pbakker:
I think by now this thread is mixing several discussions:
1- scopes
2- topdown/bottomup module inclusion
3- resource projects
…
I think both 2 and 3 are “issues” you run into when developing solutions utilizing 3rd party modules/frameworks and as I mentioned under 3 it’s something we are aware of and are looking into.
Right on Paul. Reusing modules and updating them independently of particular client solutions and servers is a PITA right now with Servoy. Not something I’ve seen other techs completely solve yet either so tough nut to crack I think.
Some thoughts for your “looking into” process:
Real solution layer
Aggregate resources
Can public anything
Scoping at the module level
REAL SOLUTION LAYER
Replace the “active module equals the solution” concept with a real solution node to give us a clear top-down scope chain: Database > Server > Solution > Module > Object.
The current way of “faking” a solution by flattening out a bunch of modules that are included in each other is overly complex and makes creating a new client workspace/project with modules coming from everywhere a work of art to achieve.
With a real solution node, a new client project would instead simply entail: 1) create a new solution; 2) include various stand alone modules into the solution (navigation, layout, access and control, code, a cms, a crm, document manager, etc); 3) create custom modules for the client.
The solution object would have most of the properties (ie. “firstForm”) and events (ie. “onOpen”) modules currently have. Modules would have their own properties and events (ie. “moduleType”, “requires”, etc).
A solution by definition requires at least one module.
AGGREGATE RESOURCES
jcompagner:
About resources, if a solution or module doesn’t touch certain tables then there is now problem what so ever, but again the resource project really targets the server, so a workspace (with 1 resource project) is really a workspace for a specific server, thats how you should work. Else it would be come one big mess, what happens if you have multiply resource projects but accessing the same kind of server/tables? Then you define on column level X in one resource and Y in another then what?
I think the answer is easier than it looks – Servoy has already solved the tougher piece to this puzzle: syncing/listening workspace .dbi files with database tables.
One additional piece is needed: implement a way for the workspace .dbi files to sync/listen to table definitions included at the module level.
This would require a specific format for specifying table definitions at the module level. Musing out loud I would suggest that the workspace .dbi files remain the default approach. Then at the module level functions could be created to modify the default workspace .dbi’s. Servoy checks through these functions when a client is started, builds up the workspace .dbi’s, and throws various warnings for duplicate columns, dbi’s out of sync with database, etc.
I had this discussion of building up resources (including data connections) programmatically per solution/project last week at a conference with some very smart people types and it turns out to not be an uncommon idea/approach in the JS stack world.
However it’s done, the ability for modules to carry around their .dbi information needs to be solved to be able to plug and play modules anywhere we like with zero fuss.
EVERYTHING CAN BE TAGGED AS “PUBLIC”
Independent module design depends on the ability to include and export to other modules (see http://www.commonjs.org). Recent Servoy versions have been going in the right direction with being able to tag things as “public”. Forms got this recently via an encapsulation property and functions have had it for a while.
But that leaves out other objects like value lists and relations. Because of this we almost always have to split major modules into two modules – one module for all the api stuff that we want to share (forms, relations, calcs, value lists, code), and one module for the specific private functionality. The api module gets included into the private module and then can also be included in any other module as needed.
This situation basically negates the whole public/private capabilities Servoy currently has. You might as well just tag modules as public or private.
So the obvious question now is: what about potential naming conflicts with making say – a relation – public? Glad you asked…
SCOPING AT THE MODULES LEVEL
Rip out current globals and scopes. There I said it.
Instead, namespace modules. Maybe with a module shortname property. The only thing a developer needs to handle then is to make sure all modules in a solution have unique shortnames.
Now, within a module all your naming conventions and referencing remains the same. However, another module referencing any public object does so with “shortname + DOT + object” notation. Examples:
barcode.forms.thisGreatForm.controller.someFunction()
(barcode.globals.globalSheetName.someProperty == "Version 3.02")
Notice I do have a “globals” object still so I lied a little at the start of this section. What I’d rather see is a reworking of globals/scopes to make things less wordy:
- globals node is no longer a js file of it’s own, just a place to put javascript files.
- there is automatically a js file in the globals node per module that has the same name as the module shortname.
A real bonus would be to have a special globals node on the solution as well. The solution object would have an implicit identifier (“Servoy?”, “solution?”) to reference global jsFiles.functions() (ie. “solution.brilliantCodeSheet.someFunctionAllSolutionModulesSeeByDefault()”).
Finally, objects within modules have to have unique names but not within a solution. Same form name in two modules in a solution? No problem. (Finally….)
SUMMARY
The ultimate goal is complete module portability. Modules need to be name spaced, carry everything they need to function with them (resources), public/private completely contained, and a solution object to plug them into.