We All Have a
World Code View
This blog post exists because you, yes you the FileMaker developer, has both a perspective and opinion about "How things should be done". You have a mental picture of what defines a "standard" when it comes to development. You have either created your own system and methods or you "buy into" using someone else's - either outright or in part. You collect insight as you grow and become a better developer. Along the way your perspective changes.
You may favor code portability over legibility. You may favor being concise over being verbose. You may want your code to be self-documenting over having to create documentation. You may be biased towards zero dependancies (good luck with that in any modern code environment).
Or, you may favor the opposites of any or all of those situations.
To put this bluntly. NONE of them are "right" in their absolute.
For example, in text based coding languages, the fact that some developers like to use 2 spaces, where another may like 4 and yet some will standardize on a tab character means that we all have differing perspectives and coding desires. Sometimes it's chosen. Sometimes it's imposed.
Based on the comments which started on the Empty strings (null values) page on this web site, this blog post and the comments serve as a place for open discussion about the notion of "standards" within the world of FileMaker development - hence the topic titled "The Great Null Dilemma".
The definition of standards can be very murky unless clarified and agreed upon. The key point here is "agreed upon" for the benefit of those choosing to adopt said standards. If you're a single developer, there's not much disagreement - because what you say goes.
However, if you perform any degree of work which may be jointly shared, then arriving at an agreed upon set of standards is what promotes collaborative understanding. And a good degree of personal benefit if I may say so myself.
My own personal viewpoint comes from having worked with FileMaker since the mid 90's and also having worked with a variety of content management systems created within PHP. PostNuke, Typo3, Xaraya and Drupal. I've also created many scripts and done work with both PHP and Perl based on using repositories of code, such as CPAN and PEAR.
In most every situation where I've agreed with myself to use someone else's code and take advantage of it, I've had to do a good deal of learning. I had to learn how things worked and why they were done that way. I had to seek to understand. Once I had it, I could take advantage of what I had learned over and over. I am also able to come up to speed quickly on any updates to what I had already learned.
Please note, I didn't have to agree with how they did things, because the advantage to me was leverage. Leverage allows you to arrive at an end result faster than if you didn't have it. In other words. I can take advantage of a PEAR module ( a pre-existing chunk of code which does something pretty specific in PHP ) and save myself the time and hassle of coding it up myself.
I also became familiar with frameworks such as Cake PHP, Code Ignighter and more recently Zend. I also made an investment in really learning the Drupal CMS. Knowing these things does not make me a coding expert, but I do think it gives me a perspective beyond just working with FileMaker.
Having been involved with using Drupal at an early stage I watched the adoption of Drupal increase significantly. From a code perspective, I would like to say that it was solely because it was "good code". Yet you'll find many developers in the PHP world who will say it sucks. "Because it's not OOP", or some other reason (Drupal is actually using more and more OOP code now). My personal opinion for the reasoning behind increased adoption and acceptance of Drupal is because of the documentation. Both within the code and outside. Documentation is the line of communication between what the code does and why it does it that way. It allows another developer to find the understanding necessary for greater leverage.
It was for this reason that I started this web site.
When you have something documented, which can be referenced, it serves as the blueprint for why something works the way it does. Again, you don't have to agree with it if your main objective is leverage.
Everyone is free to write all the code they want. Personally, I don't want to write everything. There's little point - unless I feel like I have an endless amount of time to do so.
The Perspective Difference
Some developers love to sling technical terms around what they do within FileMaker. They like to apply Object Oriented principles to their scripting and how they structure a database. They'll say they've created the coolest FileMaker system based on MVC (Model View Controller). I know, because I've done it. I've had the pride that comes with applying some cool sounding technical term or process to the world of FileMaker development. However, I know they don't really apply. Maybe their premise does, but it's not quite accurate - because FileMaker is not like other coding environments. FileMaker is like FileMaker, just like PHP is like PHP.
The truth is this. Your perspective about your own code is unique to you based on what you've created yourself, what you've adopted from others and how you've done things in the past. Changing to a "new way" of doing things always takes more effort than doing them the way you've always done them. Yet, it's easy to become stagnate and fall behind because you don't evolve with the "rest of the herd".
Inevitably, most developers will think their way is the best. I'll admit this to myself. It bolsters ego and validates what you know. Yet, I must also admit that my perspective is pretty unique - in that I'm the only one who has it.
When it comes to "standards", this is where perspective can be removed from the development equation - if, and ONLY if, you desire it. When a set of standards frees you from having to code everything yourself because you can leverage pre-existing content based on those standards you stand to gain the greatest advantage.
Herein lies "The Great Null Dilemma".
If an agreed upon standard outlines something which clashes against your personal perspective, you end up having to make a decision. Change your ways - or - don't. Stay with the project - or - don't. In the world of PHP frameworks there are plenty. In the world of FileMaker, there are few. The ones that are documented are the ones which exist for consumption - otherwise they exist in obscurity.
The fact that a standard exists does not mean you must use all of it - unless you expect what you create to interconnect with other things created under that same set of rules - and be understood by those who adopt the standard.
As I watched the world of Drupal grow up from 3.6 to 4.7 to 5, 6, 7 and now 8, I've seen every type of "coder" personality. From flexible to inflexible.
Yet despite the personality type, or personal desires regarding the "how" something should be done, there was one thing that kept some of the perspective out and kept the project growing.
Make your Case
That's what this site is about. Documentation about the standards that "we" agree on. If we agree (we being the majority who have adopted) that using an empty custom function named Null does create a dependency, yet that dependency is acceptable because most projects opt for readability and comprehension over portability. Then we let the documentation speak to that fact.
If our concern is greater adoption of the standard, because that validates our own work and efforts, and portability is a higher priority, then it's quite obvious that we kill the empty custom Null function.
Regardless of whether you agree with everything, some things or nothing here, if leverage is your objective, and you've obviously got a stake in the game - then make your case. Show, why you feel the way you do and convince others of what you say. Group participation and documentation is what makes for a good set of standards.
Hopefully, the content you find on this site will ultimately benefit your choice to continue to work with the FileMaker platform. Whether you adopt or not. If you do choose to use these standards then participate. Just don't expect that "these" standards will be "your" standards - they may not be.
So, let's open the debate and create something that helps those of us who are here.
We can't be all things to all people - lets not try to. It's really hard - and tiring.
I posted this comment on the main page of the Coding Standards and I'd love to hear what others have to say. This blog post is a better place to have the conversation. So, to start it off, here is what I had to say.
I'm all for the ideal. The biggest problem in the path of an ideal, that satisfies all the various environments, is FileMaker itself.
Sadly, my BIGGEST gripe against FileMaker is the SERIOUS lack of organizational/documentation tools. I think FileMaker has been one of those applications which had a lot of early adoption, started heading in a direction and hasn't taken the time to refactor.
Here are only some examples of what I'm talking about.
- No filtering in manage fields or tables (thank goodness it's in scripts). Finding code fast should be a priority. Draco Ventions has a great tool called Developer Assistant for this type of thing.
- No indicators on TO's or relationships of the attributes (e.g. allow creation, deletion and sorting)*
- No tightly-bound associative comments on tables, table occurrences, relationships, value lists, security and other areas. (it's great to have on fields, but why stop there)
- Inflexible code editor (no syntax highlight, code folding, changing editor font, etc.)
- The Relationship Graph is flat. No creation of logical groupings of TO's, no search feature, no grid or snapping support and various other missing features I would put in.
Granted, recent improvements like the Inspector palette and improved Status bar provide more information, but there is still a ways to go in aiding the developer.
So why say all of this to address why I promote breaking out the various technologies on a file by file basis? Because, if you're seriously developing a FileMaker solution then you're likely using a separation model. In this case, the data file is clean and won't be hindered by FileMaker specific conventions (such as the tilde and percent). Accessing with ODBC/SQL shouldn't be an issue.
I agree, this does add a bit of overhead (due to potentially duplicated script functionality), but the upside is that your whole system becomes a bit more self-documenting.
Some day, I'll have to sit down and document my development philosophy with FileMaker. I'd love to have a public chat about it. I'll make blog post about it and we can carry the conversion on over there.
* FileMaker, as the "easy-to-use" database is great. The problem for advanced developers is that it's a bit of dialog hell.
So here's the real issue. FileMaker's relational capabilities were added in because they could be. It was an evolution from the file to file heritage of the 5/6 days (if you were around back then). The capabilities realized were awesome. The concept of table aliases (which is what Table Occurrences are) is a great concept. However, I don't think organization of a growing solution was a forethought. They probably had to wait and see what developers did with the tool.
The problem is, as I see it, that developers have had to create development models to address the documentation/organizational shortcomings. Here's the biggest one of them all.
Did you know the Anchor/Buoy method of development is simply a way to organize your data structure so it's easier to understand? It really is just that. There's nothing wrong with that (I guess), but there's very little advantage to it other than its organizational aspect (at least as I understand it - school me if there's more to it). It allows a developer to have a left-aligned row of table occurrences which match to physical representations of layouts that users interact with. Yes, it does break down the solution in functional areas and "avoids" the claimed "dreaded spiderweb" - but... did you know that spiderwebs are actually really cool?
Anchor/Buoy introduces extra table occurrences (yes, at very little data cost - if any), but adds to the "perceivable weight" of the solution. It also forgoes any advantages offered by the bidirectional nature of the relationships.
I know the anchor/buoy model is popular because I've seen a lot of developers use it. Personally, I don't use it. I rely on the limited degree of organization and documentation tools I've been given - until FileMaker adds in more.
Here's an image of a very small graph of one of my personal tools.
While this is not a major solution and it hasn't been converted to all the standards here, I don't see why this method of visual organization along with the FunctionalArea » Basetablename occurrence naming won't address the primary issue that Anchor/Buoy addresses - field selection. Basically, what we're talking about here is making head or tails of what is going on within a solution. Disclaimer: I typically work on smaller focused tools and not super large solutions - although I may at some point in the future.
As far as I can tell, I don't think Anchor/Buoy is that great of a solution because it inevitably introduces a lot of "waste" due to accidental duplication. This, in-turn, adds to the confusion of a solution.
And don't even get me started on the 001, 002, 003 prefix naming for table occurrences. We're not doing accounting here. Why should anyone have to decipher something when they should just be able to read it? Adding a numerical prefix because FileMaker's method of presenting Table Occurrence selections as a monolithic popup menu is not a good solution as far as I'm concerned.
So, I'm going to wrap up my rant for now. I'm interested to hear what you have to say.
Please, comment at will!