Réaliser une Master Detail View
[OBSOLÈTE] : FileMaker 17 intègre cette fonctionnalité nativement.
Depuis —presque— toujours, FileMaker propose trois vues différentes sur les modèles : les formulaires, les listes, et les tableaux. Or bien souvent, un mélange des deux est bien pratique pour pouvoir simultanément parcourir une liste d’enregistrements trouvés, et visualiser les détails de l’un d’entre eux en particulier, notamment pour l’éditer : l’interface Master/Detail ou Master Detail View.
Ce type d’interface est archi-présent sous iOS, et l’était déjà dans la version desktop de Mail, comme d’Outlook d’ailleurs. Bref, c’est une interface typique que FileMaker ne propose pas nativement.
Il se trouve que depuis quelque temps, plusieurs de nos clients de coaching nous demandent de l’aide sur cet aspect, et nous ont appris qu’il existait des techniques très complexes -et honnêtement pas très performantes- pour faire cela. Nous avons même reçu une candidature d’un développeur (excellent au demeurant) qui précisait sur son CV maîtriser le « Master Detail View » !
Pourquoi faire simple ?
… tout ceci à notre grande surprise, car nous réalisons ce type d’interfaces depuis très longtemps, et qu’il ne nous semblait pas que cela demande une expertise particulière. Au point que nous n’avions même jamais pensé à en faire un post de blog!
En réalité, jusqu’à FileMaker Pro 13, c’était un tout petit peu plus complexe que cela. Il fallait utiliser une fonction personnalisée (qu’on pouvait notamment trouver chez Agnès Barouh). Désormais, rien de tout cela.
Voici donc une petite explication sur une manière simple et efficace de créer un Master Detail View en FileMaker, qui ne limite pas le nombre d’enregistrement à afficher, et qui est tout aussi performante sur un réseau WAN que sur le LAN. Attention, si vous aimez les longs scripts et les déclencheurs dans tous les sens, vous allez être déçus 🙂
Téléchargez le fichier de démo ici : 
1MT_MasterDetailView.fmp12
Concernant la video, si vous savez déjà ce qu’est une Master/Detail view, vous pouvez vous rendre directement à 2:40.
If you already know what a Master/Detail view is, you can start the video at 2:40
Create a ‘native’ Master Detail View in minutes
[DEPRECATED]: this feature is built in FileMaker 17
Since early days, FileMaker has been providing two, then three different types of view: form views, list views, and table views. Still, the appropriate interface, the one you often really want to offer to your users, would be a mix of a form view and a list view. The list then allows the user to quickly scroll through found records and browse to the one he/she wants to take a closer look at or edit. This type of views is called Master/Detail View or Master/Detail Interface.
This type of interface is more than common on iOS, and was already in the desktop version of Mail or Outlook… The short story is: it’s a very common and appreciated interface, but FileMaker does not have it natively.
During the past weeks, several customers to whom we provide coaching asked for help on this specific issue, and we discovered that there were very popular techniques, but we found extremely complex and not really performant, especially on a WAN network.
Why make it simple?
That was to our surprise, because we’ve been designing such interfaces for years, and we didn’t think it required specific skills. To such an extent we hadn’t even thought it was worth a blog post!… until a customer, a renown developer said this was definitely worth sharing.
The truth is, until FileMaker Pro 13, the technique was slightly more complex. It required a custom function, among the fantastic ones shared by Agnès Barouh. But now, it’s even easier (and more performant)
So here is an explanation on how to create a simple and efficient Master/Detail interface, not limited in the number of found records it can display, and absolutely usable on a WAN network. Warning: if you like long scripts, and triggers everywhere, you might be disappointed 😉
Because the English version of our almost new website is still not available, you might have lost contact with us. Here are the next most important steps in your life 🙂
- Download the demo file here: 1MT_MasterDetailView.fmp12
- Follow us on twitter
- Check out our brand new FM AuditLog Pro 2.0
UPDATE: Bruce Robertson added a valuable comment below about the lack of sorting feature in the showcased implementation. So if you really want to sort the list view (portal) like the found set (which sounds weird to me in terms of usability, but let’s not question this here), here is a different version taking advantage of the fact that whatever the method is, you will need a ‘manually’ (button) triggered script to reflect the sort change in the interface (at least to my knowledge).
And as with other solutions I saw, when it comes to sorting, you’d better work with smaller found sets (or a limited portal row number). For this purpose I added a button to find only approx. 1000 records, but I left all data so you can have fun with larger found sets.
Download this implementation with sort capabilities: MasterDetailView_sort.fmp12
So much fun! I really love this kind of tips. Thank you.
Neat technique. Given that this is a bit of a hack and does something that FileMaker shouldn’t allow, can we count on it working in future versions?
Hi,
it has ‘always’ worked. Even in FileMaker 6 and older (used this to see records with a value below the average for example). It’s only the relationship graph UI that prevents you from drawing the relationship. It’s the kind of helpers that can drive a developer nuts (like, say, the fact that you need to have records in a table before you can define an import order that updates record in a script), but that beginners find helpful.
And if one day it was not possible anymore, it’s easy to create an unstored calc field (= summaryField) and use it in the relationship. But I think the probability is really, really low.
I set the global using summary field, I just never thought about using that as the left part of the join like you did. That certainly saves many steps. So I think your method is superior, but I think it might also perform better, just wondering if you knew if it performs better. I’ll test out the performance. Thanks for your response.
I like it. Any idea of how it performs in comparison to using a global field as the left side of the join? In the past I’ve set a global field with the set of ids of the found set, but I’m wondering if this technique might perform better since globals have some issues with how screen refreshes are decided by the filemaker engine.
Hi,
The question is: how would the global field be updated?
On record load? Doesn’t work with Show all.
Anyway it would have to be scripted, and I don’t see the need here.
Well – it is OK; and simple. But if you sort the records, the portal does NOT reflect the actual order of the records. So you’re always bouncing all over the portal. as you move from one record to the next.
The proposed method has the advantage of being very simple and fast compared to other proposals. It is true that the absence of sorting options in the list can be a problem in many situations.
If the user sort the records in detail model, the list is not sorted. If the list is sorted, the detail is not necessary. This technique cannot provide sorting synchronisation between details and list.
But it is possible to give to the user a sorting system with this technique. You must use sorting buttons. As you would in a standard list format, but rather than sorting the script call by the buttun will change to another portal. You have to use as many tables/portals you want different sorts. Each portal is placed on a different panel and when the user clicks the sort button panel is changed. It’s pretty simple to set up and adds a sorting system. If the toolbar is not accessible to the user, or if the user do not use the sort menu this technique is transparent. English is not my mother tongue I hope it does not seem too.
Well; we disagree. The other methods demonstrated for Master Detail natively handle whatever sort order the user has selected. No multi-portals required.
As List Of follows the sort order of the records, so it could be possible to find a way that a record can calculate it’s index in the List, and sort on that field. Not sure about performance, to be tested.
I searched without finding.
If we need to coordinate all the «sorting» scenarios, the method based on virtual lists is the only one I know. As against it is slower and we must limit the number of records. I have a solution with 21 «Master Details» layout. All user from 7 departments love «Master Details» put complain about limitation the limitation of records.
So if you find …
Thanks for this, Fabrice. Wonderfully simple!
Playing around with your *original* file a bit (i.e., not the « Master Detail View Sort » version that you later posted in response to Bruce’s comments), I made an interesting discovery relevant to sorting. At least it was a discovery to me.
First, I figured that I’m generally less interested in keeping the portal sort in sync with the found set sort. If you hide the status toolbar so that the user doesn’t see whether or how the found set is sorted, then sort your portal (which is all the user really cares about), the « sync » problem goes away. 😉
But my discovery: I added a hard-coded sort to your master portal (nameLast; nameFirst). I made no other changes or additions to your file whatsoever. Of course, upon returning to Browse mode, the portal was appropriately sorted and the found set was unsorted. As soon as I clicked any portal row, however — thus invoking your single GTRR script step — not only does the record focus move to that record as expected, but the found set adopts the sort order of the portal! The status bar changes to tell you the found set is sorted. You can Unsort your found set, click a portal row, and the found set goes right back to sorted. To me, this is as perplexing as, and maybe even more so than, your discovery re setting the GTRR step to « Show related records only » in order to keep the portal from scrolling back to the top.
What I still wonder about is how the sorted portal performs over the WAN, compared to the unsorted version. (I was testing strictly locally, so far.) If performance is good, then it suggests that cracking the sort problem may be within reach, while keeping (most of) the simplicity of your original file. (Mind you, you’d still need several hard-sorted portals on, say, slide panels, in order to support multiple sorts, but I could live with that.)
Anyways, thanks again for posting this. It is sure to extend our collective toolbox in important ways.
Hi Mark,
thank you for your detailed contribution!
The funny thing is that this sorting property of GTRR through sorted relationship or sorted portal is something I wanted to comment about in the original video, but I don’t remember (really, aging is a pain) why I was using it some years ago. I remember using this a lot in FM7 or 8, but I have no clue why! 🙂
About the sorting issue, you put it in better words than I did: the ‘problem’ comes from the record navigation part of the toolbar, which IMHO does not really fit into the master/detail view idea.
If you take Mail for example, you can sort the list by some predefined keys (date, sender, subject…), but there is no « Custom sort », and no « Go to previous/next » other than the arrow keys, which operate on the list. There is not such a thing as a « sorted found set » : there is a sorted list that allows you to browse to a certain record.
Regarding the list matching the found set: let’s consider the case FOR doing this.
Using the fields in the detail section of the layout you can now:
Perform a find
Use contextual features (find matching; constrain; extend)
Use contextual sort by clicking in a field
Use the standard Filemaker sort dialog.
In all these cases, all standard FileMaker features (including the status area and next/previous record) are functional.
The only dysfunctional element is the « master » list portal; because it does not match what the user chose to do, with standard FileMaker feature set.
I suggest that it is important that it always match the found set.
If not – then it might be good to think about exactly what a « master detail view » really is.
If the portal should be independently sorted, then why isn’t the detail area of the layout a selected-record, established by setting a global selector field. And once you’ve done that – what happens to all the native features?
Just for saying wonderfully simple ! Thanks for that. Did it and work perfectly.
Very simple. Thanks for the video. I’m pretty new to filemaker and I have found the explanation easy to follow and understand.
In the footage you show an example with a « filter » field and a « new record » button. How could it be implemented in your solution?