very good. nice summary. i agree with all of the points. regards, toby On 10/14/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > Some notes regarding the current state of Script resolution: (1) The > script is selected by the HTTP method name. So I see no reason to also > call a ScriptHandler method of the same name. In fact, the current > SlingServlet API pretty much limits the HTTP methods supported, which > IMHO is not really a good idea. Rather the ScriptHandler should just > have a single service method which is called with the request, response > and resolved resource. > > (2) I am not sure whether resolving the script with the request > extension is useful. Rather I would use the "selectors" of the request > URL (the dot-separated parts between the node path and the extension) as > further script selectors. > > Regarding the resource: I think, we should provide the JCR item to which > the request URL resolved with a proper method, such as "Item getItem();" > and leave the "Object getDate();" method to the object mapping. In > addition, I would provide the selectors, extension and suffix in the > Resource, too, as proposed on the Wiki page. > > Providing the JCR Item and mapped object in the Resource interface > itself would of course stipulate, that microsling (and hence Sling, see > my other posting in this thread) would be based on the repository and/or > mapping and there would be no other source such as the filesystem etc. > Of course for "synthetic" Resources, the getItem() and getData() methods > might return null if there would be no more data than the path/URI and > the resource type. > > Regards > Felix > > Am Freitag, den 12.10.2007, 12:35 +0200 schrieb Bertrand Delacretaz: > > On 10/11/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > > ...I am also not sure, whether script resolution according to the resource > > > path is actually a good idea... > > > > You're right, that was a bad idea...I have added a > > > > String getResourceType(); > > > > method to the Resource interface, which is meant to point to a > > repository location where scripts and other definitions can be found. > > > > And rewritten the SlingScriptResolver to use this. > > > > Script names are also based on the request extension now, so for > > example if a scripting SlingServlet is looking for a script with a > > "vlt" extension: > > > > When rendering a Resource with resourceType=/some/stuff > > > > For a GET request with with URL extension=html > > > > The SlingScriptResolver looks for a script named > > /sling/scripts/some/stuff/get.html.vlt > > > > The updated microsling-homepage.html attached to > > https://issues.apache.org/jira/browse/SLING-47 contains links to > > source code for a quick code walkthrough. > > > > Do you guys think we need to add more stuff to microsling to reflect > > the core ideas of the Sling request processing? ResponseFilters maybe? > > > > -Bertrand. > >
-- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
