Instead of a layout with multiple tabs, many people do the same with a little trickery. Multiple layouts, where each tab 'panel' label is just a button that takes you to that layout. The layout you are on has a tab panel 'label' that's in bold font, or a different color, etc.
If all the layouts are identical to the pixel, it gives the impression that you are just switching tab panels instead of switching layouts, then you don't have one layout with 8 tab panels supporting 8 portals.
Thank you. I'm aware of this method as many of the examples use it. I just don't like it personally and so I'm wondering if there are any performance trade offs of using tabs with portals instead of multiple layouts.
There can be, but mainly if you have filtered portals as the portal filter expressions have to be evaluated for each and every related record. So you can probably get this to work as long as you avoid filtered portals. There are a lot of possible variables here, so your best way to get an answer is to try setting this up and see for your self. And keep in mind that in real use, you can end up with 1000's more records than your testing unless you use script that generate large quantities of test records for you or you can import such data from an existing system for testing purposes.
A bigger issue (and the real reason why many developers use separate layouts to simulate the tab control in this type of situation) is that all your portals will have to work from the same "table context" where you can base each separate layout on a different table occurrence--which can make for a simpler overall design of relationships, scripts, etc.
Thank you for your comments. I'm guessing that all the portals would be filtered via portal filters.
Do the portals "evaluate" when the layout loads even if they are not visible on the layout yet?
Yes, they evaluate. I've brought a whole system down (oops!) to a snails crawl because a portal filter was being evaluated over several million related records...
They key is to examine what is the likely upper limit to the number of related records. You can often use match fields in the relationship to reduce the number of records that need to be filtered--possibly eliminating the need for a portal filter in the first place.
Hmm.. I have been using the type of tab control Vinny is tallkng about, and was using a filter to restrict the portal records to only recent ones (by created date) thinking i would save the system having to load all those records...
Was that a mistake?