Under the hood question

[Ugo DI LUCA]

Hi,

Despite some information at the latests DevCons, I'm still having doubts about how really data is moved from the host to the local client.

Very concretely, I'm having hard time determining why in certain circumstances, my solutions are quick and in some others very, very, drammaticaly slow.

At one point, and that's where I am now of my conclusions, I have a tendency to believe that the whole data environment is "downloaded" to the client whenever it is needed. Fmi states that what is useful is downloaded at once to the local temp file, but I still don't get what exactly is passed to the client.

From my experience and understandings, I would say that everything necessary in the evaluated context ( data and related data ) is passed, which would then explain while it is so slow when using A/B ( anchors & Buoys ) where everything gets transported to the anchor. But is that it ? What if I change a firstname on a record, what gets downloaded exactly ? The record, the changed data, the whole record and all data necessary for its calculations and evaluations ?

Thanks for any input or debate, I would like to see the light and determine a design strategy for my layouts and relational structure.

I already moved miles away from A/B, implementing real bi-directional relations and using layouts for what they are designed for, multiplying table occurrences anchors within a same TOG, separating calculations from the rest of the data in order to lessen recalculations and evaluations. Since I did that most of my apps are behaving correctly now, which helps me think that the more a context is busy.

With respect for users and other developers with whom I was lately commenting about these strategic moves, I would like to argue with more that simple impressions.

So, anybody here with some information is welcome to "debate" or contribute to my current doubts, with this central question. What is really passed to the client, how and when does it happen ?

Thanks. I hope this will help others in their approach to developing, I thought this forum was the right place for such a discussion.

Ugo

[David Jondreau]

I already moved miles away from A/B, implementing real bi-directional relations and using layouts for what they are designed for, multiplying table occurrences anchors within a same TOG, separating calculations from the rest of the data in order to lessen recalculations and evaluations.

Could you talk a little more about this? Are you saying you use separate TOGs for calculations than for layouts? How do you structure your relationship graph?

Thanks,

DJ

[Søren Dyhr]

Ugo It's hopefully needless to direct you to these?

http://fmforums.com/forum/showtopic.php?next_end/1/fid/91/tid/174479/

...or this debate on the content of the White-paper?

http://network.datatude.net/viewtopic.php?t=102&highlight=debi

Honestly have I never really fancied to read it thoroughly. But it's interesting that you find that Anchor/Bouy slows down things.

--sd

[Ugo DI LUCA]

Hi,

May be one day I will do a workshop in Brussels if you want to attend, I dont't have enough time on my hands to complete the White Paper I had started on the subject :

Basically, while I swear I'm still using A&B for some small projects, I moved from this approach rather quickly as it didn't addressed one of the main goal I had targetted since FM7 was born : Modular Design.

A&B is like using pedals with a motorcycle, it's just counter efficient and not adpated to FM7 relationships. By killing bi-directions, we're just refusing what probably was the major advantage brought by FM7 relational architecture. By centring everything on an anchor, we favor Layout centric design, and forget about what an application really is, logical.

So, yes, I'm using TOG of course, and I feel like a stupid when I say so. With so many concepts around, everything other than A&B would in every developer's mind leed to a spaghetti plate. And while I surely love this plate at any sauce, this is not my favourite for programming as well.

Of course, it's still impossible to implement clear modular design with FileMaker, copying a whole context with its tables and relations is still one of my dream. Nonetheless, script groupings and table copy feature helps a lot in advancing up to this stage.

One quick summary of what I'm doing that's different of what A&B is. Following Mike Harris white paper, word by word, may be even more than what he says, by considering TOG, not only as a context, but as a Data Environment, and in my case a logical Data Environement. Which finally, with some more description, that what is sales is completely separated from purchases, but that I don't handle them only based on tha Sales and Purchases tables. All what is related to a sale is tied to a "sales" context, where several TO's are used for Layouts, where direction is not determined by the developer lazyness or narrowminded ( starightminded ? ) old fashioned FM6 approach - volontarily excessive words...Am I rude Mr Frank, please Kevin I beg your pardon if so, you can still use repeaters, you know I love them too -but by the business logic.

And yes, separate TOG for calculations so that evaluation does not take place on the Interface layer. This probably lead me to add a couple of To's, but I'm still 40% down from what A&B and its duplicated context offers.

This approach allows the app to evolves according to the business ( client ) needs, as the basics of any modularity process. Well, that's what I'm doing, not sure it was really the time to give details here, I'm just satisfied with it.

But still waiting for answers on what exactly is brought to the client, when and how. And not only for finds for sure.

Thanks again for any input on the subject, and sorry if this seems more related to database relation theory. This wasn't the goal. I need some mechanics around to tell me what my engine is done with :

Edited November 24, 2007 by Guest

[FestiveEmbalmer]

Hi Ugo,

This is a topic itching for dissection. It makes me itch anyway.

Being a novice, I was quick to take available advice and switched to A/B, but it felt wrong having to duplicate relationships to recreate bidirectionality that was already a strong point in FM's design!

I have continued to use (attempt, anyway) the Anchor-buoy approach because it is a good crutch for me. It has taught me to separate features out in a way that allows me to learn how to use filemaker. It limits the variables of what could be going wrong with my structural decisions in the obvious manner of separating those decisions functionally. This thinking led me to instinctively separate out TOGs for calculation context.

But is that really what I want to be doing forever? Will that still be useful, or as useful, when I am an experienced developer?

Does anyone know of a reason why A/B is useful besides simplifying a tool that is just too powerful for our human organizational skills?

I mean, look at the solutions you design and think about how much you trust your users-how much control you give them. Ask questions like: How many ways of performing a task do I give them?

Just comtemplating that I turn around and think "Did filemaker overestimate our abilities?" with the RG? It's so tabula rasa!

And is that first link Søren gave still the way FM operates? I thought they changed that? It's scary!

And the second one needs cliffsnotes! Ok, I just need to take the time, but still. Søren's always casually throwing out links that make me LEARN scary, important things!

matthew

[Ugo DI LUCA]

Hi,

Interresting point of view indeed.

Of course, A&B bring, some simplifications in our way to think and implement relations. That's probably its main advantage, but it can become problematical when one forget that logic must be placed ahead any habit.

Though I would not conclude that A&B is simple when I see how my RG explodes anytime one request is added. Sometimes, I have the feeling I'm building a chemistry plant.

One would argue A&B is easy to read as well, specially when it comes to debug process. IMO,readability is just a matter of conventions and documentation.

Again, I am a daily user of A&B as well, it just depends on the project, the same way you can recommand one tool rather than another.

But whatever the scheme, the question remains. What really gets a solution to be quick or slow, what are the effect of TOG surfing and what exactly is loaded to the client when the user navigate from a context to another. Is it tied to what's on the layout, what's on the Table, what's on the whole context, what's changed on a record ?

If we can't get direct answers from fmi, may be some here could comment with their own experience.

Thanks again

Ugo

[Søren Dyhr]

It have striken me that I, well not deliberately ... ignore the use of "Evaluate this calculation from the context of:" but it seems like A/B diminish the use of it!

Another thing is the continuation of GTRR bug'ish behavior, both of which might tell us something about engineers in FMInc and the developers being in different solarsystems.

Well I'm willing to admit that my first example might say more about me than the tool!

--sd

[Ugo DI LUCA]

Hi Soren,

Indeed, this is probably the central problem.

What exactly is evaluated, when and how ?

If no calculation TOG has been set, A&B would concentrate any evaluation from the Anchor's context. Very practicle indeed and again some simplification brought to the developer. What consequence such a strategy have ?

This depends upon when it is evaluated. Because if this calculation evaluated in context B is dropped on a layout from context A, what happens when the window is redrawed and calculations refreshed ? And what if many calculations evaluated on other contexts are dropped to this layout ? This mixture of context evaluations must have an impact, don't you think ?

And what really happens on refresh window ? Is it that only those calcs on the window are refreshed ? Only those visible on the current tab or any data on that Layout ? Or is it that I'm talking about refreshing issues only but that every calculations necessary for the whole context is evaluated at once ? If my calculation in context A uses the result of a calculation from table B evaluated on context B, there's surely a big flaw of data involved, isn't it ?

By separatig context in more logical manners, only what is necessaty should be evaluated, that's my thinking today, and why I started with this new grouping strategy ( with many calculations contexts, symetricaly "tied" - not strictly related- to the Group ).

But I may be wrong. And as outlined on a private discussion with Fabrice Nordmann, what about tooltips, specially those calculated ? These are yet again another source of evaluation dilemna when designing interface.

Well, that's all for now, I think every idea bring another question here.

About the GTRR features, are you saying FMI designed a tool without thinking how we would use it at the end ? Optimizing it fro a fully bi-directional mono file system ? I'm not far from this conclusion too, even if all the bugs reported by Fabrice lately ( By the way ) may bring other answers and questions.

Cheers

Ugo

Edited November 22, 2007 by Guest

[Søren Dyhr]

FMI designed a tool without thinking how we would use it at the end ?

Exactly! How often aren't we in the same situation ... the customers ingenuity to think up possible flows we even havn't thought about, that actually utilize the app even better or in different way of what we expected.

It's not the first time filemaker have been caugt by this ingenuity, 5-6 year ago came someone up with the idea that the web-interface could be used for other purposes than online databases. A whole line of connector tools arrived:

https://www.productive.cc/pci_cart/FMPro?-db=PCSC_Products.FP5&-Format=productshome.htm&-Lay=CGI&-View

Using the fact that most Windows dealings are browserbased, this was ... FMI havn't forseen this!

May be one day I will do a workshop in Brussels if you want to attend

Sure! If resources etc. allows!

--sd

[Søren Dyhr]

While we're at it, do you see the same kind of problems with the utilization of the separation model, where the calc'fields all reside in the datafile, and the A/B'ing makes less of a point due to the lac of dedicated layout to anchor by???

--sd

[Søren Dyhr]

Things have developed here, the entire thread have by me been tried to get more responses, by a transfer to a forum/list where say the normalization issues are less troublesome, these people does such matters by instinct.

http://www.nabble.com/Under-utilization-of-the-context-drop-down-tf4889022.html

Unfortunately isn't the server that serves FMExperts utter reliable, and we are without messages sometimes a fortnight. So Steven Cassidy re-raised my thread here:

http://www.nabble.com/Under-utilization-of-the-context-drop-down---was-%22Experts-list-%22--p14103684.html

...where I continues my endevour to dip deeper in this issue, in this thread:

http://www.nabble.com/Re%3A-Under-utilization-of-the-context-drop-down---was-%22Experts-list%22--tf4928000.html

--sd

[Ugo DI LUCA]

Thanks Soren,

I'll move there and see what other ideas and comments are thrown.

[Søren Dyhr]

Perhaps when wrapping this thread up, is it worth to mention Corn's comments to this:

http://www.nabble.com/Re%3A-Under-utilization-of-the-context-drop-down-p14177505.html

...as well as the test Ugo had made to establish some kind of meaning with this:

http://www.nabble.com/Re%3A-Under-utilization-of-the-context-drop-down-p14210821.html

--sd