Do you take pictures with your iPhone?
Then you should check out iTookThisToday.

Some Q&A Regarding Squids

Q: Is there an easy way to migrate from an existing spider to a squid? I guess it would involve a complete rebuild.

A: Well, not exactly. The best way of which I am aware is to leave the spider as is, and build your squids elsewhere in the graph. A good first step is to rename your original table occurrences (TOs) so that the squid heads can be named identically to the base tables.

For example, if you have a table named "Person" and there is a TO in the spider named "Person", rename it "OLD Person". This is useful for two reasons.

  • You can now name your Person squid head "Person"
  • When you are going through the DDR (more on that in a sec), the old tables will pop out more easily

Once you have squids set up, go through your calc fields and re-point them from the perspective of the squid head for the appropriate squid head. Next, check for any related value lists that need to be re-pointed from the perspective of the appropriate squid head.

The next two steps are the most time consuming. Re-point your layouts from the perspective of the squid head. This will mean updating all of the fields and portals as well. If you have a lot of complex layouts, this will take a lot of patience and focus.

Finally, you will need to go through all of your scripts and do the same thing. Again, if you have a lot of scripts, this will be a PITA. My advice would be to run DDRs periodically during the process to make sure you didn't miss anything. If you see one of the "OLD" TOs, you know you still have some work to do.

You can use my Process DDR file to help with this:

http://www.jonathanstark.com/downloads.php#process_ddr

Q: When using one table (head) with many legs, would you split the main table into more heads? And would normaly each table form one head. So with 10 tables you would probably have 10 heads)

A: If you have 10 tables, you must have exactly 10 squid heads.

Q: I like the squid/TOG concept, however it bothers me that I have to create extra value lists for example because the fields I want to use are in a TO that's not related to the TOG I'm in.

A: Maybe I don't understand the question, but you should not have that problem because all layouts, related value lists, and calculation fields should ALWAYS be based on a squid head.

Therefore, any related value lists would be available to any calculation or field on a layout, and would always be from the correct perspective.

In your question you refer to the "Squid/TOG" concept. To be clear, Squids and TOGs are not the same thing. TOG proponents avocate functional groupings, while Squids are strictly perpectives, devoid of any implied function. It's an important distinction.

Admittedly, related value lists are - IMHO - the most confusing aspect of FileMaker 8 development. If you like, you can download this demo file for an example of how I build related value lists with Squids.

Q: Nor can I easily work around that by moving to the other TOG.

A: You should never have to move to another squid because you would never have more than one squid head based on the same underlying table. This the beauty of squidding that TOGs lack: you don't ever create functional groupings - you only create perspectives.

So, if you have a base table called Company, the graph would have exactly one squid head called Company, with all the necessary TOs dangling off the legs to the right. There would be no other squid heads in the graph that were based on the underlying Company table.

Q: How do you deal with moving from one TOG to another? i.e. how do you transfer the current found set?

A: You would never need to do this, for the reason described above. But just so you know, it can be done like so:

Let's say you are on a layout called "Company Detail" which is based on a TO named "Company by Employee ID" and you need to transfer the found set over to a layout called "Overdue Company List" which is based on an unrelated TO named "Company by Invoice ID".

You can accomplish this with a go to related records script step that points at the "Company by Employee ID" TO that you are on, but displays the records with the "Overdue Company List" layout. Doesn't really make sense to me, but it works.

Q: Seems like a lot of extra scripting.

A: Well, it is definitely more scripting, but I see this as an advantage. Here's why:

  • When it comes to implementing business logic, scripts give you much more flexibility than relationships on the graph
  • Most, if not all, of your business logic is contained in one place (ScriptMaker) rather than scattered all over the place
  • Assuming you are using 8 and are taking advantage of variables, scripts are extremely portable and can be reused all over the place
  • I find it easier to keep scripts organized than keeping the graph organized

If you think about it, a relationship between TOs basically amounts to nothing more than a stored query. And they are not dynamic, meaning that they can not be altered by the user at runtime. So, unless I am CONSTANTLY using a particular relationship (i.e stored query) between two TOs - like Invoice to Invoice Item - I don't put it in the graph.

Rather, I would perform a scripted routine to find the records I am looking for. It is really not that much work. When I am doing development, I pretty much never put a relationship in the graph unless I absolutely must. For instance, in order to display a portal or define a calc field that must be displayed on a layout.

Keep in mind that I work with a large team of developers and on projects that last for years, so I have considerations that don't exist for all developers. This technique has proven invaluable for us, but may not apply to all situations.

Also, in the interest of full disclosure I am a huge fan of php, shell scripting and applescript, so maybe I am just wired for procedural programming :)

Q: And is there any benefit to squids other than making the popup TO menu more manageable? Put another way, is there any real downside to relating all my tables other than *potential* confusion?

A: In my experience, the confusion is not potential, it is inevitable. Again, I am referring to large projects that may be worked on by a rotating cast of characters. If you are the only developer and you know you are not going to get confused, by all means, make a spider graph. But if the spider ends up biting you, don't blame me!

Thanks for the questions - please feel free to send more...