Rapid Development Techniques - File Maker

If you choose not to base your database system on one of the prefabricated interfaces or solutions described above, here are some tips for jump starting the development of your database system.

Create a Graphics Library
To speed the development of your layouts, build a database of graphics, layout elements, and icons that you can quickly copy and paste into your solutions.

Here’s a screenshot of the graphics library of one prominent FileMaker developer:

Create a Graphics Library

With a library like this, you’ll never be stacking a bunch of line elements together to make an arrow graphic again.

Import Scripts
If you’ve already got a solution with a bunch of standard scripts that you always add to any new database, remember that you can batch import them into the new database from an existing one. Always remember to try to create the same fields, relationships, value lists, and so on in the new database before importing so that you don’t have to fix that many broken links in the newly imported scripts.

Copy Layouts
Don’t reinvent your interface when developing different databases in a system. Develop the interface in one database, the main menu perhaps, then copy its entire layout (including all elements) and paste it onto a new layout in other databases.

Use a Clone
If you’re building two bases that will be a lot like each other, such as a quote line items and an invoice line items database, develop one completely then save a clone of it and use the clone to create the second database. If you’re lucky, you’ll only have to change the names of the ID fields and a few relationships, and edit the text on any print layouts (like the printed quote that usually comes from the line items database).

QuicKeys
Though an automation tool like QuicKeysis somewhat less useful when you’re able to import scripts from one database to another, it can help you to rapidly develop a database system. Essentially, QuicKeys lets you set up shortcut keystrokes and toolbars that perform an action in the current application when typed or clicked. For example, you could use it to automatically generate scripts, open a certain application preferences tab, print a layout, access a network drive, copy a bunch of databases from one place to another, and more, with the click of a button or press of a key.

(You must set up the “macro” that’s run upon that mouse click or keystroke first, of course, but it’s easy to do.) QuicKeys is also a useful tool for other general computer use.

Main Menu.fp5 as Central Command
As we hope you’ve seen in the “Darn Good Security System” example (if you’ve dissected its databases), the main menu database serves as a sort of central repository for elements used through the rest of the databases. In addition to reducing redundancy in your database system, this type of centralization also speeds development time considerably. Consider centralizing the following in your main menu database.

Graphics
Store all navigation graphics (as well as highlights for portal rows, button icons, checkbox icons, company logos, even entire chunks of color that you use as the tabs or backgrounds for your layouts) in global fields in the main menu. Make them as low resolution as possible to speed their delivery to users over the network (big graphics slow FileMaker’s performance when shared). Then, if you need the graphic in a database in your system, access that global container field via a constant relationship to the main menu. (Wonder why? Imagine having to manually change the “next record” arrow icon on at least five layouts across 50 databases in your system.)

Preferences
When a user logs on, store their user information and privileges in the main menu for reference by any ancillary database that needs to check the current user’s access rights. Store any other global system preferences in the main menu, too, such as a user’s platform and desired zoom level and color scheme, your company’s logo and address (for use when printing), and other stuff that might be needed by other databases.

Scripts
Scripts are generally pretty specific to the database they’re in, but sometimes you can centralize processes that are at least partially the same in all ancillary databases. For instance, the logon and shut-down scripts should be called (in the main menu) from an ancillary database; don’t rewrite the shut-down script in each database. Also, in the “Darn Good Security System,” most of the logging/ audit trail scripts are in main menu and are then called from the ancillary database that needs some logging performed.

Value Lists
In some cases, you neither need to have a value list dynamically based on the contents of a database (like a list of your current products that comes from the product database) nor allow users access to edit or update the value list. In these cases you could base a value list on the contents of a global text field that lives in the main menu. A global field with values in it like:

Lions Tigers Bears Oh My

would show up as four selectable values in a value list, though it isn’t clear who in their right mind would select “Oh My” for anything.

Record IDs
Sometimes you want to generate an ID in a different way than your standard auto-entered serial number. For instance, say you’re printing a few invoices for a particular client, and you want to group them under one StatementID so that you can bill the client for all those invoices en masse. However, you want to preserve that group so that you can print the same group later, even if the client buys more stuff from you (generating more invoices) in the meantime.

To do so, you could store the StatementID in the main menu as a non-global number field that is referenced every time you need a new StatementID for a group of invoices. (This should be a regular number field because global field values are user specific.)


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

File Maker Topics