[lively-kernel] Code reorganization in Webwerkstatt - please check your js files

[Keith P. Hodges]

It seems ridiculous for me to talk as if I know what I am doing, but I figure you guys will be forgiving...

Its a mad place for me to start learning, reorganising the whole code base as an exercise. From what I have seen so far (which is not a lot)...

I prefer to be able to define an explicit load list, rather than a search path. 
	- Search paths can be the source of hard to find bugs. I spent an hour or two yesterday trying to debug an apache conf, when all the time an old file was being picked up in the search path.

I was quite surprised to find that the bootstrap.js was not data driven.

If the bootstrap.js is part of the "corest, kernelist" part of lively, I would expect to see the list of modules would be better pulled out into the start.xhtml somehow. The list could be moved into the Config somewhere. ves sorting out some of decisions that boostrap.js is making i.e. isCanvas. I would even consider putting up two hard coded lists, i.e. CanvasModules and NormalModules. 

I am experimenting with moving the load list call into start.xhtml

Instinctively I am thinking that I would like the load list to be recursive, that modules can specify a list of modules. In which case the top level config would call in the "core" top modules and the "users" top modules. If this was the case, a "canvas" module could only load in submodules if canvas is not present. However, nothing is going to be faster and clearer than an explicit list, so that would be my preference.

regards

Keith



> Hi, Fabian --
> 
> sounds nice, just like Java classpath, but what about overriding modules? And... the most important of all, how do
> we figure out if a module can be loaded in this or that part on the client side? Should we check before every module 
> load if the module is available under rootA, rootB or rootC? We could use node.js to do it on the server for us...
> or another idea:
> Don't use additional roots but "link" in other path into our root. We could explicitly register "webwerstatt/users" for the
> users prefix... this would also allow us to map non file system based modules from the codeDB into our normal module schema without having to user special chars as codeDB1 did....
> 
> Best,
> Jens

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hpi.uni-potsdam.de/archive/lively-kernel/attachments/20111027/ac6222a3/attachment-0001.html>