Servoy Forum

Sometimes I wish I had the ability to "move around" within Servoy's UI tree programatically. By this I mean from any element, I should be able to "get to" the element that contains it (i.e. its "parent") and access all the parent's properties and functions. Similarly, from any element that has sub-elements (such as portals and tabpanels) I should be able to access a list of its sub-elements (i.e. its children) and access their properties and functions.

Syntax would look something like this (these are just rough ideas):

element.form.name //returns the name of the form the element is on
form.tab.name // returns the name of the tab the form is displayed in
element.portal.name //returns the name of the portal the element is on
myPortal.elements //returns an array of elements on the portal
myPortal.elements.shift_time.dataprovider //returns the dataprovider
name of the shift_time element in the specified portal


I can achieve some of these things today using functions like getTabFormNameAt() and such, but I'd like to see this made a integral part of the "dot notation" we use to access elements, properties and functions, rather than depending on specific functions like getTabFormNameAt() which only return a string, and not a genuine reference to the form object.

Any thoughts on this?

Would this be a 'nice to have', a 'must have', a 'cannot live without', a timesaver or a 'just an idea' feature? Can you provide some examples why you need this and how you would use it.

The inserts me in the debate with to possible application. It seems of to understand to me what now in the management of the navigation UI can be used the index of the contained tab only in a form to be able to individualize it inside that forms. Instead a function would be opportune that is able setup not the number of the index BUT the Name of the tab. Otherwise the developer remains imprisoned in the to put in order of sequence continually index the numerous present tabs in the principal form.
I.e. a function of setup similar to:
//get form name
frm=forms.main.elements.tabs_main.getTabFormNameAt(forms.main.elements.tabs_main.tabIndex)
if(frm == "frm_ordersList")
A) Setup form index
forms.main.elements.tabs_main.tabIndex = 5;//go to a form_ordersManagement (index=5)(setup for index)

A1) The setup become for name:
forms.main.elements.tabs_main.tabName = form_ordersManagement ; //go to a form_ordersManagement (index=X)(setup for NAME)
Regards,
Michele Annese

Jan,

The ability to learn the relationship of a tab or portal is a need-to-have. Should I submit this to the support system? I just want to be sure it isn't something that's already available but which I have missed.

The rest of what I am suggesting is nice-to-have, and not just nice for me, but nice for you too because I think once it's implemented, it will cut down on the number of requests you get for specific functions like "getTabNameAt()" and "getPortalName()" and "getTabRelationshipAt()" and so on because you will have empowered the developers to get to those properties themselves using the SOM dot notation.

I should mention that the ability to treat the UI as a tree structure and to "navigate" that tree freely is something that has been built into Omnis' "dot notation" from the start and it comes in handy very often. From any object in the solution, you can build a string that references any other object in the solution.

In general, providing this ability makes code more abstractable and makes it possible to create forms & methods that will "work anywhere" and are less dependent on specific names of parent entitities such as forms, tabs, tabpanels and portals.

Here are some specific examples of when this would be useful in my Servoy development.

1. I recently worked on a form used for logging shift information (hours worked & pertinent info about each shift) in a calendar-style form. The form that had a 5 X 7 grid of portals. The logic behind the fields in each portal would have been more "abstractable" and centralized had it been possible to learn from the element some things about the portal it belonged to, especially the relationship the portal was based on.

2. I use the same form in two different tabs of a tabpanel. When it is being displayed in tab A, it needs to have behavior different from when it's displayed in tab B. Learning what tab it's currently being displayed in as a property of the form itself (e.g. myForm.tab.name) just seems more starightforward than the current alternative:
myTabPanel.getTabNameAt(myTabPanel.tabIndex) which has the added burden of requiring that I know the name of myTabPanel beforehand.

one the application which needs to find out the parent element name which has now become a must have for me is as follows:

+ I have a common form (formA) with some buttons.

+ I use the form within a tabPanel as a common action panel in all the main forms.

+ Each tabPanel has got an appropriate name

+ Now when a button is clicked in formA I want to find the actual tabPanel name which contains the form

If we have the dot notation structure in a full fledged manner, we can easily find out the parent name.

Is this functionality already achievable in servoy using some methods?

Please help!

Thanks a lot

is there a function like

elementObj.getParentTabPanelName() AND

elementObj.getParentTabPanelFormName()


I desperately need these methods.

Please help!

Thanks a lot.

I need the following functions. Dear Servoyians! can I have a word from you on this? Thanks!

Code: Select all

is there a function like

elementObj.getParentTabPanelName() AND

elementObj.getParentTabPanelFormName()


I desperately need these methods.

Please help!

Thanks a lot.

in 4.2 you can call:

controller.getFormContext()

that will return a dataset with the complete form structure to the main application frame