Jump to content
The ORIGINAL FileMaker Community - Forum - Online Business Apps & Software Forum
Michael Rocharde

You did what?

Recommended Posts

Michael Rocharde

Inexperienced developers often program FileMaker in a particular way because they saw someone else on a video, blog or other resource perform the same series of steps. It even happens because the developer simply follows the client’s request. There isn’t one set of programming for generalized solutions. It’s up to you as a developer to think about the best way to solve a programming problem with all the tools at your disposal. In this podcast, we examine the pros and cons of Quickbooks integration, calendars, web enabling, the data separation model, live development, main menus, dashboards, reporting, progress bars, building solutions from scratch as opposed to using a starter solution, un-stored calculations, custom menus, backing up, organizing the relationship graph and testing scripts and calculations as you go.

https://firesidefilemaker.podbean.com/e/you-did-what-1581192795/

Share this post


Link to post
Share on other sites
AHunter3

I'm convinced that's why "anchor-buoy" has proliferated within the FileMaker world.  Somebody somewhere must have written or blogged about doing it that way and other folks just followed suit.

Share this post


Link to post
Share on other sites
Josh Ormond
  1. I'll say this, with the caveat that I am in no way an Anchor-Buoy devotee. But It does have its place.
  2. The reality is, it's about readability, and maintenance. It works really well for somethings, you just need to be aware of places where it can cause issues.
  3. There are never any great times to design a system a particular way just for the sake of design it to fit a specific pattern, at the cost of other more important factors.

The podcast noted above, has started to feel a bit too negative for my taste. Which is sad, because typically, I love listening to other developers talk about FileMaker, even when their opinions differ greatly from my own. Hopefully, they can right the ship and get on track with not shaming others so frequently.

Share this post


Link to post
Share on other sites
Michael Rocharde
33 minutes ago, AHunter3 said:

I'm convinced that's why "anchor-buoy" has proliferated within the FileMaker world.  Somebody somewhere must have written or blogged about doing it that way and other folks just followed suit.

I'm going to have to disagree with you on this one; while A-B is not perfect, it makes it significantly easier to manage the relationship graph and avoid the complexity of a spider web. Now, I will agree that there are more table occurrences using it and that will affect performance, especially, over a WAN however the performance loss is massively insignificant compared to the ease of development and. especially, for somebody new coming in and having to figure out what is going on. Below is the RG from a project I've just taken over which was a complete mess and made me shudder. Five hours later, I had moved all of the TOs around but made no other changes. Yes, as it turned out the original developer had used A-B but I wasn't able to tell that until some considerable time later. However, at least I can now start to unravel what is going on whereas the non A-B method of managing the RG would probably have had me tearing out what little I have left.

A-B came about due to the difficulty of managing the RG and some very smart people in the community worked diligently on it. Not everybody uses it and some developers hate it but, like everything else, there's a time and a place for it.

I do appreciate you writing though and thanks for listening to the podcast.

Michael Rocharde
(303) 856 5778

RGs.jpg

Share this post


Link to post
Share on other sites
Michael Rocharde
1 minute ago, Josh Ormond said:
  1. I'll say this, with the caveat that I am in no way an Anchor-Buoy devotee. But It does have its place.
  2. The reality is, it's about readability, and maintenance. It works really well for somethings, you just need to be aware of places where it can cause issues.
  3. There are never any great times to design a system a particular way just for the sake of design it to fit a specific pattern, at the cost of other more important factors.

The podcast noted above, has started to feel a bit too negative for my taste. Which is sad, because typically, I love listening to other developers talk about FileMaker, even when their opinions differ greatly from my own. Hopefully, they can right the ship and get on track with not shaming others so frequently.

Josh, I'm truly sorry that you feel that way. There was no intention and never has been to shame anybody; all we've ever tried to do is have interesting discussions about working with FileMaker. Both John Mark and I have very different opinions about very many things and neither of us are afraid to voice those opinions. It doesn't mean to say that we are right or wrong; they're just our 2¢. Hopefully, you'll continue to listen and enjoy future podcasts.

Michael Rocharde
(303) 856 5778

Share this post


Link to post
Share on other sites
AHunter3

re: Anchor-Buoy,  I know it has its proponents.  I suppose I, too, am guilty of saying negative things about a developer technique that I think is poor.

 

But I'd like to point out that defending Anchor-Buoy on the grounds that it's an improvement over a snarly spider-web mess is kind of like defending autocratic dictatorship as a political modality in the grounds that it beats heck out of complete chaos and disorganization.  In other words, in both cases it's not like those are the only two options.

My relationship graphs are simple "modular".  If I a table of Clients and a table of Jobs and each job is associated with a client, I connect the two tables once.  The relationship works in both directions as is.  I do NOT create one table occurrence called "Jobs_from_Clients" and link that one to the Clients table, then create a table occurrence called "Clients_from_Jobs" and link it to the Jobs table, dragging the two duplicative table occurrences to the right and having the native tables jammed against the left margin.  I sure as heck don't end up with hideous TO names like "Inventory__from_Tasks_from_Jobs_from__Clients".  Monstrosities of that nature with even worse naming conventions tend to proliferate within Anchor-Buoy.  Redundant TOs sprawl.  Massive amounts of structure exist for no legitimate reason, and it all gets touted as if any strategy other than Anchor-Buoy is somehow known to be inferior.  

 

[/rant]

Share this post


Link to post
Share on other sites
Michael Rocharde
On 2/16/2020 at 7:55 PM, AHunter3 said:

I'm convinced that's why "anchor-buoy" has proliferated within the FileMaker world.  Somebody somewhere must have written or blogged about doing it that way and other folks just followed suit.

Good points, all.

 

 

Share this post


Link to post
Share on other sites
Josh Ormond
40 minutes ago, AHunter3 said:

My relationship graphs are simple "modular".  If I a table of Clients and a table of Jobs and each job is associated with a client, I connect the two tables once.  The relationship works in both directions as is.  I do NOT create one table occurrence called "Jobs_from_Clients" and link that one to the Clients table, then create a table occurrence called "Clients_from_Jobs" and link it to the Jobs table, dragging the two duplicative table occurrences to the right and having the native tables jammed against the left margin.

Most, well implemented, Anchor-Buoy is as you describe...modular. I will say this, I am a proponent of not creating excess TOs, however, there are also times where it's necessary from an ease of maintenance perspective and from a performance perspective.

Your Clients and Jobs example is a gross-over-simplification of the problem. I do get what you mean, but in a large complex system, separating TOGs from each other can have a big performance impact, even at the cost of duplicating some pieces of the graph. And again, I'm not talking about unnecessary duplication. Duplication with intent.

Make it as simple as necessary, but not any simpler.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

Terms of Use