Container tabpanel

Discuss all feature requests you have for a new Servoy versions here. Make sure to be clear about what you want, provide an example and indicate how important the feature is for you

Container tabpanel

Postby Riccardino » Sat Sep 01, 2007 2:55 pm

I love tabpanels.
But sometimes I need something able that behaves the same way of tabpanels, but where I can simply put stuff like portals, fields, images etc without the need of creating new forms.

Anyone agrees?
ciao, ric
User avatar
Riccardino
 
Posts: 911
Joined: Thu Apr 24, 2003 11:42 am
Location: Ferrara, Italy

Postby Jan Aleman » Sat Sep 01, 2007 6:22 pm

What would you say are the top-3 benefits over just creating a new form?
Last edited by Jan Aleman on Sat Sep 01, 2007 6:37 pm, edited 1 time in total.
Jan Aleman
Servoy
Jan Aleman
 
Posts: 2083
Joined: Wed Apr 23, 2003 9:49 pm
Location: Planet Earth

Postby Michael Mooney » Sat Sep 01, 2007 6:31 pm

Ric,

Sure ... I often (if I can use the term "often" being fairly new to Servoy - less than a year!) use a "container" tabpanel for precisely what you describe: a place to put other things that need to be wrapped and contained and easily replicated with definable GUI boundaries and characteristics. I suppose one can always use a "junk" form that has no other purpose in life except to form a required foundation for tabpanels (this is what I do if building reusable "widgets" that would house, for instance, a number of abstracted control and navigation objects).

The larger question that is raised through your question is whether there is a fundamental system-level architectural requirement (or not) to bind a tab panel to a form. Perhaps there is: I don't know how Jan and others at Servoy Engineering have architected this piece in their foundation level classes, low level event handlers, super classes and sub classes, etc. It would be nice to have, as an option, the ability to create a tab panel without a parent form. But only Engineering can tell us if this is a reasonable or engineering-burdensome idea at this stage of Servoy product development. After all, it does mean potentially disabling a host of other available features once a parent form has "disappeared" and what if one wants to add a field later on?

But, I agree: I have, at times, wondered why one needs to bind to a form if there is no intention to use it as a form container. I would second this concept if it doesn't create a domino-effect upon other functionality or a huge amount of re-engineering time.

After all, resusable and abstracted "widgets" that are well-contained yet appropriately open/exposed are the building blocks of SaaS and business objects.
Michael Mooney
 
Posts: 269
Joined: Thu Apr 12, 2007 2:26 am
Location: Canada

Postby Riccardino » Sat Sep 01, 2007 6:49 pm

jaleman wrote:What would you say are the top-3 benefits over just creating a new form?


Suppose I have a form with 3 different portals (I don't want any form for those informations, so portals are perfect for that), then 25 fields that I want to split into several areas.

Having such a tool I could create a tab, place every portal in a single panel (if needed) and arrange the fields in order to aggregate them according to common criteria (say GENERAL, ADMINISTRATIVE and STATISTIC informations, for instance).

In short: less overhead (no other forms required), quicker setup (you don't have to setup a form: just take the object and place in the tab), maybe faster loading, since the informations of a portal placed on a hidden tab don't need to be loaded with the main form, but only when the tab is selected.

I know there are ways to do that with Servoy, but all of them I can require more work. And I'm a lazy guy...
ciao, ric
User avatar
Riccardino
 
Posts: 911
Joined: Thu Apr 24, 2003 11:42 am
Location: Ferrara, Italy

Postby Riccardino » Sat Sep 01, 2007 6:54 pm

Michael Mooney wrote:Ric,

Sure ... I often (if I can use the term "often" being fairly new to Servoy - less than a year!) use a "container" tabpanel for precisely what you describe: a place to put other things that need to be wrapped and contained and easily replicated with definable GUI boundaries and characteristics. I suppose one can always use a "junk" form that has no other purpose in life except to form a required foundation for tabpanels (this is what I do if building reusable "widgets" that would house, for instance, a number of abstracted control and navigation objects).


But do you place multiple object in the form and the control their visibility and coordinates or do you have a different technique? I'm asking because I want to be sure we're talkin' about the same problem.

Michael Mooney wrote:
But, I agree: I have, at times, wondered why one needs to bind to a form if there is no intention to use it as a form container. I would second this concept if it doesn't create a domino-effect upon other functionality or a huge amount of re-engineering time.



If dev team provides me a different object, just to avoid the risk of comprimising the current tabpanel architecture, is perfectly ok for me. :-)
ciao, ric
User avatar
Riccardino
 
Posts: 911
Joined: Thu Apr 24, 2003 11:42 am
Location: Ferrara, Italy

Postby Michael Mooney » Sat Sep 01, 2007 7:28 pm

Ric,

I would not typically run with a heavily loaded form where I hide/display objects. So, form re-use is limited to where there is a discrete set of related operations. So, yes, I do end up with extra forms without a lot of things to do in terms of "being a form". However, in actual practice I don't have a lot of these since adequate abstraction of operations and functionality will eliminate the need for a bunch of redundant objects.

Jan,

Not sure if you are chatting with Ric or me but here are my thot's:

1. More intuitive for a developer. A form that contains only operational objects (like buttons) doesn't feel like a form. This is a conceptual hurdle I personally had to get over. I wrestled for several months with the notion of having to create a form when I really didn't want to perform standard form things. I had always felt that there was some degree of conceptual mis-match here (and it may be just me :? ). I note that some of the dialogs that plug-in developers have created touch on this area as well.

2. Forward looking, I am wondering about Servoy architecture for other plugins and other java objects. There is a great benefit (for Servoy and Servoy customers) to being able to leverage other commercially available java plugins ... and it seems to me that a container tabpanel object that has no other purpose in life except to house other objects is a natural way to go here. Take a gantt chart or calendar plugin, for instance. Yes, it will likely need to access form level functionality (e.g. - controller level methods and Database Manager node). But there may (or may not) be a parent form naturally associated with the plugin. Or, take a nice looking Clock (digital/analog). It really doesn't need a whole bunch of controller/form things going on. It simply needs to exist (as a bean) or a well-contained plugin/bean within a tabpanel (the tabpanel supplying gui boundaries and a few other attributes).

3. The container tab panel would serve as a broker and intermediary to application level events. There is a more natural association here than through a form (which has intrinsic binding to one table). For example, let's say I wanted to have a few properties of a container object like AcquiringFocus and LosingFocus. Then I can easily fire methods when moving from a group of associated objects (within the container) to another group of associated objects. Or, in a SaaS environment, let's say I want to sell a cluster of objects that do such-n-such then the container object becomes handy for grouping, management (and marketing) or chaining together SaaS business objects. By chaining objects I mean once one object group has done it's thing then control is handed off to the next logical object group depending on what took place in the immediately preceeding object group (or "container" if you prefer).

Anyway, just a few thot's on this topic ... "thinking out loud" as it were!

Best, Michael
Michael Mooney
 
Posts: 269
Joined: Thu Apr 12, 2007 2:26 am
Location: Canada

Postby pbakker » Mon Sep 03, 2007 3:01 pm

Hi Riccardino,

Just to make sure I understand what you want:
You want to be able to create a group of elements that you can hide/show and move all at once, preferably with 1 line of code. Currently, to do this, you need to place the group of elements on a separate form, that you then place in a tabless tabpanel and control them through hiding/showing/moving the tabpanel, right?
What is the reason you also place single portals into a tabPanel? What extra's does that give you compared to just placing the portals on the main form?

Hi Michael,

When you like to build widgets inside Servoy, we need to provide you with the tools to do so. Currently, you have to define a form as a container for the GUI of your widget and then on the form you can define all the behavior. If we would have to provide you with the tools to build a widget that is not based on a form, it would mean, in my opinion, duplicating all the functionalities that allready exist on forms, we would only have to take some out. So, the only difference between your widget container and a form would be the binding to a table/foundset and all functions that relate to that. That sounds like quite a complication of the development environment, while you do not gain anything extra in the process. Or am I missing something?

Paul
pbakker
 
Posts: 2822
Joined: Wed Oct 01, 2003 8:12 pm
Location: Amsterdam, the Netherlands

Postby Riccardino » Mon Sep 03, 2007 8:49 pm

pbakker wrote:Hi Riccardino,

Just to make sure I understand what you want:
You want to be able to create a group of elements that you can hide/show and move all at once, preferably with 1 line of code. Currently, to do this, you need to place the group of elements on a separate form, that you then place in a tabless tabpanel and control them through hiding/showing/moving the tabpanel, right?
What is the reason you also place single portals into a tabPanel? What extra's does that give you compared to just placing the portals on the main form?


Let's say I have a form with 5 different portals: they're actually cluttering the form (and giving the user a confusing experience).
But those portals only show statistic informations, so I actually don't need any form for them.
My intent is to place them in a component that allows me to have a cleaner presentation of the form itself. So I thought a "container" tabpanel should do the trick:
do you have a set of buttons? Place them in a tab. If you have another set, you can place 'em in another tab and switch between them with a line of code.
Do you want to organize the space and group similar informations? Place them in a tab and you're done.

I hope a gave you the idea :)
ciao, ric
User avatar
Riccardino
 
Posts: 911
Joined: Thu Apr 24, 2003 11:42 am
Location: Ferrara, Italy

Postby Michael Mooney » Mon Sep 03, 2007 9:37 pm

Paul,

Currently, you have to define a form as a container for the GUI of your widget and then on the form you can define all the behavior.


Why not have a tabpanel acting as the container instead of the form?

If the tabpanel serves as a container, then:

1. The container (e.g. - one tabpanel with one hidden tab - tabOrientation) contains form-independent objects (per Ric's comments) or a form-dependent object (at present, a form)

2. The container (multiple tabs on a tab panels) may have form-independent objects or form-dependent objects.

Yes, I agree that there would need to be some low-level work to manage whether a particular tabpanel container has database service requirements or not. This would require an internal class to decide whether a given container (tabpanel/tab) can access database objects (controller classes, etc) or not. In terms of the development environment it would only be a property setting on a tabpanel - I personally don't think it would complicate the development environment for Servoy developers.

I can't make ServoyWorld this year but I would venture to say this is worth at least a discussion over a glass of beer to see if there are any/enough market/engineering benefits to this approach. Perhaps there are other options such as enhancing Dialogs with with additional variable typing and support for multiple instancing. I certainly recognize that much work has already taken place surrounding the foundational form-as-container-approach ... personally, I can't really say at this point whether one approach or the other seems "best" to me ... I simply don't have enough understanding of the internal class and architectural assumptions of Servoy at this early stage.

Best, Michael

ps, Ric: I had the same questions that Paul did regarding the 5 portals. Would not the "statistic informations" require some degree of database access? Paul: Ric is touching on my earlier comments on business objects and flow between them:

do you have a set of buttons? Place them in a tab. If you have another set, you can place 'em in another tab and switch between them with a line of code.
Michael Mooney
 
Posts: 269
Joined: Thu Apr 12, 2007 2:26 am
Location: Canada

Postby Riccardino » Mon Sep 03, 2007 10:32 pm

Michael Mooney wrote:ps, Ric: I had the same questions that Paul did regarding the 5 portals. Would not the "statistic informations" require some degree of database access?


I have probably not been clear enough: sorry :)

Since a picture's worth of 1000 words, here attached an example of a form that would take advantage of this functionality, turning this:
http://www.morninger.it/download/immagi ... Before.png
into this:
http://www.morninger.it/download/immagi ... /After.png
ciao, ric
User avatar
Riccardino
 
Posts: 911
Joined: Thu Apr 24, 2003 11:42 am
Location: Ferrara, Italy

Postby Jan Aleman » Mon Sep 03, 2007 10:48 pm

with 4 forms that would take about 12 minutes of work. Forms are containers of elements. Why not use them? It's quick, easy to maintain and flexible.
Jan Aleman
Servoy
Jan Aleman
 
Posts: 2083
Joined: Wed Apr 23, 2003 9:49 pm
Location: Planet Earth

Postby Michael Mooney » Mon Sep 03, 2007 11:05 pm

Ric,

While I don't know Italian :) I wonder if some re-arrangement of GUI elements and grouping of information, what-goes-in-what-tab and that sort of thing might resolve some concerns?

Personally, I often finds it helps to begin with pen and paper and sketch out what needs to appear on a given form or set of forms. This helps guide me in terms of screen development. This exercise (information architecture) can be a bit tedious (and demanding!) but it sure helps when it comes time to cut code and design screens. I have also discovered, as a pleasant surprise and secondary benefit, that this exercise helps me discover the correct choice of technical tools and screen objects.

For instance, on your "before" graphic, how about containing some of the major "elements " (like portals) within a tab index or a tabless tab panel (with embedded forms) to help provide a seamless switch and visually pleasing movement back and forth (from "before" to "after")? I personally much prefer the use of a form within a tabpanel as compared to a portal.

For e.g.:

1) Tab panel to contain the "Patient Profile or Statistics" area
2) Tabpanels to contain the 4 or 5 forms - these are contained within 1)

I am just getting ready to post this and I see Jan has already commented as well!

Michael
Michael Mooney
 
Posts: 269
Joined: Thu Apr 12, 2007 2:26 am
Location: Canada

Postby Jan Aleman » Mon Sep 03, 2007 11:15 pm

Sounds like we'll have to reserve a whole night at the bar at 'world to talk just about tab-panels and containers! Containers containing drinks will be excluded from the talks. I hope you can still adjust your plans Michael and join! It's only 6 hours from Toronto!
Jan Aleman
Servoy
Jan Aleman
 
Posts: 2083
Joined: Wed Apr 23, 2003 9:49 pm
Location: Planet Earth

Postby Michael Mooney » Mon Sep 03, 2007 11:22 pm

Jan,

Love to join you all except that I have promised my dear wife of 23 years a holiday (which is already booked) as part of our anniversary! We are booked for this at the same time as Servoy World in Eastern Canada (hmmm ... you did say only 6 hours 8) )

So, I must do a Heineken by proxy! Hope to catch you at the next Servoy event (or else find an excuse to get out to Amsterdam - I hear it is a lovely and fine city).

Michael
Michael Mooney
 
Posts: 269
Joined: Thu Apr 12, 2007 2:26 am
Location: Canada

Postby Riccardino » Tue Sep 04, 2007 12:34 am

jaleman wrote:with 4 forms that would take about 12 minutes of work. Forms are containers of elements. Why not use them? It's quick, easy to maintain and flexible.


Give a portal a little form and it will ask you a whole solution... :-)

I know it would solve the problem, but if I have to create a form for every portal I want to keep in order, the portal itself becomes useless: I can set the form as a table and access it via a relation. Am I correct?
ciao, ric
User avatar
Riccardino
 
Posts: 911
Joined: Thu Apr 24, 2003 11:42 am
Location: Ferrara, Italy

Next

Return to Discuss Feature Requests

Who is online

Users browsing this forum: No registered users and 17 guests

cron