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.