Why is Servoy Scope Backwards?

[john1598360627]

I've always been confused by this. Why does Servoy use the scope of the project in reverse of how Modules are linked together?

For example, you have your Main Solution right? That Main Solution points to modules. These modules can point to other modules. From the 'root' of the solution, this linking of modules is 'forward' from the root. Intuitively, the assumption would be this is also how the actual scope of the code works too.

When I talk about 'scope' I'm specifically referring to being able to call a function or reference data from another module's form or scope within another module. Essentially 'seeing' other modules.

But the relations, usually used with Parent / Child metaphor, is a bit more complicated.


Example 1 - SCOPE LINK
(see below)
The Parent Module sees everything the Child Module has. But also, the scopes origin/root is shared with the Child Module.

With this idea, the Solution or Module0 would be the 'global' scope so to speak as every other module is under them.

Every Module in this case would be able to see and use what Module0 or the Solution has with Forms and Scopes.

This means, Module1 can see and use everything from Module0 and the Solution, but not Module2 or Module3.

Module4 would be a 'sub' module under Module1 as well. So despite Module4 having the global module of Module0, it wouldn't be able to see Module5 or Module 6.
Module7 and Module8 would be at the end of the line. This would be kind of a double 'global' scope in a way but only in one direction.

To put it simply, the Parent can see and use everything the Child has. AND, the Child can see and use everything the Parent has.

However, this isn't how Servoy actually works with scopes despite how these are linked.


EXAMPLE 2 - SERVOY SCOPE
(see below)
This is how Servoy's scope works. While the Parent Module can see what the Child Module has.. the scope isn't shared. So rather than the root / origin being the 'global' it's the end of the linking itself.

So then, Module8 and Module 7 are the 'global' modules. Meaning, all the Modules will be able to see and use them...
But, the Solution and Module0 become the 'end' point... Meaning they will see and use everything. WHich is strange because the Solution and Module0 are the main 'Parents' of all the links.

To put simply, the Parent can see and use everything the Child has.... But the Child can't see or use anything the Parent has.



THE PROBLEM
Because the linking of Parent and Child modules are 'backwards', this creates some weird problems.

For example, despite Module8 supposedly being the global module in EXAMPLE 2 / How Servoy Currently Works .... It can't actually SEE anything. It is only referenced.
Likewise, the Solution can see and use everything.... but why what would be the point of this when most of the programming is going to be happening in the 'Child' modules themselves. And if the Child modules can't see the Solution... Then the Solution is basically useless.


THE SOLUTION
Make the SOLUTION the ORIGIN / ROOT of all scopes. EXAMPLE 1 just makes more sense.
Not only is the Solution the 'Super Parent' that can see all of it's Child Modules, but all of it's Child Modules can use the shared global scope that is created 'forward'.
Plus, it's easier to split that 'global' scope up by just connecting some other modules to the Solution and basically creating new organizational scopes from that.


HELP?
Is there a reason why Servoy uses an inferior way of scoping the Solution such that the Solution is not the origin/root/global scope?

Or if there's a way of turning the Solution into the root/global?


[Example 1 - SCOPE LINK]

servoyScope-Scope-Link.drawio.png (52.68 KiB) Viewed 20365 times

[EXAMPLE 2 - SERVOY SCOPE]

servoyScope-ServoyScope.drawio.png (52.23 KiB) Viewed 20365 times

[jcompagner]

i don't see how this is backwards

a module is a library

If a solution includes this moduleA or a moduleB includes a moduleA then the the solution can use moduleA (but not the other way around) and moduleB can use moduleA (but not the other way around)

how is that not completely logical?

the thing is if you open a module as standalone itself, it should always fully validate, if a module could suddenly use something of its parent then the module is not standalone anymore, you create a cycle dependency, that means its not a module its just one big thing.

But it could be i don't understand it fully correct what you are really saying

The problem is a bit that in the end everything is one big thing, so yes what a core solution provides (like the components packages) they belong to the runtime environment, thats why we had those first at the resource node (where the kind of belong)
but that had some problems for some people
So there we have some stuff that is a bit backward.. because of global resources that are provided by the solution that are used by all the modules.. that is backward and not so nice.
For example if you have a Solution A that includes a Module B (which can also be a stand alone thing) and Solution A has the webpackages. Now if i make Module B as the main solution and i export it, where does it gets the webpackages from? very likely it doesn't really work because of missing stuff

[john1598360627]

BACKWARDS

i don't see how this is backwards

a module is a library

If a solution includes this moduleA or a moduleB includes a moduleA then the the solution can use moduleA (but not the other way around) and moduleB can use moduleA (but not the other way around)

how is that not completely logical?

So to re-iterate, the idea in Servoy is that all of the modules point towards the Solution so the Solution can see everything correct?

That's exactly why this is backwards. All of the programming does not happen in the Solution itself, it happens in the Modules. I have about 10+ Modules, to organize the project properly. Why would I put all of this code into the Solution 'module' itself?

Again, this relationship Servoy setup means that the Solution, the environment of the project itself isn't the root. The 'top of the node tree' is the root... rather than the root itself.


STANDALONE?

the thing is if you open a module as standalone itself, it should always fully validate, if a module could suddenly use something of its parent then the module is not standalone anymore, you create a cycle dependency, that means its not a module its just one big thing.

But it could be i don't understand it fully correct what you are really saying

Ahhh, I see. Yeh I didn't explain it properly. I'm not saying that every module is standalone and can see every other module. That would be a complete mess as you said.

Instead, the Child nodes can see everything up to the Root of the Tree. But not beyond that. Instead, the Root becomes the 'conductor' of all the Nodes. Like wise, any other Node near the Root can be used for similar effect. Again, this allows for the Solution to be the Root of the node tree, rather than the star on top of the tree.


COMPONENTS

The problem is a bit that in the end everything is one big thing, so yes what a core solution provides (like the components packages) they belong to the runtime environment, thats why we had those first at the resource node (where the kind of belong)
but that had some problems for some people
So there we have some stuff that is a bit backward.. because of global resources that are provided by the solution that are used by all the modules.. that is backward and not so nice.
For example if you have a Solution A that includes a Module B (which can also be a stand alone thing) and Solution A has the webpackages. Now if i make Module B as the main solution and i export it, where does it gets the webpackages from? very likely it doesn't really work because of missing stuff

Yup, I have encountered this problem. Due to how the top of the tree is the Global space, I have all my assets at the top/end. Now, components that are modules I have to attach to the end/top so they can be globally seen.

I should clarify too. The rest of the webcomponents do seem to work with respect to the Solution. So I have the normal components within the Solution and all the Modules can see this. But this creates an inconsistency with the rules here. Why can the components treat the Solution as the root, but not modules themselves?


OBSERVER
I wanted to bring up too a design pattern that may help explain the full context here.

What I'm describing for the Solution being the root, and the Module being able to see up to the Root. What I'm talking about is within the context of Functions or the 'Scope' space of a Module. This is what is going 'forward' through the tree.

However, that's just the 'code' so to speak. Forms are the UI and UX of the project themselves. And every Form element has events to it correct? While these are 'Functions', they are a special case. These events fit more into what is called the Observer Pattern.

https://en.wikipedia.org/wiki/Observer_pattern

This is all about 'events' and 'signals'. This is structured more in line with how Servoy is doing Module relations. It's pointing 'backwards' to the root basically. This is because, events will send a signal to a system that will update anything that was connected to that system.

This concept is definitely not straightforward to understand though, but it's a tool that becomes quite powerful. As it bridges that gap between user developed 'functions' and UI form element 'events'.

I actually use this pattern for a navigation system I setup.


SOLUTION
Ultimately, what I'm trying to get at is that it makes the most sense for functions to go 'forward' from the root to the children.

But, signals do work by going 'backwards' from the child to the root.

[jcompagner]

no i really think you see it wrong
depedencies are as all depedencies the root gets depedencies of its children

the children never should see the parent..

thats how it works everywhere for example in a java dependency file (mvn pom.xml file) that "root" (the solution) says i depend on module "a" and "b"

then "a" and be has no idea that the root uses "a" the root can only use "a" but not "a" can never see or use "root"


What you seem to describe is completely something else that solution (which is special module) and modules are, those are just encapsulation of code.

I already told you that components are a bit special, and that is kind of a bad design, thats not the proper way todo it, but components are kind of outside of the solution/module structure, they kind of belong the the complete environment where you deploy on.
(and as i said we had that before, components where in the "resource" project, which is purely looking at how it should be way more correct, but this had drawbacks for a lot of deployments (like modules that can be installed in a lot of different solutons))

to have another sample, we have a svyUtils module that we ship, and you can install that and use that then in your root solution (or any module that also installs that svyUtils as a depedency)

How can that svyUtils know already the root?? it has many many roots, any solution of any customer that installs that module into its solution (the root)

So to re-iterate, the idea in Servoy is that all of the modules point towards the Solution so the Solution can see everything correct?

no a solution point to a module (has that as a refences) so that the solution can use the module

this is by the say not always "solution" -> "module" but can also be "module A" has "module B" as a dependency and because of that A can use stuff from B (but B doesn't see A its just used by A)

So if you don't really do anything in Solution (what you see as the root) and do everything in Modules then that is fine, but Modules should just has other modules as depedencies so they can be used

You kind of seem to see as the root Solution as something that binds it all together.. That is not true, what binds it all together is the resouces project (what is your server in the deployment)
there you can have multiply solutions that you run that all are using a lot of (shared) modules.

But the server environment of all those solutions is the same for all the solutions, and in that environment that is for example the database servers, but also all the component, plugins and services

But the root solution is just like any other module, its the same thing.
There is no difference between a module of a solution or the solution itself.

[john1598360627]

'See'
I suppose that where the confusion is coming from. What I meant by 'see' is by seeing the public functions from that module. As in, I'm seeing the Solution / Modules as objects, and that when you link them that is an extension.

https://www.ennicode.com/inheritance-in ... mming-oop/

Code: Select all

// Create parent with myMethod
class Parent1{
   public void myMethod(){
      System.out.println("Parent 1 Method");
   }
}
// myMethod derived through the inheritance to child1
class Child1 extends Parent1{
}
// myMethod derived through the inheritance to child2
class Child2 extends Parent1{
}


The children 'see' the public method is what I'm getting at. Although your right in that isn't the proper wording. Rather the children are 'inheriting' the functions by extension.

In Servoy, linking modules together creates a situation where it inherits backwards. The Parent inherits the functions of the child nodes.... Which doesn't make sense to me.

SOLUTION
I supposed if the idea behind the Solution / Module design is that the Solution is just another Module... Perhaps the resource itself should be the true Global Space?

As in, having an option to create 'Scopes'/functions that would be available to every function in the environment.I believe I remember hearing that Servoy used to have this, but deprecated it? This could also be expanded to 'assets' or custom resources too. Just so there's a central point that can be shared between different solution environments.

Because an issue I have with the 'multiple solutions' design is.... I have no idea how to setup multiple solutions that would all share the same global functions and assets and also work in tandem together.


For example, if we go back to my example; Is it possible to convert some of those modules into their very own Solutions?
Like so;

Solution0 -> Solution1, Solution2, Solution3

Solution1 -> Molude1, Module2, Solution 4
Solution2 -> Molude3, Module4, Solution 4
Solution3 -> Molude5, Module6, Solution 4

Solution4 -> Module7, Module8


(In this context, that Solution0 is the Start and that Solution4 is the End.)

Is the more proper way of setting up a Servoy project? Rather than having a bunch of modules?

[steve1376656734]

I thin the confusion here comes from what you consider to be the parent and child. If you take a diagram from the link you have referenced that shows multiple inheritance:

Multiple inheritance image from linked article

Multiple Inheritance.png (78.33 KiB) Viewed 20090 times

The equivalent diagram for a Servoy environment would be:

Servoy inheritance

Servoy Inheritance.png (69.23 KiB) Viewed 20090 times

The above diagram assumes that the fields and methods in the modules are declared as public and not protected or private.

This, to me, seems perfectly logical and follows the OOP concept of inheritance as the solution "inherits" the public fields and methods from the modules in the same way that the sub-classes inherit them from the parent classes.

Hope this helps
Steve

[jcompagner]

if you have many top level solutions that you want to have common shared logic
then that shared logic should just be in module that all the other top level solutions or other modules) to include that shared module that has all the global functions you want to have.

as i said before solutions and modules are the same thing they are just a "package of functionality" that others can include.. Pure for servoy the difference between a "pure" module and a soluiton is that a solution is "startable"
but you can make a fully structure of just solutions (so not modules)
The name "module" really means this is a solution that is meant to be included, it is not a standalone startable entity.

But steve also descirbed it nicely

A Module could have a "MyBaseClass"

and then any other module (or the normal solution) that would include that Module could then extends that "MyBaseClass" , because it can see that MyBaseClass and can extend/enhance on top of it
But MyBaseClass has no idea that there are SubClasses build on top of that, it doesn't see those

[john1598360627]

I thin the confusion here comes from what you consider to be the parent and child. If you take a diagram from the link you have referenced that shows multiple inheritance:

Multiple Inheritance.png

The equivalent diagram for a Servoy environment would be:

Servoy Inheritance.png

The above diagram assumes that the fields and methods in the modules are declared as public and not protected or private.

This, to me, seems perfectly logical and follows the OOP concept of inheritance as the solution "inherits" the public fields and methods from the modules in the same way that the sub-classes inherit them from the parent classes.

Hope this helps
Steve

This is exactly the problem here. See how you define the Modules as Parents that create a 'sub class'? ... Well it's the opposite in Servoy. The Solution has to exist, it's the root of the node tree. Modules are the sub class.

The name "module" really means this is a solution that is meant to be included, it is not a standalone startable entity.

So it is backwards by how Servoy defines it.


Which again, backwards is great with an Observation pattern. And I assume I can improve my project structure by implementing more Solutions, which I haven't attempted yet.

[john1598360627]

if you have many top level solutions that you want to have common shared logic
then that shared logic should just be in module that all the other top level solutions or other modules) to include that shared module that has all the global functions you want to have.

as i said before solutions and modules are the same thing they are just a "package of functionality" that others can include.. Pure for servoy the difference between a "pure" module and a soluiton is that a solution is "startable"
but you can make a fully structure of just solutions (so not modules)
The name "module" really means this is a solution that is meant to be included, it is not a standalone startable entity.

But steve also descirbed it nicely

A Module could have a "MyBaseClass"

and then any other module (or the normal solution) that would include that Module could then extends that "MyBaseClass" , because it can see that MyBaseClass and can extend/enhance on top of it
But MyBaseClass has no idea that there are SubClasses build on top of that, it doesn't see those

Okay so, I'm curious about this. The reason why I made my entire project be modules is because I thought Solutions and Modules are the same thing.

What is the advantage of having multiple Solutions? Like what can I do with multiple 'startable' points?

[rafig]

Not sure if this helps (or was mentioned in some way above that I missed), but I only realised after a Servoy training course or something, that at 'run time' (solution export?), the code is all "flattened", so there are no modules or anything, it's all just one big load of code.
This is why you can refer to something in another scope/module that causes a warning in the developer code, but works when it's run (might not be the correct way of doing, as Johan states that modules should be self-contained, but might allow for breaking things down code wise... )
But I might be wrong or haven't explained quite right...

[jcompagner]

What is the advantage of having multiple Solutions? Like what can I do with multiple 'startable' points?

you just can have multiply apps right?
that people can start? then you have multiply solutions that you can start like "MyMainAppl" "MyEntryApp"

But all that has no meaning, so i don't know why you ask that, if you just have 1 applicaiton so you have 1 main solution then the rest can be just modules (it all doesn't care that works the same, so i really don't get the question why this matters)

A module can have another module as its module, just like that module can have a solution (marked as a solution) as its module which, it self can also have another solution as its module

All that is just the same, works the same, there is no difference.

[john1598360627]

Not sure if this helps (or was mentioned in some way above that I missed), but I only realised after a Servoy training course or something, that at 'run time' (solution export?), the code is all "flattened", so there are no modules or anything, it's all just one big load of code.
This is why you can refer to something in another scope/module that causes a warning in the developer code, but works when it's run (might not be the correct way of doing, as Johan states that modules should be self-contained, but might allow for breaking things down code wise... )
But I might be wrong or haven't explained quite right...

True I remember this. I believe too you can disable the warning about referencing stuff 'out of scope'. However, I do want to stick with the 'intended' scope.

[john1598360627]

What is the advantage of having multiple Solutions? Like what can I do with multiple 'startable' points?

you just can have multiply apps right?
that people can start? then you have multiply solutions that you can start like "MyMainAppl" "MyEntryApp"

But all that has no meaning, so i don't know why you ask that, if you just have 1 applicaiton so you have 1 main solution then the rest can be just modules (it all doesn't care that works the same, so i really don't get the question why this matters)

A module can have another module as its module, just like that module can have a solution (marked as a solution) as its module which, it self can also have another solution as its module

All that is just the same, works the same, there is no difference.

Ah so multiple solutions are for multiple apps then huh?

Would there be any reason to have 'nested solutions' though? Like link these multiple apps together.