Portal Sorting Techniques

[grumbachr]

I've been searching through various portal sorting techniques. Seems most people are big advocates of using "Tabs" these days for portal sorting.

What's the next most common and easiest to implement. I've found such a variety that my heads starting to spin from all the options.

[comment]

Tabs are it, IMHO.

[Fitch]

If you must use a portal, I agree, use tabs. But where possible, consider using a list instead.

[grumbachr]

Thanks I was afraid thats what you were going to say. I know its easy but I was hoping for something that wouldn't muck up my design.

Fitch I already have List views with sorting.

I may not try to implement portal sorting in the end. I was just trying to add portal sorting as a bonus feature to my solution its not a must have.

Thanks again

[comment]

Why do you feel this would "muck up your design"? It's quite cheap to implement.

[bcooney]

At the risk of incurring much derision, we do add portal sorting--sometimes--and use the portal sorts on two fields, and we populate them with a script, etc. method. It is a lot of work.

[LaRetta]

Why do you feel this would "muck up your design"? It's quite cheap to implement.

Cheap to implement yes; VERY expensive to maintain.

[comment]

How so?

[grumbachr]

maybe i don't have to shift or move anything to add tab sorting but i know i'll have to add something. i've worked on the interface to this solution for a long time and it finally to the point were i can say i'm very happy with it. really don't want to mess it up.

Its also a lot of work. I have 6 portals with about 40 columns I want to add sorting to so that would be 80 tabs. not sure it worth all the work for something that's only a "nice to have".

And I have to agree with LaRetta they aren't easy to maintain. if you don't do them well they can look like crap, there can be a ton of graphics that if they don't match up just right can throw off the hole look and feel.

[comment]

Oh, I see: you're thinking about the demos with arrows and stuff. You don't need all that. Use an invisible tab control object, with column headers serving as buttons to switch panels. Very much like table view, in terms of user experience.

If you want indicators, you could use some conditional formatting (if placed above the tab panel), or fixed indicators (if placed inside the tab object) - but nothing should be in the tab panel headers, IMHO.

---

P.S. 40 columns in a portal??!

[LaRetta]

It is same as maintaining multiple duplicate layouts except with the added complexity of hidden tabs. Then management wants another field and I can guarantee that won't be the only change in that design. So you spend hours unhiding the tabs, adding the field (and duplicating throughout, adding two more tabs and ... by this point, ALL other methods begin to look like a cakewalk.

I understand the benefit but I all too well also understand the pain of their maintenance. If I wanted to curse someone, I'd probably have to say, "May 10 sortable columns in 20 tabs live forever in your house!"

:laugh2:

Edited March 27, 2009 by Guest

[Josh Ormond]

I started looking into this a little from Excelisys. Neat idea that works pretty good. Especially if you want to sort by multiple columns.

It's a little bit to setup...small portals are probably just easier to use tabs. Maybe it will work for you.

PortalSortExtreme.zip

[LaRetta]

If you could show a sample of what you mean, Michael, I'll change my belief about them [color:green](and be grateful). But invisible tabs with rectangle over them and leading empty tab and it goes on and on. And maybe with vs. 10 there are more tricks available. But I consider them spawned from satan, or worse ... sent to us by 'developers of a different database program' in spite.

UPDATE: In truth, I would love to fall in love with tabbed sorting. But I didn't ask for a demo of your vision in a 'prove it' way ... only that I can't imagine how they could be tolerable much less fun.

Edited March 27, 2009 by Guest
Added update and green.

[comment]

There are two issues with these methods that use a common calculation field for sorting.

The first issue is that most of them break under certain circumstances. There is a LOT more to sorting than a simple conversion of text to numbers, or vice versa. For example, in proper sorting spaces are NOT ignored, and "apple pie" comes before "applepie". Not to mention that text in French, Greek, Russian or Japanese should also sort correctly.

The second issue is that by the time you have solved the first problem, your calculation lags visibly when handling large related sets.

[comment]

invisible tabs with rectangle over them

That went out with version 9, I think. If you set tab width to 0 and border to 'none', the tab control becomes invisible AND unclickable.

Here's a demo. The 'Main copy' layout has the same tab control object before making it invisible as described above. To add a field, you'd have to do the following:

- add two tab panels and name them as objects

- add the new field and another button to all panels

- duplicate everything into the new panels

- modify the two new buttons in the two new panels

I do most of this by copy-dragging objects outside the tab control, then dragging them back into another panel.

TabPortalSort.fp7.zip

[Josh Ormond]

There are two issues with these methods that use a common calculation field for sorting.

Agreed, I haven't used it much...it depends on the actual situation. I have only used it in one solution. Accounting for all the different field types and other such issues like you mentioned didn't make it worth it for me.

But it is still good info to have, because there are instances where it works very nicely.

Do you know of any other ways to sort by multiple columns in a portal? I have been looking for an alternative.

I think. If you set tab width to 0 and border to 'none', the tab control becomes invisible AND unclickable.

Yes they do. I can't even explain how excited I got when I noticed this. It was almost frightening.

[comment]

Do you know of any other ways to sort by multiple columns in a portal? I have been looking for an alternative.

The alternatives are fairly limited, because if it's the same portal, it will always sort by the same sort order. So the only way to control the sorting is to control dynamically the contents of the field/s named in the portal's sort order. And because we want it work individually for each user, those fields must be unstored calculations.

So ultimately it comes down to (a) how good your calculations are, and (: how much are you willing to compromise. I believe I can state safely that there is no way to make it work perfectly in EVERY situation. But if, for example, you can be sure that your numbers will never exceed the range from 10^-9 to 10^9, then the calculations can be significantly simplified.

[mr_vodka]

I am going to have to agree with LaRetta on how cumbersome sorted portals on tabs can be.

Lets say for example there are 3 different layouts for different type of groups. However, the portal needs to be sorted and on each layout. The portal displays 6 fields.

That is already 6 X 2 = 12 portals for each layout

12 X 3 = 26 tabs.

Now lets say they add a new field.

1. You have to go unhide the tab panel.

2. Modify 12 Existing tabs

3. Add 2 new tabs

4. Add descending and ascending portals to new tabs

5. Repeat on layout 2 and 3.

Furthermore, on Windows, you have to start messing around with stack order of any objects to avoid flashing.

All this for just 1 portal. If you have other portals that users want sortable ( once they get one they want everyone of them done ) then repeat across the system for all portals. In the end you will find yourself maintaining hundreds of tabs.

Overall its a good technique but I have to agree that it really is a nightmare to maintain.

Edited March 27, 2009 by Guest

[comment]

I am not sure that qualifies as a nightmare, but that's just my personal opinion. In any case, the alternatives are not. So what would you prefer?

[LaRetta]

invisible tabs with rectangle over them

That went out with version 9, I think.

Yes but they still haunt me in MY nightmares. Like John, I've had more than my share. Like you, I ask what are our alternatives? Currently nothing but that only means we haven't discovered a better way yet. I think it is important to maintain our dissatisfaction in the method so we keep our minds open to new approaches as features are released AND so we don't discourage some young, bright mind from stepping in and seeing a clear easy solution that we've all overlooked.

Simply, FileMaker should have multiple-sort features on portals where we can specify several sort sequences and then select which are displayed for the User to click OR the sort dialog should allow User to enter field selections like current sort dialog (only selecting from fields within the portal).

We are only talking about one single ascending/descending sort on one single field and it takes THIS much work? Multiple sorts should be standard fare for all portals (controlled by the Developer, of course).

Oh, and I very much appreciate your file, Michael. Overall, I remain (greatly) dissatisfied with the solution (although it is the best solution out there right now). Once you allow it for Users, they will want it on every portal. Even when you give it to them, ascending/descending on every field, they will remain dissatisfied because they can't sort by multiple fields. Nobody really wins.

UPDATE: I encourage everyone to tell FileMaker you want them by going to Feature Requests .

Edited March 27, 2009 by Guest
Added update

[comment]

I certainly agree concerning the feature requirement. I really don't see why portals couldn't have a "table view" (and why they couldn't show the found set, while I am at it).

I should add that tabbed portals *do* allow sorting on multiple fields - albeit fixed ones. So you could have "Name" sorting by LastName/FirstName, and "Age" sorting by Age/Gender/LastName, for example. Yet another advantage to this technique over the calculated one.

I don't mean to discourage anyone from coming up with a better method. On the contrary: in my experience, at least, saying it's impossible is the best incentive.

[mr_vodka]

Portal sorting by script would be cool. :-)

[comment]

Just wondering: would you and LaRetta find this version less of a nightmare?

TabPortalSortExt.fp7.zip

[bcooney]

This version is much better!

[bcooney]

For the interest of completeness of this thread, here is a link to a demo for Portal Sorting using calc fields, courtesy of Excelisys.

http://www.excelisys.com/web/downloads/files/PortalSortExtreme.zip

[comment]

Isn't this the same one we had earlier in the thread (the one that breaks with "apple pie" vs. "applepie")?

[bcooney]

Duh, didn't see the post. I guess I'll delete it?

However, I was thinking about expanding this discussion to list view sorts...

[Fitch]

The way you've set up the script parameters and tab object names to handle ascending and descending sorts is a great technique. However, tracking the current sort order is not the big problem.

The big PITA comes when the customer wants to add, change, or move a column.

When a portal fills up most of the tab it's difficult to select objects and move them without accidentally jumping to another tab. I usually end up dragging the whole portal off to the side, editing, then option-drag it back onto the tab to copy it. Then go to the next tab, delete that portal, option-drag, etc. Then I go through each tab and reset the sort order. P.I.T.A. * 2 ^n (where n=number of columns).

[comment]

I do the same, except I try to drag the fields only, to eliminate the last step. Still, you're not going to convince me that sorting on an unstored calculation is better.

I hope I am allowed at least to think that I have better calculations than any I have seen. It would take very extreme circumstances to break them (like having one column in Swedish text, and another in English). But I'd rather drag fields around - especially if sorting on more than one column is required.

[David Jondreau]

My 2 cents...

I use both. When all I need is a couple of fields sorted, I use tabs. But when I need something scalable (in terms of the number of fields, not the size of the db), I use calcs.

The two common objections to the calc method, that it's slow for large record sets and doesn't handle other langauges or unusual character sets well don't apply to most of my solutions. I don't use portals when there's a large set of related records and I don't develop in other languages.

[jfcarbel]

What about using this FMButler doSQL plug-in to accomplish this. See this demo from FMButler blog.

Could each column header be a button with an associated script that changes the sort criteria via a call to the plugin? Would this not work?

In this case adding another column would be very simple and maintaince even easier. And the fact that your are using SQL to select records rather than calculations should mean performance will be better as well.

Thoughts?

[liltbrockie]

Just been reading this thread.. can NOT believe Sort Portal Row script step does not exist lol

Feature Request Filled out and sent.

[HunterBoss]

At the risk of being flamed, why is the sort function built in to the Portal Set Up not doing what you need? What's missing?

Christopher

[David Jondreau]

Dynamicism. What if you want to give a user the option of having a sorting a portal by first name or last name? That's a pretty common feature in applications.

Edited April 28, 2010 by Guest

[bruceR]

There is a variation on the multi-tab multi-portal method where only the first portal is the display portal and the other portals are used to capture record ID sets and never need to be seen. I'll try to post an example at some point. Has the potential for reduced maintenance when changes are required. There is yet another method that requires no additional portals or calcs. Yes, something like table view sort/size/arrange options within a portal would be really great, and dynamic scriptable sorts seem way overdue.