hi guys, > * /system/sling/console - the sling console > * /system/sling/info - the info servlet > * /system/sling/docroot/sling.js - the client side library...
this works out beautifully for me under 1.5 conditions ;) (1) the docroot mapping works at some point. which leads to the fact that i can do <script src="/sling.js">. including (explaining) /system/sling/docroot/sling.js and therefore exposing the complxity for the most common case is very painful. (1.5) we put something meaningful on /system and on /system/sling i thought quite a lot on where the "system things" should be served up from and i guess everybody knows that i am the "stick everything into the repository" guy. never the less i initially i thought these kind of system functions should be served up from some magic bundle... then i thought we could have a "sling system ws" that we sort of magically mount into /system/sling ... but in the end i think that there might well be workspaces that are "slinged" and others that are not within the same repository. so i am happy populating the /system/sling folder of every "slinged" workspace in a repository. regards, david On Thu, Apr 3, 2008 at 9:48 AM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > > And as you mention sling.js is static, so why not > > > > * /system/static/sling.js - the client side library... > the idea of the docroot is, that it can be remapped to /...so the > physical location is /system/docrot/sling.js, but is accessible via > /sling.js, for example. if no such remapping is foreseen for the > sling.js, then i would put it directly to /system/sling.js. > > btw: to put files in 'static' just because their are static is a poor > categorization (as if someone would group all 'html' in one folder and > all 'js' in another.....(group by function and not by form :-) > > regards, toby >
