I think there are still problems with modules and namespaces. But before I am going to post an example in detail, an observation:
If I define a global method in the main module and switch to a module and define a global method there with the same name, it’s possible, i. e. no error message.
If I define a global method in a module and switch to the main module and (try to) define a global method there with the same name, it’s NOT possible, i. e. I get the error message:
com.servoy.j2db.persistence.RepositoryException: The name ‘highlightSelectedRow’ already exist as an global method
So, if this message is true, then the method(s) should be displayed in the main module global part (or the variable or relationship) because it’s really there as the error message says.
This is the symptom, I assume. The behaviour (in my case of a method called by a calculation) is also very strange.
Can anyone help with the definition of the namespace of the different global parts in main and modules?
Normally one works top->down. A module is part of a bigger picture, not the other way round.
So when you define something in a solution that is already in an attached module that will give you an error (as you found out). And not the other way around since the module can move from one solution to the other.
Imho this is the way it should be and I think that if you want to check it bottom->up it is best to add the solution temporarily as a module to the original module.
Again, a module should be a re-usable piece of code (class/library if you will). When you think of it that way the issue makes more sense… Or not?
Thanks for the quick reply I wanted with this little piece only easily show the (mis)behaviour, so the real problem is deeper (definition and execution hierarchy). But let me say so: If Servoy Developer is going to complain in the main global part that the method already exists (in my case in the module) then it should certainly show the method in that main global part, otherwise one acts as a blind cow, which is definitly not funny (in programming .-) And if I am able as I am to define the very same method in the main global and then in the module global (or even in many modules), which (global) method is executed when?
Best regards, Robert
IT2Be:
To me this makes, sort of, sense.
Normally one works top->down. A module is part of a bigger picture, not the other way round.
So when you define something in a solution that is already in an attached module that will give you an error (as you found out). And not the other way around since the module can move from one solution to the other.
Imho this is the way it should be and I think that if you want to check it bottom->up it is best to add the solution temporarily as a module to the original module.
Again, a module should be a re-usable piece of code (class/library if you will). When you think of it that way the issue makes more sense… Or not?
Good question Robert.
I am not sure, discussed this long time ago with the developers but I think/can imagine this is the first one loaded and that will be the one from the (main) solution. But again, I am not sure and maybe I even mix this up with global variables since they are much less ‘critical’…
Yes, global variables and I assume also relationships are less critical. In my implementation the behaviour is not as expected (at least by me). But before posting all in detail I wanted to check what others have found or if it’s a known bug.
I hope Servoyans can say how the namespaces and the behaviour is meant?
Best regards, Robert
IT2Be:
which (global) method is executed when
Good question Robert.
I am not sure, discussed this long time ago with the developers but I think/can imagine this is the first one loaded and that will be the one from the (main) solution. But again, I am not sure and maybe I even mix this up with global variables since they are much less ‘critical’…
Robert Huber:
This is the symptom, I assume. The behaviour (in my case of a method called by a calculation) is also very strange.
So you are calling a method from a calculation?
I know this can work but it’s not for nothing that methods are not available in the Navigator tree in the (calculation) Editor.
I remember Servoy removed that out of the (calc) navigation tree in version 2.x or so. So I think it’s safe to conclude that what you are doing is not supported.
Oops, completely overlooked that calculation thing. Yep, not supported and not advised.
Although possible there is a potential danger for cascading calls…
Thanks for the hint about calling a method from a calculation. Is there something written about what is and what is not supported? I would definitly like to know.
Please don’t mix the problem of my description of the global methods in main and modules with how they are called. This is not at all related to each other. Therefor I only described the behaviour of defining them. For the problem, the problem is there if the methods are just ordinarily executed (called). So of course we discuss only this valid case (but still thanks to pointing me to a possible other problem).
Best regards, Robert
ROCLASI:
Hi Robert,
Robert Huber:
This is the symptom, I assume. The behaviour (in my case of a method called by a calculation) is also very strange.
So you are calling a method from a calculation?
I know this can work but it’s not for nothing that methods are not available in the Navigator tree in the (calculation) Editor.
I remember Servoy removed that out of the (calc) navigation tree in version 2.x or so. So I think it’s safe to conclude that what you are doing is not supported.
Robert Huber:
Thanks for the hint about calling a method from a calculation. Is there something written about what is and what is not supported? I would definitly like to know.
I tried to find it on the forum but the thread might already be archived or something.
Anyway, unlike a calculation a method can set (other) fields, thus can trigger a calculation, thus can trigger a method, etc…
In other words you can get a cascading event that can lock up Servoy.
Thanks for helping. I also was searching the forum but did not find answers.
I am fully aware of the problematic you describe and I am glad you pointed to it. Nevertheless I would like to come back to the main problem: How do the main (called application, which I think is meant the solution) and the module global parts differ, i. e. how are their respective namespaces defined? And how is the execution sequence if they contain methods with the same name. And why doesn’t the main global method part complain about an existing (global) method in a module but not displaying it?
I hope the folks at Servoy can point me to the description of the definition. Actually I would be very happy to have definitions of fundamental basic concepts underlying Servoy, but they seem not be existing or not available (to me). Hopefully I am wrong.
Best regards, Robert
PS: Sorry to insist on the basic problem, but I get quite often stuck because of the lack of such basic definitions. And I am always a bit unsure if they exist (or at least are well designed in Servoy). For me it would be much more efficient to have such descriptions instead of trying here and there a bit.
ROCLASI:
Hi Robert,
Robert Huber:
Thanks for the hint about calling a method from a calculation. Is there something written about what is and what is not supported? I would definitly like to know.
I tried to find it on the forum but the thread might already be archived or something.
Anyway, unlike a calculation a method can set (other) fields, thus can trigger a calculation, thus can trigger a method, etc…
In other words you can get a cascading event that can lock up Servoy.
I just realized that defining a method in the module global (space) with the same name is possible (except in the main module as mentioned earlier) but then opening the method is only possible in the module where the last definition of the method (with the same name) has be done. In all other modules the method can’t be opened, i. e. the code can’t be moved to the right side to edit. If one edits the method and opens another module (with the same named method in global) Servoy gives an error message:
Switch to design mode to fix the problem(s):
GlobalScriptMethod with name ‘highlightSelectedRow’ of solution 'HadesPersons’is conflicting with ‘ScriptMethod[name:highlightSelectedRow, inmenu]’ based in solution HadesPlacements
My conclusion so far:
There is only one global namespace for the main and all modules
Although there is only one namespace for global, only the methods (and variable, relationships) originally defined in that module are shown in the globals list
One can not access a global method which was defined in another module although it’s the same namespace
On the other hand, one can define two methods with the same name in global but it leads to conflicts (because it’s only one namespace)
In short, either the separation of the namespaces is wrong or the access to the single global namespace is wrong. Error handling is baffling to me.
Or someone please tells me how it really is intended to work I don’t get it.
Best regards, Robert
Robert Huber:
Hi Robert
Thanks for helping. I also was searching the forum but did not find answers.
I am fully aware of the problematic you describe and I am glad you pointed to it. Nevertheless I would like to come back to the main problem: How do the main (called application, which I think is meant the solution) and the module global parts differ, i. e. how are their respective namespaces defined? And how is the execution sequence if they contain methods with the same name. And why doesn’t the main global method part complain about an existing (global) method in a module but not displaying it?
I hope the folks at Servoy can point me to the description of the definition. Actually I would be very happy to have definitions of fundamental basic concepts underlying Servoy, but they seem not be existing or not available (to me). Hopefully I am wrong.
Best regards, Robert
PS: Sorry to insist on the basic problem, but I get quite often stuck because of the lack of such basic definitions. And I am always a bit unsure if they exist (or at least are well designed in Servoy). For me it would be much more efficient to have such descriptions instead of trying here and there a bit.
ROCLASI:
Hi Robert,
Robert Huber:
Thanks for the hint about calling a method from a calculation. Is there something written about what is and what is not supported? I would definitly like to know.
I tried to find it on the forum but the thread might already be archived or something.
Anyway, unlike a calculation a method can set (other) fields, thus can trigger a calculation, thus can trigger a method, etc…
In other words you can get a cascading event that can lock up Servoy.