I’m in the process of converting portals into tab panels. However, there’s one visual characteristic that puzzles/bothers me. When necessary, portals have the ability to reconfigure the size of fields to make room for scrollbars. Tab Panels don’t. That is, unless I’ve set up my Tab Panels incorrectly.
If I configure the fields to take up the full width (no allowance for the vertical scroll bar), then a horizontal scroll bar turns up when the vertical scroll bar appears, something I’d like to avoid.
I’ve set the anchors for the “Local” field for “Right”. Doesn’t make a difference.
on a portal you have a property to disable sorting (when clicking on the columnheader) and
disable: reordering of the columns,
and disable resizable of the columns.
I can’t think of too many instances in which I’d NOT want sorting. I’ll push that into my back memorybanks for that rare occasion I don’t want sorting – use a portal instead of a tab panel.
Mostly on invoice-lineitems, you don’t wanna sort.
Because the customer does sort the line-items itself by deciding which line to type first. If you have sort enable, and they push on the endprice button, the complete invoice becomes a mess.
I’m interested in this discussion because I like how portals come with sortable, re-orderable, re-sizable column headers with no work at all. However, I’ve been warned by an experienced Servoy developer to avoid them all together. I haven’t yet been given a good reason.
In the meantime, how do I easily make emulate the above features with a tab panel? I know I could define actions for each of the column headers, then write some code, but am I missing a way that makes it easier?
BulldogBen:
Thanks so much, that’s a great function and has saved me loads of time. Especially now I’ve found the titleText property so I can label my columns.
Portals just never seem to be as responsive as a table within a tab panel which is a deal breaker with heavy data entry. (i’m using an old version of servoy so this may have changed)
The methods they contain are for the parent form not the native table they are based on, unlike table views. This may be limiting, as you are always programming through a relationship.
You can’t put related fields within a portal other than those specified by the relationship. For example I am showing table B data (lineitems) within a form from Table A. But Table C has a relationship with Table B also and i want to show a particular field from table C in the portal. With a table view you can show whatever related data you want within the table.
You are always limited by the portal relationship, but with a table you can use a relationship or also show data with a search making it much more flexible.
As a general rule i don’t use portals for data entry. Only for displaying related data as its saves creating a form. And even for this I am changing all my portals over to the “table bean” datasets whch is a vastly superior option again
most of those points are not valid anymore for 5
1> this seems weird to me because underneath it is just the same component
2> this is true, but programming through the relation ship could be better anyway (so that you are sure that you have the right foundset)
3> in 5 you can go deeper, but yes for portals this is not fully supported (yet).
BulldogBen:
I’ve heard a few times to avoid portals and use tab panels instead, briefly why is this?
Not so much a reason to avoid, but a very big ‘pro’ for using tabpanels is the fact that existing forms can be re-used vs. portals where you have to define the available fields over and over again (including other properties that apply to these fields).
jcompagner:
most of those points are not valid anymore for 5
1> this seems weird to me because underneath it is just the same component
Why to have these two components if they are same component underneath? I guess it’s because of legacy and to support solutions that are using portals. However, I think that there is a consensus to get rid of portals little by little - and just keep one of these two components… Just a something to keep in mind - in IMHO
because the work differently?
portal can be made way quicker, there could always be cases where they are useful.
That we internally use the same java components as much as possible is just reuse of code and easier to maintain and improve both at the same time
Thanks for all the replies, I’ve got a good feeling for when to use each now. There are certainly cases in which a portal is much quicker and easier to produce, so I won’t totally discard them.
ptalbot:
You can have sortable, re-orderable, re-sizable column headers with tabPanels without any code, just put a form in it in TableView mode.
I tried to “put a form in it in TableView mode”, but i have only the option “Table view (locked)” and with this it seems not to be possible to resize a column.
Or maybe it has to do with the following:
I use solutionModel.getForm(), and then enhance the form with the required fields, then show with application.showFormInDialog()
