Datafield of a Portal or not?

Classic Servoy
1

Hi,

How can I distinquish between regular formElements and formElements that are columns of a Portal or TableView?

Elements that are the columns of a Portal or TableView looks exactly alike in the Method editor, allthough they are not the same.

For example, setting the visibility, width, height etc on a formElement that is part of a Portal/TableView has no effect.

Developer seems to be partly aware of it, since in the Properties tab, for elements of a Portal, the header of the Properties tab states that the Parent is a Portal and the PrintSliding property is not shown.

Reason why I’m looking for this is that my custom security works based on the elements.lenght, elements and elements[‘name’] and the Portal/TableView elements are included in these.
Any thoughts appreciated,
Paul

2

No-one? :roll:

Did some further diggin’ myself and found the following things:
Elements on a form that are actually TableView columns have the following behavior:

  • the X and Y are 0 when the form is loaded, but not yet shown
  • the X and Y have a negative value when the form is also shown
    Elements on a form that are actually TableView columns have the following behavior:
  • The X and Y are always 0 (regardless if the form is only loaded or also shown)Allthough with this logic it’s almost possible to determine whether or not an element is part of a TableView or a Portal , it’s not really a neat way to do it and secondly, will this logic remain as it is now in future versions?

The only exception as far as I can see are actual formelements at location 0,0.

I would really like to know more conclusivly if an element on the form is part of a TableView or Portal. For example a element.getParentType(); function, which returns either “Form” or “Portal” or “TableView”

Paul

3

How can I distinquish between regular formElements and formElements that are columns of a Portal or TableView?

Elements that are the columns of a Portal or TableView looks exactly alike in the Method editor, allthough they are not the same.
..
Reason why I’m looking for this is that my custom security works based on the elements.lenght, elements and elements[‘name’] and the Portal/TableView elements are included in these. [/quote]
Probably a stupid question but do you have to have the elements ‘named’ that are in the portal? In other words do you need access to them for other reasons? I know that is not what you are asking directly but I am always debating as to whether to name every object when I set up a form. Often I want to cycle through all the elements of a form looking for something and ‘naming’ everything just means that there is more to cycle through. And in this case, at least from your quick description, it sounds as though you might not need those elements within the portal to be ‘named’.

4

tnx John for the reply.

I’ve been thinking about using naming conventions (including no name) to solve my problem, but I have two problems with that solution:
1- quite some effort naming all elements correctly, with the change that an element is named incorrectly and the logic is not sound anymore
2- if third parties develop modules that are included into the main solution, there is no control over the naming convention they use, which means again that the logic is not foolproof.

Paul

5

pbakker:
I’ve been thinking about using naming conventions (including no name) to solve my problem, but I have two problems with that solution:
1- quite some effort naming all elements correctly, with the change that an element is named incorrectly and the logic is not sound anymore
2- if third parties develop modules that are included into the main solution, there is no control over the naming convention they use, which means again that the logic is not foolproof.

OK, I see, that makes sense.
1 - would mean a fair amount of work to rename items. If though there is a consistent naming convention (the Servoy default naming of all portals starts with ‘portal’ and for tab panels with ‘tabs’), then searching for all such items shouldn’t be too hard with looping through the forms in a method such as: forms.[formName].elements*.getName(). This would help to locate all such occurrences where there might be duplication in the past.*
2 - also true. However if third parties are given the naming conventions used and still mess it up there isn’t much more you can do. Sometimes trying to be too ‘all-knowing’ can cause more problems than it is worth. Just like trying to be too ‘global’ in method development!
The reason I mention using ‘universal’ naming conventions (maybe adding ‘port’ as a prefix or suffix to every ‘name’ within a portal) rather than have Servoy itself track every such ‘relation’ is that I worry about eventually slowing Servoy down. Since every single business rule, screen draw or basic method involves in itself SQL’s submitted to the servoy_repository even without the calls to the data back end, I worry about ‘extra’ relationships (tieing each named element to a ‘parent’ element) eventually causing slowdowns. Especially if a solid naming convention might not be just as good, just as robust and actually speedier.
Just a thought.

6

I agree with not building in too much overhead (offcourse :-) )

But…: the info I request seems to be allready there, but only not accessible (As I said, Developer knows an element is part of a Portal, since it shows it in the header of the properties tab).

It seems to me that there would be no extra relations to create, just making the info available thorugh a function.

And functions are triggered only when the developer put them in a method, so adding a function to retrieve the info needed doesn’t slow down Servoy, except when the developer uses the function.

Paul