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

[Fabian Bornhofen]

Hi Jens,

I just committed a change to the loader. You can now configure
(additional) module paths in bootstrap.js (search for modulePaths). I
admit that there shoule be a nicer way to configure it, though...

Anyway, what happens is that the loader would check if it can get the
module from the core folder. If not, it tries the alternatives. I
added 'users' for Webwerkstatt. You should be able to require user
defined modules with ... require('jenslincke.YourModule'). ...
What you might try to do is create a new module in your users/ folder,
check if that works and if it does, remove the users/ folder from
core/. The only difference is that you need to write
'jenslicke.YourModule' instead of 'users.jenslincke.YourModule'.
Please let us know if there's anything that does not work.

If this is configurable, we might think of alternative load orders, so
you'd be able to have your own Events.js and so on. It'd be cool to
play with that, but it might slow down the loading process (idea:
Config.customModules?).

Keith: What's cool about the recursive load is that in your xhtml
files, you only need to link to bootstrap.js and it takes care of
everything else. If you add references to all core modules to your
worlds, you'd have to manually update these every time we add or
remove a core module. (Well, you should not expect this to happen too
often..) It also makes it easy to build e.g. a facebook app that
displays worlds.
There are a couple of things that eventually should be changed in
bootstrap.js and I like that we're playing with this right now.
That'll help us understand and make the right decisions.

Regards,
Fabian

On Thu, Oct 27, 2011 at 2:00 PM, Jens Lincke
<Jens.Lincke at hpi.uni-potsdam.de> wrote:
> 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
>
>
> Am 27.10.2011 um 22:52 schrieb Fabian Bornhofen:
>
>> Hi Jens,
>>
>> you're right. We are thinking about changing the loader so you can
>> specify additional module locations. You would have something like
>>
>> Config.additionalModulePaths[i] = 'users' // path relative to Config.rootPath
>>
>> and then
>>
>> module ... .requires('jenslincke.yourPersonalModule') .....
>>
>> What do you think?
>> Fabian
>>
>>
>> On Thu, Oct 27, 2011 at 1:00 PM, Jens Lincke
>> <Jens.Lincke at hpi.uni-potsdam.de> wrote:
>>> Hi, Lauritz
>>> I definitely think it should go into the users folder, but since you changed
>>> the codebase the users folder are out of reach
>>> for loading moduless.... so I moved the code into the codebase again.  How
>>> should we deal with multiple roots?
>>> Best,
>>> Jens
>>> Am 27.10.2011 um 19:49 schrieb Lauritz Thamsen:
>>>
>>> Hi Jens --
>>>
>>> Should we require them differently such as we did with the modules from the
>>> CodeDB? In the meantime I will move the modules in question below the
>>> kernel/ dir.
>>> Kernel is therefore a bad name, because the kernel is under "lively" and we
>>> would not call the rest kernel, or would we?
>>>
>>> Yes, I agree it shouldn't be 'kernel/', so we will rename it to 'core/'
>>> later in the evening (Oct 28, 1 a.m. CEST or Oct 27 4 p.m. Pacific Time).
>>> However, I am not sure that "personal modules" should be part of our core
>>> distribution. Either such code belongs into apps/, lib/ or into lively/ and
>>> should be synched across repositories or it should remain in a user's folder
>>> and shouldn't be synched across repositories. What do you think?
>>> Best,
>>> Lauritz
>>> On Oct 27, 2011, at 2:18 AM, Jens Lincke wrote:
>>>
>>> Hi, Lauritz
>>> works for most pages. How do we deal with non kernel code additions in the
>>> wiki. Code in users or project directories such as
>>> http://lively-kernel.org/repository/webwerkstatt/projects/BP2012/
>>> http://lively-kernel.org/repository/webwerkstatt/users/ahold/
>>> Should we require them differently such as we did with the modules from the
>>> CodeDB? In the meantime I will move the modules in question below the
>>> kernel/ dir.
>>> Kernel is therefore a bad name, because the kernel is under "lively" and we
>>> would not call the rest kernel, or would we?
>>> Best,
>>> Jens
>>> On 27.10.2011, at 07:58, Lauritz Thamsen wrote:
>>>
>>> Hi.
>>>
>>> As announced yesterday, we reorganized Webwerkstatt a bit.
>>>
>>> Please let us know if you experience any problems regarding loading or
>>> saving.
>>>
>>> Best,
>>> Lauritz
>>>
>>>
>>> On Oct 25, 2011, at 5:10 PM, Fabian Bornhofen wrote:
>>>
>>> Hi -
>>>
>>> as mentioned earlier, we want to simplify code distribution.
>>>
>>> As a first step, we are going to reorganize some files in Webwerkstatt and
>>> move the core code from /repository/webwerkstatt to
>>> /repository/webwerkstatt/kernel.
>>>
>>> To keep your worlds running, we will run a script on all xhtml files in
>>> Webwerkstatt that changes the path to bootstrap.js. For most worlds, you
>>> will not notice any difference. If you have never written a Lively
>>> JavaScript module on your own,   then most probably you do not need take any
>>> action.
>>>
>>> However, if any of your worlds have dependencies on other js files (e.g. js
>>> files in your home folder), please check references to these paths.
>>> Config.codeBase will be /repository/webwerkstatt/kernel instead of
>>> /repository/webwerkstatt. Paths relative to Config.codeBase therefore should
>>> be fixed (typically with another '../' at the beginning).
>>>
>>> We want to apply and commit our changes to Webwerkstatt on early Thursday
>>> morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).
>>>
>>> Please contact Lauritz or me if you have any questions or if you need
>>> assistance.
>>>
>>> Rationale:
>>>
>>> We want to create a repository of the minimum set of files that is needed
>>> for running the Lively Kernel. This could be hosted on Github, Launchpad, or
>>> elsewhere. By centralizing these files in Webwerkstatt (which is effectively
>>> our upstream repository right now), it will be possible to check them out as
>>> a Subversion submodule that can be kept in sync with other version control
>>> systems.
>>>
>>> Regards,
>>>
>>> Fabian
>>>
>>> _______________________________________________
>>>
>>> lively-kernel mailing list
>>>
>>> lively-kernel at hpi.uni-potsdam.de
>>>
>>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>>>
>>> _______________________________________________
>>> lively-kernel mailing list
>>> lively-kernel at hpi.uni-potsdam.de
>>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> lively-kernel mailing list
>>> lively-kernel at hpi.uni-potsdam.de
>>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>>>
>>>
>
>