FM BetterForms
BF Editorfmbetterforms.com
1.0 dont use
1.0 dont use
  • Introduction
  • Features Summary
  • Getting Started
    • System Overview
    • Integration
      • 1. Configure FileMaker Server
      • 2. Add your Server to BetterForms
      • 3. Introduction to Hooks
      • 4. Create your first Site
      • 5. Create your first Page
      • 6. Configure your FileMaker File(s)
      • 7. Run your first Hook
      • Next Steps
    • Common Customizations
      • Introduction to Actions
      • Introduction to Buttons
      • Page Navigation
      • Displaying Data in a Table
    • Support
      • Hacking a Webpage
      • Learning JSON
  • Reference
    • Site Settings
      • Navigation
      • Slots / Code Injection
      • App Model
      • Site-wide Named Actions
    • Page Settings
      • Data Model
      • Card / Window Modals
      • Validation
        • Custom Validators
      • Misc Page Settings
    • Page Elements
      • Common
        • Button
        • Data Table
        • HTML
      • Grouping Elements
        • Tabs
        • panel
        • accordion
        • listrows
      • Uploading Files
        • dropzone
        • dropzone to S3
        • uploadCare
      • Misc Elements
        • Plain Text / Code Editor
        • signature
        • fullCalendar
        • rangeSlider
      • Payment Gateways
        • Authorize.net
        • PayPal
        • Stripe
      • Adding Custom Page Elements
    • Actions Processor
      • Named Actions
      • Actions
        • runUtilityHook
        • path
        • debounce
        • throttle
        • showAlert
        • showModal / hideModal
        • function
        • clipboard
        • cookie
        • setFocus
        • wait
        • emit
        • validate
        • channelJoinAnon
        • channelLeaveAnon
        • messageSend
        • messageSendAnonChannel
      • Authentication Actions
    • Script Hooks
      • Globals Variables
        • $$BF_Model
        • $$BF_App
        • $$BF_State
      • Keeping Keys Private
      • Reducing Payload Size
      • API Callback Endpoint
      • Common Hooks
      • Scoped Hooks
    • Users & Authentication
      • Managing User Accounts
      • Custom Login Pages
    • Advanced Configuration
      • Custom Domains
    • BF Utility Functions
    • BF Error Codes
    • Messaging
      • Adding users to channels
      • Removing users from channels
      • Sending messages
      • Get connected users
      • Get active channels
  • Usage Tips
    • Troubleshooting
      • Debugging
      • Frozen Actions Queue
    • JavaScript Tips
      • Calling Named Actions from HTML Vue Events
      • Calculations
    • System Overview
    • Forms Processor
      • Form Types
      • HTML & VueJS
      • Styling and Design
      • JS Caclulations and Functions
    • Customizing and Styling
      • Custom Components
      • Custom CSS
      • Custom Components
      • Page Pre-loaders
      • Favicon
    • Design Patterns and Best Practices
      • Working with environments
      • Handling Data
      • Saving Data
      • Optimization
      • Business Logic
      • UI / UX
  • Security
    • Authentication
    • Security White Paper
    • Firewalls
    • Technology Stack
  • Compatibility
Powered by GitBook
On this page
  • DRY - Don't Repeat yourself
  • Validation Best Practices

Was this helpful?

  1. Usage Tips
  2. Design Patterns and Best Practices

Business Logic

PreviousOptimizationNextUI / UX

Last updated 3 years ago

Was this helpful?

Separating Concerns

DRY - Don't Repeat yourself

Write scripts that can be called from both FM Client and BF Web apps equally. This is a paradigm change for most FileMaker developers.

Consider a workflow that creates a new record when a user initiates some action like clicking a button.

Traditional FileMaker Pseudo code

  • [Button Clicked] - Run script "Create Record"

Validation Best Practices

Do not assume data has been validated. Anything that comes from the client (browser) can be hacked. If you are using the database native field validations (not empty, unique etc) then make sure you trap for errors on commit. These errors should be echoed back to the client in the form of a or .

modal
alert