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.
