It's a little difficult to tell from your explanation, but the short answer to your question is no, FileMaker is not really an object-oriented programming "language". It's a database environment and Rapid Application Development (RAD) tool.
That being said, in your particular situation, it sounds like you're making your life harder than it needs to be, probably because you're unfamiliar with FileMaker and how it works. I can't be certain without seeing your solution (maybe you can post a sample file), but it sounds like you have a lot of duplicate tables that have more or less the same fields in them, with slight differences. If that's the case, you probably have a data modeling issue that could be rectified to make your solution run better.
Perhaps it's best if we cover some of the "layers" that FileMaker has and that might help you sort out how it works a little better.
1) Data tables / schema: This is where you store the actual data for the solution. Tables can contain actual solution information or they can be utility tables that store information temporarily for automation purposes. But it should follow good normalization practices for the solution to run well. A solution shouldn't have multiple tables that contain the same or very similar storage; it's a waste of computing resources and makes the solution inefficient (i.e., slow).
2) Relationships Graph; This defines the connections between the data tables. It functions as a combination of Entity-Relationship Diagram (ERD) and querying tool (although the Find functionality also functions as a type of querying). Joins can be created between Table Occurrences (TOs), which are representative of the underlying tables (not the tables themselves).
3) Layouts: A layout is a presentation of an underlying TO. Every layout sits on top of a TO, which gives it "context" - it establishes the point on the Graph from which FileMaker evaluates all the calculations, relationships, etc., for that layout. This is an important concept to understand in the FileMaker environment, because the path you take through the graph for any layout will define what related sets you'll see.
4) Scripting: The scripting engine performs the functions typically seen of methods, procedures, and functions in a more code-oriented language (such as Java). A given script can mimic a procedure or a function, depending on how you structure it (if you pass in parameters and return a result, and the script is independent of context, you've built a function). "Methods" don't really exist, since you don't have "classes" or "objects", but much scripting is dependent on context - an underlying layout is often assumed, so the script will only work properly if the context is established (either by the script or by executing it only from the correct layout).
5) Conditional Formatting: Allows the developer to change format of layout objects based on conditions, either the values in fields or through a calculation. Tied to specific layout objects.
6) Script Triggers: Event triggers. Fire a script at the object, layout, or window level.
7) Functions: These are built-in capabilities inside calculations. Many of them allow you to extract context information from the current state of the database, including, for example, the current layout context, the current date / time, the current table name, and so forth.
8) Custom Functions: The Custom Function feature is a way for developers to add functionality to the built-in calculation engine. The calculation engine is used in many places throughout the environment, including scripting, database definitions, interface elements (such as Conditional Formatting), and the like. Essentially an extensibility tool.
So, to address what I think your concern is, you can do a few things. (I'm doing some guessing here, so I might be wrong on exactly what you need. Let me know if this isn't right.)
1) Try to back up and, instead of using tables to contain similar information, build a single table and use scripting to manipulate the records. You can update records through the scripting engine and use discriminators (such as, say, a Type field) to separate one record from the others. Find requests will allow you to separate them out.
2) By using the Get ( ) functions, you can extract information about the database so you can write DRY scripting that doesn't have to be repeated multiple times. It will automatically adapt itself to the current context when it runs. (FileMaker's scripting engine is a runtime operation; it doesn't fully compile.)
3) You can use global fields to create temporary relationships between tables, such that you can establish the joins during scripting operations instead of hard-coding them into your Graph. This will be way more flexible and will cut back on the amount of coding you have to do. It'll also run faster.
A lot of this is more advanced techniques. I would suggest you first start with some database normalization, and then use scripting techniques to create functions instead of trying to use data tables. If any of this is not what you're looking for, then maybe posting a copy of your file would be useful.
Wow, long post, +1 to Mike_Mitchell.
FileMaker scripting does not natively support OOP. You can emulate it with a bit of an effort, but I am not sure there is an advantage in doing so.
To be fair, SQL is not OOP language either for the same reason - it is a query language
First of all, thanks for your contribution.
Honestly I don't completely undestand why Filemaker has difficult to approaching to the object-oriented programming. I'm new about this environment. Please, can you explain me again more in detail,? I'd like understand perfectly your reasons.
Mike_Mitchell you're right about my competences in Filemaker.
In short I have especially a financial underground and in the past my job just consisted of defining the financial calculation structure of some financial software of my company (all these software with Filemaker Language). So, for a long time, I worked in very close contact with our Filemaker programmers and this has benn a great opportunity to know as programming and, more specifically, as Filemaker work.
Eventually my boss asked me for becaming myself a Filemaker programmer and this is my first software.
Besides I have to say you that this software had a lot of different programmers succeded during the last 10 years, so probably this is the main reason for its great complessity and difficult running.
Now I will try my problem with a very streamlined example.
This software manages a financial service "A". For this running we define this structure.
Table A (field A1, fileld A2, .., field A50, field Z1, field, Z2, ..., field Z10)
Script A1 (for calculation)
Scriprt A2 (for export to Excel - monthly values)
Scriprt A3 (for import from Excel - monthlyvalues)
Scriprt A4 (for cancellation Excel - monthly values)
Scriprt A5 (for export to Excel - annual values)
Scriprt A6 (for import from Excel - annual values)
Scriprt A7 (for cancellation Excel - annual values)
Scriprt A8 (for export in PDF - monthly value)
Scriprt A20 (for other funcion ..)
Scriprt A40 (for control n)
Layout A1 (PC window - monthly values)
Layout A2 (PC window - annual values)
Layout A3 (PDF- monthly values)
Layout A4 (PDF- annual values)
Given this structure you have to think about a financial service "B", that have a similar structure.
Table B (field B1, fileld B2, .., field B50, field Z1, field, Z2, ..., field Z10)
Script B1 (for calculation)
Scriprt B2 (for export to Excel - monthly values)
Scriprt B3 (for import from Excel - monthlyvalues)
Scriprt B4 (for cancellation Excel - monthly values)
Scriprt B5 (for export to Excel - annual values)
Scriprt B6 (for import from Excel - annual values)
Scriprt B7 (for cancellation Excel - annual values)
Scriprt B8 (for export in PDF - monthly value)
Scriprt B20 (for other funcion ..)
Scriprt B40 (for control n)
Layout B1 (PC window - monthly values)
Layout B2 (PC window - annual values)
Layout B3 (PDF- monthly values)
Layout B4 (PDF- annual values)
You can see that the scripts and layouts are pratically the same. The unique difference consists in the fields inwards. Besides some fields (Z1, .., Z10) are the same and these fields are the more recalled from scripts and layouts !
Nevertheless I have always a hard work because when I define a new financial service I have to change also these fields (in all these scripts and layout) because they have a different relationship.
Last complessity, these fields (Z) are calculated in another table in another file of this software. Right! This software has been made on the basis of 7 different file linked between themsel.
So can I define a new object-oriented programming in order to manage more simplier these kind of situation ?
Once again, you do not need OOP here, you need to sort out your database structure. We are not talking about FileMaker specific, you architecture does not look right from the general RDBMS point of view.
Just to get you started:
Why do you need two separate tables for financial service "A" and financial service "B"? You can just use a single table and add financial_service_type to differentiate between the records. Ideally, you would move it into a separate table and only a foreign key to link to that table.
The process you need is called Database Normalisation and not OO programming.
I’m not sure how much more “in detail” I can explain it. FileMaker is not an OOP language. It’s a database environment. It’s really that simple. It’s like asking, “Why is a horse not a car?” Um … because it’s not. They’re both means of transportation, but they’re just not the same thing.
Now, based on the structure in your example, I would speculate you have some financial people (who are accustomed to a spreadsheet environment) working from that paradigm in FileMaker, and this is why you have a field structure like what you have (fields like A1, A2, A3, etc.). The folks who built it are trying to translate each spreadsheet they used to use for each financial service into a data table. While the correlation loosely holds, it’s a poor way of doing things.
What you have is a data modeling issue. A properly modeled database would completely do away with the need to create a new table every time you have a new financial service. Rather, you would define a set of rules around what each transaction is supposed to do, and build up the structure accordingly. (And for heaven’s sake, don’t use a field structure like “A1, A2, A3”. Use meaningful names.)
I suggest you get a copy of the FileMaker Training Series and go through it. Pay particular attention to the chapter on Data Modeling. If this doesn’t work for you, find a database consultant in your area who can help you lay out what you’re trying to do in a properly normalized database.
In addition to database normalization, you can make dynamic scripts in filemaker that will take parameters (EG monthly, quarterly, annual), and perform different actions based on those parameters.
This lets you handle actions for similar functions as you've noted, like imports and exports, and changing the data displayed on a layout through find operations.
Since the filemaker script maker is WYSIWYG, picking and choosing from a static set of commands, there's really no "OOP" that you can do. the only "raw code" you write is for the calculation engine, which acts the same way that most functions act in hard coded languages. The calculation engine is not used to write "objects" though, just simple (or complex) calculations.
If I were you, I'd take a look at one of the starter solutions that comes with filemaker. you'll have full access to view schema, scripts and layouts. After you've seen those things, you might get a better understanding of how things fit together in FileMaker.
Don't treat filemaker as an OOS though, it's the wrong approach and will only end in frustration.
+1 to the other suggestions. There should only be one table for a financial services with the one set of scripts, layouts etc. over it. And you should have some sort of unique identifier for each financial service.
It sounds to me that what you have can be compared to an address book. Each address book card does not get their own table and layout! It's one table full of entries.
In your structure above you have one table per financial service, use the same table and fill it with services.
Like the address book there may need to be some customisation for each financial service, e.g. in an address book often you need to have the details in the table to handle a private address, and a company address. I'm sure your financial service is a lot more complicated than an address book, but you need to do it differently than what you are doing, a database should not need redevelopment for the regular task of adding an entry.
The simple answer is that what you are trying to do is not what FileMaker does. You have the wrong application and should a) find the right application or b) revise your plans and methods.
FileMaker was originally designed for the novice and retains much of that design today. It i s an upper level design environment with much of the hard work done by the programming staff. Users just point and click among the many functions and derive powerful apps.
I suggest you stop trying to shoe horn your ideas into FileMaker and instead open some of the sample files and get an idea of how to create an app in FileMaker. These are demos and not intended to be full fledged apps. But you will get an idea of how to make things work.
Essentially, if my understanding is correct, you are trying to use tables and fields to contain code and such for your app. In FileMaker you would put your instructions inside a script and activate that script with a button click performing the script or as a step in a parent script that then performs the script itself. Parameters can be passed back and forth which I think is also part of your question.
It will take a bit to understand how FileMaker works and then agonize over how it doesn't do what you can do with other apps but then it does a lot you can't do with them. It's all about finding the one that works the way you want to work.
Every so often you do need to flip between an A and B Table, and FileMaker does not do that well
It would be an interesting feature request
A single script can work on more than one Table, by switching layouts, and not using field names, e.g. just go to first field in the Tab Order, or by Object Name, and Get ( Value ), or Set Field
A SQL solution is also possible, since SQL Queries can be built "on the fly", refering to multiple tables
As a last resort, duplicate the file, and call it B, and use 8 linked files
> So can I define a new object-oriented programming in order to manage more simpler these kind of situation ?
There is a lot of good advice here. I think the biggest point is that it appears you are trying to setup FileMaker as if it were a spread sheet. If you want you can think of FileMaker in terms of OOP. To do this, consider a Table as an Object with records as an Instance of that Object. Using your example of a Service. Consider a table with fields that define the service as the Object. Creating records in the table would be set of instances of the service.
If you set up an Object (table ) for a client, You connect them though Primary and Foreign ID keys. Primary ID in Service = Foreign ID in client.
That's as far as I dare go with the OOP analogy, it has been to many years since I went to Computer Science class.
I would strongly recommend that you go through the FileMaker training series. If you become a paid member of the Community you can download it here. Also go to your local book store or look on line. There are number of great books on FileMaker. They don't mention OOP, but will give you some very good advice on developing FileMaker databases.
One other place to look for good FileMaker development techniques is FileMaker standards:
Again thanks for your attention to my problem.
Certainly I have to do more practise about Filemaker and I'll do it.
About your advises, I'm very interested in your idea to manage all the similar services (as A and B; but in this app we have also C and D that are verey similar between themself but they have a different logic from A and B) with a unique table.
Nevertheless, isn't this running too heavy? Above all the importation of a table with a great number of fields (to other table or file), doesn't it slow down the app activities ?
You have to think that this app has a lot of financial services and a lot of similar financial services as A and B (for example there are other 15 services that are similar to A and B (by the way Mike_Mitchell of course their fields have a name more meaningfull than A1, A2, B1, B2; it was for doing an example).
OP you said "importation of a table with a great number of fields" and this suggests that, as others have said, you are trying to recreate a spreadsheet structure in FM and this is not the right approach for making FileMaker fly. To be good at FM development you have to understand your data and fit it into the relational data model because FM is an Relational Database Management System. That means normalization, data modeling and other concepts.
Take a look at some of the starter solutions to see how others have done things.
Also FM starting point by Richard Carlson Consulting and other publicly available FM solutions.
15 tables is not unusual. Do they really need to be separate ?
Either way, importing data can be painfully slow, as FileMaker needs to create records, and update indexes, but that could be done overnight. Try it
It would help if we had Square Bracket Notation, to refer to Tables with a Variable
> Nevertheless, isn't this running too heavy? Above all the importation of a table with a great number of fields (to other table or file), doesn't it slow down the app activities ?
Se vuoi, ti posso aiutare chiarire ancora un po' le tuoi domande.
Quello che vogliono dire gli altri è che FileMaker funziona completamente diverso da OOP. In fatti, si assomiglia di più a MySQL o Microsoft Access. Se stai disposto ad spedirci una copia del tuo file con parecchi registri sarebbe più facile aiutarti.