1 of 1 people found this helpful
That Help document is misleading. Tables are assoicated with the Layout, not a tab. I think they are referring to putting portals on tabs - which would allow for RELATED records from other tables to be displayed.
While it is useful to reduce the number of layouts. This approach is the wrong way to go. As David said, tab panels are for data related to the table the layout is based on. On the customer layout you might use a tab for Contacts, Phone/email, invoices, shipping addresses etc..get the idea?
One navigation method I have used used the on modify script trigger and the tab name as key to change layouts. Each layout has an identical tab set up. This makes it look like the tab is changing context and if done right is invisible to the user.
I'm afraid your right, David. Very misleading - and very disappointing after relying on it to design an application.
That's a very interesting and creative idea, Bruce. And one that I will pursue. Thanks..!
Thanks John - but hardly the 'wrong' way to go based on what a tab control should be and Filemaker's statement about what it is capable of. Tabbed designs - whether in pocket organizers or software should delimit dissimilar information not restrict them to only externsions of the same data. Selecting a tab should select a context and restricting every tab to the same context is simply absurd.
1 of 1 people found this helpful
Tabbed designs - whether in pocket organizers or software should delimit dissimilar information not restrict them to only externsions of the same data. Selecting a tab should select a context and restricting every tab to the same context is simply absurd.
Perhaps you're right, however FMP has always used layouts to control context. You have to accept what you've got and find its strengths. For those of us who were already using filemaker and not a pocket organiser, tabs were a revelation. We already had a method for switching context so we didn't need that tool. Tabs gave us the ability to manage extensions of the same data without having to recreate the layout.
Sorry to get into philosphical distinctions... I am a newcomer to Filemaker but have been a developer since the release of the Apple II encouraged me to start writing machine code for the 6502 processor. I have mainly used PHP and MySQL for online applications but recently stumbled across one produced in Filemaker and liked the look and feel. So I took a closer look and was very impressed with many of its features. So I decided to implement a project using it. I have been pleasantly surprised by its power - but also a little disappointed by some of the 'restrictions' - particularly those that seem to defeat what I would think would be the primary purpose of the feature - such as multiple tabs having only a single context. I'll learn to live with them - or find a way around them as I get better acquainted with the beast - which does, after all, provide much of the satisfaction of programming. Bruce's thought (below) is exactly what I needed to get the creative juices flowing...
But thanks for chiming in...
Philosophically speaking Tabs are a layout extender. They give you more real-estate in the same layout by layering data in specific groups.
They were not intended to perform as context switchers. The Context is defined by the TO. Since the TO can only be assigned to a Layout, not a Tab, there is no way to define the context at the Tab level.
On the other hand if you judiciously use a TOG with the correct relationships you can 'sometimes' use the current TO as the starting context for data filtered (related) thru other contexts.
Or perhaps creating a calculation in a related table that uses a context to retrieve data related in another table and show that in a Tab or portal. For example a List[ of related Teacher's] for a Student from a TO of Classes.
This is a common philosophy coming from that background. Your view of a layout is different.
...I have mainly used PHP and MySQL for online applications...
From an operational standpoint, tabs are used to separate groups of data that relate to the same subject. For instance, on both OSX and Windows, settings and preferences for a single Application are in a dialog ( like a layout ), and all of the tabs included there-in separate sub-categories of options/data that relate to that same application.
Then what would be a 'best practice' to deal with an application where the top level are two tables of companies - one customers and one vendors - with each having a related table for contacts within the company and which, in turn, has a related table containing contact information for each individual contact (a record for each email address; phone number, IM; website; etc.)?
Assuming that a tab control is limited to either customers or vendors, and a portal can nopt contain a portal, how do you deal with listing multiple contacts on a tab with the associated contact information attached to each?
I certainly like some aspects of FMPro12 - but I am struggling a little with the restrictions on tabbed layouts and portals.
Many thanks for any help and advice...
1 of 1 people found this helpful
From a data perspective, it's not necessary to have 2 separate tables for customers and vendors. For that matter it's not really necessary to have a separate table for the companies and contacts. You can designate each record as a 'Customer', 'Vendor', 'Contact' of 'Customer' or 'Vendor' with the fields in that one table.
A self-join can relate the Customer/Vendor to the indiviual Contacts. The same idea as you have with the table for contact info: an attitribute-value pair.
From there you can show related records on the layouts in a variety of ways:
- Merge Variables
- Collect the values through a looping script.
- Collect via the List () function.
- Collect via ExecuteSQL
- Global Field
- Web Viewer ( using data url )
- Regular field - like if you were bringning records into a designated Report table, that only contains data temporarily.
- Calculated field - using any combination of the above.
You have a lot of options...it just may not be readily obvious if you are used to doing things straight through a SQL query/view.
That provides a really interesting - and very useful - perspective on doing things in FMP12.
I had - very briefly - toyed with the idea of combining customers and vendors once I became aware that I could not change the context within a tab control. But a little mental shudder at the thought of such a betrayal of long-held values kept me from such blasphemy.
I really do value your advice - and will do my best to re-adjust my thinking to the new environment - which is turning out to be a stimulating experience...
Hmmm...having separate tables, with separate fields for essentially the same data is a violation of, hmmm...4th normal form (4NF), yes? (if I'm understanding it correctly...where is Theo when you need him)
Actually, having worked with a few different web developers recently...I am seeing that type of idea more and more.
But a little mental shudder at the thought of such a betrayal of long-held values kept me from such blasphemy
OMG...that's hilarious. I love it.