Can SM/Groovy change the way we build FM databases

[ProZachJ]

Wanted to get some input/ideas on something I have been kicking around in my brain since finding ScriptMaster and beginning the journey of learning Java/Groovy.

Can SriptMaster/Groovy be used to create an FM database that is Object-relational?

This is just strait brain spewing, but if you code your own classes and package them as jars for use with ScriptMaster could you leverage java/groovy classes in a way that would allow FileMaker tables to become more like persistent objects and thereby avoid some of the pitfalls that accompany traditional relational db data normalization?

Can we bring the concept of inheritance to FileMaker?

Example...Leads/Prospects/Customers have many similar characteristics and need to preform many of the same functions/behaviors yet each has some unique properties that cause them to be modeled in FileMaker/Relational DBs as a separate table. This leads to a lot of duplications in layouts, scripts, fields and calculations.

I have always feared that my daily use and development in FileMaker is turning me into one of the bemoaned "dataheads" who thinks in terms of tables, fields, and functions rather than in terms of real world objects. How can we use ScriptMaster to bring a little bit of object thinking to the FileMaker world?

[Valentin]

Not sure I can give a the answer you're looking for.

One downside of ScriptMaster in comparison to a plugin that has a specific purpose, is that it's not able to store a state of any particular object in memory for use by another module. I can expand on this point if you like, just let me know. There are, however, several ways to share data between ScriptMaster modules, you can use SMSetVariable function, you can use system properties, or you can serialize objects to disk. I think you're talking about implementing your own data storage and it doesn't seem that it's a good idea at first glance. While FM does not have a straightforward way to implement OO functionality, you can definitely use a single table to store all shared data for Lead/Prospect/Client setup, and have separate tables for info that's specific to Lead, Prospect, and Client.

All of the above is my opinion, so please don't let that stop you from doing whatever you're intending to do with ScriptMaster, and if there is missing functionality we're glad to look into customizing it for your specific needs.

[ProZachJ]

I was just more talking about using scriptmaster to leverage the JDK in a way that could make FM more object oriented.

Like in the example before:

I have 1 table that represents my "people object" and I use a field to be the "describe myself" behavior of that object. The field is a simple text field but using scripmaster/groovy is used as a map thus allowing me to alter the attributes that compose a persons description based upon the type of person they are.

For example:

Here is the value of the "description" field for two different people.

Type:Employee Name:jimmie Address:222 my lane Salary:$1,0000000

Type:Customer Name:jack address:1234 Sample st

accountrevenue:$15000

Both people have names and addresses but only employees have salaries and only customers have account revenue.

Instead of using separate fields for all the attributes that describe a person, and thus having to create either different or more tables to normalize the difference in description for different types of people. I have created a field that functions as the description regardless of the type of person by using scriptmaster/groovy to leverage maps, a very useful tool that is foreign to the filemaker world.

The question is if dealing with this in implementation would be to laborious. It would definitely represent a whole new way of thinking about a Filemaker database.

I just was hoping to kick this mental football around a little as my employer is never going to pay me to develop Object/Relational filmaker theory but its a topic that has been running around my brain ever since I met scriptmaster.

[andries]

This is an interesting way of thinking, and I am also trying to get to a Object Oriented/Relational method to develop inside FileMaker.

Just for the ease, let's keep the example of the people object.

Me as well I try to normalize data as much as possible, but I like keeping them in separate fields. I don't see the added value of storing them all in one field (for now, maybe I don't understand the prinicple already, but I am willing to think with you!). For example: just for the interface you will still have to create separate fields (calculations taking values from the general "Describe myself" field) only to see them.

Can you describe a little more how you would use ScriptMaster as a mapper, and why you need ScriptMaster to do this?

If it is just to change partial values in one field there are plenty of custom functions that can do that for you. There is a bunch of xml functions, so if you store the data as xml, you can change whatever you want.

How will you handle the display? For example on a "Employee" layout, how will you show his salary if it is stored in the same field as where the employees name is.

I hope some other people join this discussion, but I don't know if the ScriptMaster subforum is the correct place to have this discussion. I am now trying to do this with just simple FileMake scripts, I have setter and getter scripts, certain "method" scripts, etc. But I think I can still go much further in this theory/method, so I am really curious how other people think about this.