Probably been discussed before but I was wondering if anyone has a technique to minimise the number of forms shown in the solution explorer tree in Eclipse (Servoy 4.1).
I know in 3.5 there was a way to list forms under an expandable node based on the table to which they were attached - though I see that might not be appropriate now. With hundreds of forms the navigation is becoming pretty un-wieldly now with all forms expanded in a single node
I suspect using modules would be one answer but a bit of over kill just to manage a forms tree more effectively, and in any case 100 forms or so could still end up in each module (not really fixing the problem).
Have I missed a point? Is there already a way to do this?
IT2Be:
Have you tried the filter (header of Solution Explorer)?
It is even more flexible…
I have tried the filter Marcel but that really does’n result in the kind of division I was hoping for.
In sime cases the filter actually collapses the entire solution tree making it even more inconvenient.
What I was hoping for was some sort of division of the forms by a node structure - perhaps by table, perhaps by user selection (Main Functionality, Section, Category or some other fancy structure!) and I could have just those forms open it the tree at that time.
I made this as a feature request a short while ago, but was wondering if I’d sent the developmrs on a ‘wild goose chase’ - as would have been the case if functionality was in place to cater for this.
How do other developers with a lot of forms handle this in 4.1?
Instead of scrolling through the list of forms, you can use Control-Shift-L to quickly find any object in Servoy.
Once you have the object open in an editor, you can use the “Link to Editor” button on the Solution Explorer to ‘select’ the object in the Tree as well.
This is not what you’re looking for, but once you get used to finding stuff this way, it works so much quicker than scrolling through the list of objects/forms in the Solution Explorer tree.
pbakker:
Instead of scrolling through the list of forms, you can use Control-Shift-L to quickly find any object in Servoy.
Once you have the object open in an editor, you can use the “Link to Editor” button on the Solution Explorer to ‘select’ the object in the Tree as well.
This is not what you’re looking for, but once you get used to finding stuff this way, it works so much quicker than scrolling through the list of objects/forms in the Solution Explorer tree.
Paul
Thanks Paul I’ll try that out over the next couple of days. Like so much else it takes a bit of perseverance with unusual techniques to get to see the value in them.
Can you see some sort of tree ‘forms’ node structure for the future in Serclipse?
it is in the planning that you have something like labels/tags on forms and those tags are then a filter on the forms. (so you can have a label that is a table label which would be what 3.5 does)
dont know in which servoy version will get that.
jcompagner:
it is in the planning that you have something like labels/tags on forms and those tags are then a filter on the forms. (so you can have a label that is a table label which would be what 3.5 does)
dont know in which servoy version will get that.
Thanks Johan - the sooner the better for me - forms are building fast and navigating them is more and more of a challenge. Naming conventions help but it seems a shame to change a currently successful (and favourite) naming convention to make the tree navigation easier. Seems sensible to blend the tools around the way development works rather than the other way around.
I know you guys will do the best you can for us - you always do!
In java development we also have many ways of displaying our code/classes but i never really walk over thsoe tree’s/lists to open a class up
i use also a search dialog. it is way way faster then anything else.
We have found that by far the most effective form naming convention is one that alphabetically lists “form sets”. A “form set” defined as a top level form and all the forms associated with it (through tab panels or form in dialogs).
It makes finding that 4th level deep form a snap – just eyeball the top level form name and all the included forms are listed under it.
With the filter, you can easily display a specific set of forms that you are working on. We have many hundreds of forms and getting to where we need to go is never an issue.
Seeing all forms by table was never a useful view for us so never used it.
The naming convention does more than just order the forms:
table it is based on
whether it is a form, list or FID
what level down it is in the form set
(optionally) what function it has
That’s a lot of good information. Ordering by form set in the navigator makes it all easy to stay oriented by how we work (which is by form sets, not tables or individual form functionality).
