Portals Vs 'View as List'

[TRNET]

Has anyone used only portals for all list layouts in a project?

Usually a table will have 2 main layouts - List and Details. The List layout shows a list of items that when one is selected it goes to a Detail layout with all the relevant fields for data entry. The list layout uses 'View as List' and can be easily sorted with scripts attached to the column headers and a total can be put in the Footer or a Trailing Summary. All straight forward...

BUT, has anyone used all portals instead? What are the pros and cons?

I have setup a template that has a Menu on the right side of my layouts and using portals I can have a list without using the list view so my detail layout looks identical to my list layout.

I have to use a lot more scripting/TOs etc to do simple things like sorting or finding but it sure looks better. Will the file slow down too much with thousands of records? Is there a downside I haven't considered?

Any help/comments are appreciated.

Edited September 17, 2005 by Guest

[onthebass]

Portals are great if you wish to contain the user. Suppose you have a list of clients and there are several jobs associated with that client. The user simply selects a client and then gets a portal list based on a relationship with just the jobs for that client. No search screens needed.

List views are good for utilizing all built in FM functions, but like you said using all portals means you have to program all the functionality. You, especially, have to think about when a user leaves a portal and the portal list goes back to the first record. If you want to make sticky portals you can but they get a little complicated depending on how many variables are being used to filter the portal and if the portal needs to be refreshed.

As far as size goes, you have to do some performance tests if you are going to put summary fields from the related records in the portals. I've had good results depending on the server and network performance. Without summary fields there are no problems.

[CyborgSam]

TRNET->

Welcome to the forums!

In a FM6 solution, I wanted all the user interface in a single window, so I had to use portals to all the other files. It was a bit limiting and required some cumbersome kludges. And it was slower than I'd like.

In FM7/8 I do the same as you are doing. I want a consistent interface from one layout to the next, and I use a bar with info & buttons. I also want the interface to behave as similar as possible in FileMaker Client and IWP. So portals are the only way to go given my criteria.

[Søren Dyhr]

if you are going to put summary fields from the related records in the portals.

It's probably my lack of english grammar when it becomes crafty? But isn't it a summary field from a related table shown outside the portal ...or do you mean Sum() Count() among other aggregate-functions???

--sd

[onthebass]

It's probably my lack of english grammar when it becomes crafty? But isn't it a summary field from a related table shown outside the portal ...or do you mean Sum() Count() among other aggregate-functions???

--sd

Using the Client, Job example. Suppose each job has several records related to it in a table called "Line Items". So each job will have a Total Cost calc which will be a Sum() of the Line Items.

Then in your Clients layout (or whereever) you have a portal which on each line lists a job for that client and Total Cost for that particular job. Then outside the portal you can have a Sum() calc of all the Job Costs for that client.

If you had a list view of Clients and you wanted to know the total costs of all the jobs for all the clients you would have a Summary calc of job Sum() calcs.

So you are right I threw the word summary around loosely.