3 Replies Latest reply on Oct 5, 2012 6:36 AM by jbante

    option to script & write custom functions in a (more?) object-oriented way

    hrc

      Hi everyone

       

      Some years ago I worked on a project where the industry calculation and simulation suite MatLab/SIMULINK was used. This is a hugely complicated and powerful plattform which, basically, has nothing to do with FileMaker.

       

      In earlier versions users could only write linear, procedural scripts in MatLab/Simulink. However, MatLab/Simulink underwent a development and nowadays users may choose whether to write their simulation scripts in a procedural way or in an object-oriented fashion.

       

      What I like about this is, that those, who don't know what OOD is or somehow can't get used to it, just don't have to use it. At the same time, those who want to use the powers of OOD can do so.

       

      When developing FileMaker scripts and custom functions I very often think: "Okay, this would be a typical case, where OO would make life a LOT easier. How do I implement it with the tools I have?"

      I might add that it's not sufficient for me, that you can use PHP or Groovy via commercial plugins (Scodigo, 360Works) because the objects you create with these plugins live only within the custom functions written with these plugins.

       

      I am aware that the option to write scripts and custom functions in an OO way is a feature that the marketing department of FileMaker could advertise only with a fraction of its target audience, but I am sure that many of us professional developers would be very happy to use it.

       

      What do you think?

        • 1. Re: option to script & write custom functions in a (more?) object-oriented way
          jbante

          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?

          • 2. Re: option to script & write custom functions in a (more?) object-oriented way
            hrc

            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.

            • 3. Re: option to script & write custom functions in a (more?) object-oriented way
              jbante

              It sounds like you're ascribing to object-oriented programming greater power than it actually has. It's an organization techinque (one that is easily abused), not a free lunch or silver bullet. Programming of course involves encapsulating computer-executable representations of real-world problems to reduce those problems to something the human mind can grasp, but I'm not convinced that object orientation is a good fit for encapsulation in FileMaker. Personally, I think FileMaker developers could stand to gain more by adapting lessons of the functional programming paradigm. One of the fundamental benefits of FileMaker is that it cuts out multiple layers of organization between the CPU and a working application — developers don't have to think about JavaScript-driven HTML on the client-side communicating over HTTP (and the rest of the OSI stack) with PHP on a web server, which is itself exchanging data with a MySQL database. It's just FileMaker. Object oriented programming encourages developers to build a whole new network of components passing messages to each other or calling each others' methods (depending on your particular sect of object orientation). That would be a step backward for what FileMaker is.