I've seen many requests for features where novice users can do something the simple way, and advanced users (i.e., users with experience writing software for other environments) can do it a different way — they all make me fear that the ecosystem of FileMaker applications could become fragmented into camps that use the feature and camps that don't, with no continuous easy on-ramp from one to the other.
Can you describe such a scenario you've run into where OO features would have made a FileMaker solution easier?
Thanks for your reply.
I don't share your fear that the FM community could become fragmented because I believe that it already is! And I don't think that this is a bad thing. I believe it's a logical consequence of the fact that FM is made for non-IT professionals as well as for IT pros. In my country FileMaker is pretty wide-spread among schools. Many a teacher uses it to bring order to... just anything, basically. A friend of mine, for example, who is a college teacher, uses it to track their collection of books, movies and specimens in the range of biology. I helped him a few times when he had questions how to implement something. His layouts are extremely simple and he doesn't even use FM Pro Advanced to develop, however, his database is a huge help for himself, their technicals staff and his fellow biology teachers.
Where would OO features make life easier? - Oh in so many cases...
Think about custom built menus. Each menu item has its set of properties (label, target, active/inactive, etc.) and an action should be carried out when clicking it. This action may vary depending on context and user account. There you have it: properties and methods. OO.
Think about the state of a user session. It would be much more comfortable to store it in an object during execution than either in a bunch of global vars (attention: security!) or in a bunch of global fields.
Think about writing powerful custom functions (without plugins). I wrote a set of custom functions to make it easier to deal with IPv4 addresses when managing them with a FMDB. There are custom functions to validate them, to check for their membership in a subnet, to render them human-readable or sortable, etc. It is certainly possible to do this with current methods, however, it would be more efficient, more elegant and even easier using objects than many, many variables.
Think about syncing data between to FMDBs (be it FM Go and FM Pro or whatever). Wouldn't it be nice to wrap a whole context in an object and to sync these objects instead of dozens/hundreds of vars or fields? To give a specific example: Think about a restaurant where orders are taken on an iPhone/iPad and transferred to the order dispatching FM Server. How nice: An OrderObject contains the table number, the time the order was taken, and it contains furher ChoiceObjects of subclasses Starter, Main Course, Beverage, etc., etc. After transmitting such objects you can feed them by script into the right tables so that the kitchen staff knows what dishes to prepare.
I could go on...
Again: I AM very well aware that all/most of these things can be done in a non-OO way. That's what I'm doing all the time. But I think it's a pitty we don't have the power of OO in FileMaker, even a partial implementation would be helpful.