ptalbot wrote:Hi all!
First, I'm sorry to disagree with Robert about the fact that "the modules should be in the folder of the main and not on the equal level."
That goes against the idea that a module is something that can be shared among many solutions... if you enclose it into one solution, you won't be able to use it anywhere else.
But then the all idea of "module" doesn't make sense anymore, because a solution tagged as "solution" can be used as a module in any case...
I must confess that I never made any "module" as such, although I use them a lot
Hi Patrick, you don't need to be sorry .-) a forum is good to hear many (different) ideas. But I actually didn't mean grouping into one "package" means one cannot use modules in different solutions - of course I also would like to use modules in more than one solution if appropriate (although in our practice it's quite rare, as solutions have not much in common, so the chance of using modules is not big, except for modules containing basics)
ptalbot wrote:About security though, I do agree with you, Robert: I wonder about these best practices too!
What is very much unclear to me is the role of the Servoy Resources Nature that you can assign to a solution, and the fact that you can also change/create Resources project on the fly in Serclipse.
I would have thought that a "Resource Nature" project was where Servoy was keeping its Datasources, Security, and Styles, at least that's what I can understand when I look in the workspace at a "Resource" project (the default "servoy_localhost_resources" for example, with a .project file set with a nature of "com.servoy.eclipse.core.ServoyResources"), so why having them in different workspaces altogether, when/if you can choose/change/assign them from inside the same Workspace to different solutions?
Pauls, by recommending to use one workspace per solution "Resource Nature", are you implying that this feature is not working?
Thanks Patrick for explaing this in more detail, but that's a part which shows that one has either the concept as it it is now or one has strictly separated workspaces with it's own resources etc., but then, I assume, the easy way of activating different solutions with all of the associated stuff would get lost.
ptalbot wrote:And even more confusing, there is the relationship between these "Resource Nature project" and the Servoy repository...
This is still very mysterious to me, and I feel that I'm not the only one.
I agree, I am still missing a documentation about the concept of how Servoy is intended. Unfortunatly, this is not only a flaw of Servoy , everyone tends to write about which button to press etc. but nowhere are the intentions, concepts, ideas, current state and what will come and how it should look in "the end", which would help a lot to understand the ideas behind the tool as a whole. May be I again I could ask at this moment for a sheet describing all the events and their relationships to each other and when the trigger in various circumstances, incl. when using modules ,-) And yes, I know, the onShow event for example triggers when the form is shown .-) (if it would be only that easy)
ptalbot wrote:Questions, questions...
This is an area which definitively needs some cleaning, and precise documentation, and I also hope that it will be addressed in the next major release.
According to my reply, for me as well, questions, questions, ... these sort of questions also show the limit of a forum to discuss them, as no one has the big picture, or, more precisely said, at least not me.
Of course despite my complaints/wishes many thanks for the discussion possibilities on the forum! Robert