Draft road map for porting 2.20 to FM 8
Goals for first port of ebase 2.20 to FileMaker 8 (v. 2.80)
1. Revise login/security model to take advantage of new FM features & remove dependence on dialog plugin.
2. Revise Find features to to take advantage of new FM features & remove dependence on dialog plugin, client-side files.
3. Revise email features to to take advantage of new FM features & remove dependence, at least for now, on e-mail plugins. (this means, for now, no POP, no incoming mail)
4. Revise import features so they can be server-side files.
5. Implement FileMaker features in place of those provided by window, dialog, and SMTP plugins. Temporarily disable bulk-mail features that use SMTP plugin (to re-implement in a later release)
6. Test & confirm successful & reliable peer-to-peer performance.
7. Test & benchmark WAN performance
8. Begin to plan & document coding conventions for all subsequent work, including future bug fixes, incremental condensation into separate data & user interface files, & new feature implementation.
- Printer-friendly version
- Login to post comments
this looks good to me. a
this looks good to me. a few comments:
re #4: the import features don't need any particular changes to work as server-side files. You could just put 'em up on the server and they'd work fine (as long as the File References were set properly). The only reason they were made client-side to begin with was to enable multiple users to store their own mappings (something that I think in reality has been used very rarely at best).
The biggest potential improvement in FM8 for the importer would be to use the new functions that allow looking up a value by reference to a field name. These would allow the importer to run much faster, as there are several overly-complicated scripts in there that are working around the lack of such as function by looping through field controls on a layout.
re #2: this sounds good. I'd really like to see some other improvements in the Find (UI and features) but that could wait until a later release.
re #8: I'd suggest really looking into the pros/cons of the "separation model". My experience with it so far (in non ebase context) has been that it's buggy and of limited helpfulness. There are some bugs (AFAIK undocumented) that crop up for me when attempting to refresh certain data based on complex relationships when the tables are in a different file.
And, as I'm sure you're aware, FMP's dependence on calc fields makes it very difficult to truly separate data and interface - I've found that just about every significant change requires some changes to calcs that are in the same table as the live data. And if that's the case you'll never be able to do a simplified upgrade (i.e. upgrade just the front-end and leave the data file(s) alone). And that would be the biggest benefit attempting separation to begin with.
I'd vote more for consolidating ebase into 3 or 4 files. Something like 1 for the core structure and data, 1 for custom reporting (which would still require temp tables), 1 for other custom elements, etc.
Separation Model comments
I'm offering only a few comments about the "separation model" ...
I've used a pretty large separation between "interface" and "data" in 2 rather large projects now.
Like Matthew, I've found it fairly common that changes that might SEEM like "interface" changes in fact require changes to the "data" file.
However, in my case at least, I've still ended up feeling that the separation was a qualified advantage. You have to weigh the pros and cons, but the "interface" file at LEAST makes it possible to do relatively minor customizations of layouts, etc. without dealing with export/import of data, etc. It has been my judgment that if the underlying data model being applied by the application is well-thought out and comprehensive enough to be stable, that I will typically approach BIG FileMaker projects with a "separation model" mindset - until something knocks me OUT of that.
I haven't personally seen any issues with bugginess resutling from an "interface/data" separation, but my applications have been much more straightforward under the hood than ebase V2 is...
I definitely agree that consolidation of now-separate files into a reduced number of files would be a very useful goal, whether this involves separating out the interface or NOT.
--------------------------------------------------
Larry
ebase Consultant
www.quimdas.com