Re: Sling-API
Hi, Am Freitag, den 26.10.2007, 13:39 +0200 schrieb Carsten Ziegeler: > With the new service locator using a type as an argument, I think we can > drop the NAME constant from the SlingScriptResolver interface. You are of course right :-) Regards Felix > > Carsten > > Felix Meschberger wrote: > > Hi all, > > > > Start a discussion on working on the current Component API in [1] > > Carsten launched a discsussion on simplifying the API and leaning more > > towards the original Servlet API. I took this up in issue 28 [2] and now > > committed a large chunk of updates to the sling-api project. This update > > is inspired by the recent discussions on the list and the evolution of > > microsling. > > > > To summarize, these are the most dramatic changes: > > > > > > * Content and Component removed > > The Content interface is replaced by the more generic Resource interface > > providing access to the JCR Item and the mapped object. The Component > > interface is removed. Instead the Servlet interface is used by Sling. > > The former API of the Component interface to get the Content class name > > and create Content objects was not really used and thus has been removed > > without replacement. In the future servlets will be registered as OSGi > > services which provide their identification as part of the service > > registration properties. > > > > > > * ResourceResolver > > The ResourceResolver is added and provides the functionality to access > > Resources and list children, which was formerly provided by the > > SlingRequest interface. A new ResourceManager interface extending the > > ResourceResolver is added, which may be implemented to provide seemless > > content mapping. The ResourceManager extends ResourceResolver and > > servlets may cast to get the functionality. > > > > > > * Renamed SlingRequest/Response > > The SlingRequest and SlingResponse interfaces are renamed to > > SlingHttpServletRequest and SlingHttpServletResponse respectively to > > clearly indicated that they are an extension to the respective Servlet > > API interfaces. > > The microsling SlingRequestContext is not migrated into the Sling API as > > it showed that it is easier to an extended Servlet Request/Response API > > than to always access a context from the request attributes. Through > > carefull implementation of request and response wrappers integration > > issues are minimized, too. > > > > > > * RequestPathInfo > > The RequestPathInfo interface is new and replaces the selector, > > extension, and suffix accessor methods formerly in the SlingRequest > > interface. > > > > > > * Manifest Servlet and Script support > > The core interfaces to implement servlet and scripting support are made > > part of the Sling API. Though, generally servlet implementors will not > > be confronted by these interfaces, the are made part of the API to be > > able to more easily explain how Sling is intended to work. > > > > > > * Removed "duplicate" interfaces > > ComponentFilter and ComponentFilterChain are removed. Instead the > > Servlet API Filter interface will be used. Likewise the > > ComponentContext, ComponentSession (with ComponentSessionUtil) are > > removed because they are not used anymore and do not provide any more > > functionality. > > > > * Additional helpers > > Additional helpers have been added: ProcessTracker, which may be used to > > track progress of request processing for debugging etc. purposes, and > > ServiceLocator, which may be used by servlets (most prominently scripts > > not loaded through OSGi) to access services. > > > > > > I would like to open the discussion now on this Any comments are > > welcome. Thanks in advance. > > > > Regards > > Felix > > > > PS: Yes, the vote I wanted to hold some weeks ago has of course never > > taken place due to the big impact the microsling initiative had on all > > this :-) > > > > [1] > > http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00177.html > > [2] http://issues.apache.org/jira/browse/SLING-28 > > > > > >
Re: Sling-API
With the new service locator using a type as an argument, I think we can drop the NAME constant from the SlingScriptResolver interface. Carsten Felix Meschberger wrote: > Hi all, > > Start a discussion on working on the current Component API in [1] > Carsten launched a discsussion on simplifying the API and leaning more > towards the original Servlet API. I took this up in issue 28 [2] and now > committed a large chunk of updates to the sling-api project. This update > is inspired by the recent discussions on the list and the evolution of > microsling. > > To summarize, these are the most dramatic changes: > > > * Content and Component removed > The Content interface is replaced by the more generic Resource interface > providing access to the JCR Item and the mapped object. The Component > interface is removed. Instead the Servlet interface is used by Sling. > The former API of the Component interface to get the Content class name > and create Content objects was not really used and thus has been removed > without replacement. In the future servlets will be registered as OSGi > services which provide their identification as part of the service > registration properties. > > > * ResourceResolver > The ResourceResolver is added and provides the functionality to access > Resources and list children, which was formerly provided by the > SlingRequest interface. A new ResourceManager interface extending the > ResourceResolver is added, which may be implemented to provide seemless > content mapping. The ResourceManager extends ResourceResolver and > servlets may cast to get the functionality. > > > * Renamed SlingRequest/Response > The SlingRequest and SlingResponse interfaces are renamed to > SlingHttpServletRequest and SlingHttpServletResponse respectively to > clearly indicated that they are an extension to the respective Servlet > API interfaces. > The microsling SlingRequestContext is not migrated into the Sling API as > it showed that it is easier to an extended Servlet Request/Response API > than to always access a context from the request attributes. Through > carefull implementation of request and response wrappers integration > issues are minimized, too. > > > * RequestPathInfo > The RequestPathInfo interface is new and replaces the selector, > extension, and suffix accessor methods formerly in the SlingRequest > interface. > > > * Manifest Servlet and Script support > The core interfaces to implement servlet and scripting support are made > part of the Sling API. Though, generally servlet implementors will not > be confronted by these interfaces, the are made part of the API to be > able to more easily explain how Sling is intended to work. > > > * Removed "duplicate" interfaces > ComponentFilter and ComponentFilterChain are removed. Instead the > Servlet API Filter interface will be used. Likewise the > ComponentContext, ComponentSession (with ComponentSessionUtil) are > removed because they are not used anymore and do not provide any more > functionality. > > * Additional helpers > Additional helpers have been added: ProcessTracker, which may be used to > track progress of request processing for debugging etc. purposes, and > ServiceLocator, which may be used by servlets (most prominently scripts > not loaded through OSGi) to access services. > > > I would like to open the discussion now on this Any comments are > welcome. Thanks in advance. > > Regards > Felix > > PS: Yes, the vote I wanted to hold some weeks ago has of course never > taken place due to the big impact the microsling initiative had on all > this :-) > > [1] > http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00177.html > [2] http://issues.apache.org/jira/browse/SLING-28 > > -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling-API
Bertrand Delacretaz wrote: > On 10/26/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > >> ...Here are my comments on the sling-api revision 588629 (hang on, lots of >> them ;-)... > > Forgot one important thing: > > I'd put all of this inside the "sling.api" package instead of "sling". > Dunno if this was discussed before, but IMHO this is not "Sling", this > is only its api. > I think the "api" in the package name is superfluous :) It's clear that if the package is o.a.sling that this is the api. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling-API
On 10/26/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > Bertrand Delacretaz wrote: > >... I'd put all of this inside the "sling.api" package instead of "sling" > ...I think the "api" in the package name is superfluous :) It's clear that > if the package is o.a.sling that this is the api If you see it in isolation, of course you're right. But if someone sees all the Sling code in the same tree (for example with merged javadocs from all Sling modules) you'd have something like that, not? core exceptions (*) helpers (*) jcr osgi params (*) See what I mean? The (*) packages are from the API, the others are from the implementations of the various modules. They're all mixed up now. But maybe I'm missing something -Bertrand
Re: Sling-API
Hi, Thanks Felix for the summary of changes. Overall I think this is very close to the microsling API, so if it allows Sling OSGi to work as well as it did before that's a great thing! Here are my comments on the sling-api revision 588629 (hang on, lots of them ;-) 1) The "helpers" package name Carsten mentions that in the other thread - in microsling the idea is to use "helpers" as the name of all packages which contain "boring" stuff, classes that you don't need to study to understand the API. I like that name, as it's a clear flag for people not to waste time looking at that stuff. 2) ProcessTracker The javadoc comment says "tracks the progress of request processing", so I'd call that "RequestProgressTracker" instead, "process" is too generic IMHO. 3) Service-related classes (ServiceLocator + exception) I'd put these in a "services" package, they're more than boring helpers. 4) params package It might make more sense to call this package "request", and include RequestPathInfo in there. 5) MetaData I'd call this ResourceMetadata instead, MetaData is too generic, and "metadata" is one word so I don't like the CamelCaseDInTheMiddle too much. 6) SlingScript Should we use getResource() instead of getScriptPath()? In our model, a Script is always created from a Resource...not sure about that. I'd use getScriptReader() instead of getScript() as the method name. 7) SlingScriptEngine Should we have two eval() methods? eval(script, props, request, response) for servlet environments eval(script, props, reader, writer) for "internal" scripts 8) HttpConstants As we're requiring java 5, we can make this a class instead of an interface, and use it with "import static" to avoid the Constant Interface Antipattern. 9) Constants Same as HttpConstants, make that a class, and I'd rename that class to SlingConstants - there are too many Constants class out there I guess. I'd also move that class to the "helpers" package - it is not interesting to study. 10) SlingHttpServlet... I'd move these classes to the "servlets" package, and maybe move the SlingXMethodsServlets to servlets/helpers - that's what they are I think, and that would prevent the package from having too much stuff. 11) SlingScriptResolver As mentioned elsewhere, provide an additional method to resolve a script by path, or maybe resolveScript(String path,String [] pathsWhereToSearchForScripts); 12) javadocs In general I find the javadoc comments too verbose for my taste. But we can talk about that once the naming and packages are in place, maybe I'll try doing a patch to make the docs as terse as possible, without losing information, and we can decide whether we want that. Ouch...lots of comments, but that's mostly naming and package nitpicking, the actual API looks good! -Bertrand
Re: Sling-API
On 10/26/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > ...Here are my comments on the sling-api revision 588629 (hang on, lots of > them ;-)... Forgot one important thing: I'd put all of this inside the "sling.api" package instead of "sling". Dunno if this was discussed before, but IMHO this is not "Sling", this is only its api. -Bertrand
Re: Sling-API
On 26 Oct 2007, at 12:05, Felix Meschberger wrote:
* ResourceResolver
The ResourceResolver is added and provides the functionality to access
Resources and list children, which was formerly provided by the
SlingRequest interface. A new ResourceManager interface extending the
ResourceResolver is added, which may be implemented to provide
seemless
content mapping. The ResourceManager extends ResourceResolver and
servlets may cast to get the functionality.
I would like to open the discussion now on this Any comments are
welcome. Thanks in advance.
Some suggestions:
1. I still feel that the mechanism to resolve a servlet is a bit too
hard coded. I'd suggest adding a ServletResolver interface, which
would work similar to the ResourceResolver. The selectSlingServlet()
method would then resolve a Servlet using the configured
ServletResolver(s). The body of the current selectSlingServlet()
method could form a DefaultSlingServletResolver to maintain current
functionality.
public interface ServletResolver {
/**
Find the Servlet that request must process for
the loaded Resource.
*/
Servlet getServlet(HttpServletRequest request, Resource
resource) throws SlingException;
}
Example usage: I need to use a different servlet for export. I'd then
configure a ServletResolver that looks for an ?export=true request
parameter and returns the export servlet. Another example is if I
need to print debug information while coding. I'd then configure a
ServletResolver that looks for ?Debug=true parameters and returns the
debug servlet.
2. Generalise the "Servlet" into a sort of "View" component. The best
analogy is probably Struts' ActionForward class. Wouldn't it be
appropriate to use a JSP as a view component for a Resource? I feel
that having the SlingMainServlet resolve to view components is
duplicating functionality available in the servlet container. A
SlingForward could either be initialised with a resource type,
requesting handling by the appropriate SlingServlet for the resource
type, by a normal path parameter to forward to a JSP decided by the
servlet container, or some other constant to request handling by a
script execution servlet. The above interface would then contain the
method
SlingForward getSlingForward() (HttpServletRequest request, Resource
resource) throws SlingException;
3. Extend the MicroslingRequestContext implementation to resolve a
number of ResourceResolver and ServletResolver from the service
locator. They should be orderly configured, and each one tried until
one actually resolves a Resource / Servlet. This would be needed for
the suggested ServletResolver setup to be easily extended as
suggested above.
--
Torgeir Veimo
[EMAIL PROTECTED]
Re: Sling-API
Bertrand Delacretaz wrote: > On 10/26/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > >> Bertrand Delacretaz wrote: >>> ... I'd put all of this inside the "sling.api" package instead of >>> "sling" > >> ...I think the "api" in the package name is superfluous :) It's clear that >> if the package is o.a.sling that this is the api > > If you see it in isolation, of course you're right. > > But if someone sees all the Sling code in the same tree (for example > with merged javadocs from all Sling modules) you'd have something like > that, not? > > core > exceptions (*) > helpers (*) > jcr > osgi > params (*) > > See what I mean? The (*) packages are from the API, the others are > from the implementations of the various modules. They're all mixed up > now. > I think "now" is key here :) We should move implementation stuff to a sub package like "impl.foo". In addition with OSGi, implementations are private stuff and hidden and not available through the classpath. Of course this is just at runtime. But we shouldn't provide javadocs for the implementation stuff. Anyway, I think there are two solutions: a) use "api" as a sub package and imply that all api is in this package or a sub package of this. All other packages are private. b) use "impl" as sub package and imply that everything is public except stuff in "impl" sub packages. As one usually uses (should use) api stuff I prefer short package names and I would tend to b) :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling-API
> Example usage: I need to use a different servlet for export. I'd then > configure a ServletResolver that looks for an ?export=true request > parameter and returns the export servlet. wouldn't that be just a request to another resource type? eg: instead of requesting /foo/bar.html you request /foo/bar.xml which then uses the export script to export the contents of /foo/bar ? > Another example is if I > need to print debug information while coding. I'd then configure a > ServletResolver that looks for ?Debug=true parameters and returns the > debug servlet. for this use case if would setup a filter that changes the log level to debug (if there are loggers bound to a request?) for such request. having an extra debug servlet would just duplicate the code. > 2. Generalise the "Servlet" into a sort of "View" component. The best > analogy is probably Struts' ActionForward class. Wouldn't it be > appropriate to use a JSP as a view component for a Resource? no. i think the idea was for microsling to not have JSP support at all, and for sling to use the eclipse JSP compiler (which is way faster (and works with OSGI) than for example japser). regards, toby -- -< [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 >---
Re: Sling-API
Hi, Am Freitag, den 26.10.2007, 15:28 +0200 schrieb Bertrand Delacretaz: > 1) The "helpers" package name > Carsten mentions that in the other thread - in microsling the idea is > to use "helpers" as the name of all packages which contain "boring" > stuff, classes that you don't need to study to understand the API. > > I like that name, as it's a clear flag for people not to waste time > looking at that stuff. > > 2) ProcessTracker > The javadoc comment says "tracks the progress of request processing", > so I'd call that "RequestProgressTracker" instead, "process" is too > generic IMHO. Agreed. > > 3) Service-related classes (ServiceLocator + exception) > I'd put these in a "services" package, they're more than boring helpers. Agreed. > > 4) params package > It might make more sense to call this package "request", and include > RequestPathInfo in there. Agreed (and Carsten also mentioned this). > > 5) MetaData > I'd call this ResourceMetadata instead, MetaData is too generic, and > "metadata" is one word so I don't like the CamelCaseDInTheMiddle too > much. Well, I though MetaData is more generic (and I see it as two words). But I agree, we should probably call it ResourceMetadata. > > 6) SlingScript > Should we use getResource() instead of getScriptPath()? In our model, > a Script is always created from a Resource...not sure about that. I don't think, that a script is always a resource. It might also be an OSGi service registered with the given path. In this case of course the "path" is not actually the absolute correct word. I would not change this to a Resource in this use case. > > I'd use getScriptReader() instead of getScript() as the method name. Agreed. > > 7) SlingScriptEngine > > Should we have two eval() methods? > > eval(script, props, request, response) for servlet environments > > eval(script, props, reader, writer) for "internal" scripts I think eval(Script, Map) suffices it and should encompass enough information needed. > > 8) HttpConstants > As we're requiring java 5, we can make this a class instead of an > interface, and use it with "import static" to avoid the Constant > Interface Antipattern. Agreed > > 9) Constants > Same as HttpConstants, make that a class, and I'd rename that class to > SlingConstants - there are too many Constants class out there I guess. Agreed. BTW: The Constants interface is not implemented in any part of Sling (AFAIK) exactly for this reason. But making it a class, is also ok. > > I'd also move that class to the "helpers" package - it is not > interesting to study. I do not actually agree. But it is just sort of a guts feeling :-) > > 10) SlingHttpServlet... > I'd move these classes to the "servlets" package, and maybe move the > SlingXMethodsServlets to servlets/helpers - that's what they are I > think, and that would prevent the package from having too much stuff. I do not agree as the SlingHttpServletRequest/Response interfaces are two of the central interfaces of interest to Sling programmers: These are the first interfaces they are confronted with, so I would rather keep them upfront. > > 11) SlingScriptResolver > As mentioned elsewhere, provide an additional method to resolve a > script by path, or maybe > > resolveScript(String path,String [] pathsWhereToSearchForScripts); Agreed with exception: I think the search path thing is either an implementation specific functionality or may be described by a getter (don't like setter in interfaces :-) ). I would not add this parameter to the signature of the resolveScript method. > > 12) javadocs > In general I find the javadoc comments too verbose for my taste. But > we can talk about that once the naming and packages are in place, > maybe I'll try doing a patch to make the docs as terse as possible, > without losing information, and we can decide whether we want that. Well, I disagree :-) The API speficies a central part of Sling and as such should be specific as much as possible to not run the danger of being underspecified and thus create problems in the future, where people might expect something, which does not match the implementation. > Ouch...lots of comments, but that's mostly naming and package > nitpicking, the actual API looks good! Thanks, but as the changes are big, comments will be big :-) Regards Felix
Re: Sling-API
Hi, Am Freitag, den 26.10.2007, 16:12 +0200 schrieb Bertrand Delacretaz: > On 10/26/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > > Bertrand Delacretaz wrote: > > >... I'd put all of this inside the "sling.api" package instead of > > >"sling" > > > ...I think the "api" in the package name is superfluous :) It's clear that > > if the package is o.a.sling that this is the api > > If you see it in isolation, of course you're right. > > But if someone sees all the Sling code in the same tree (for example > with merged javadocs from all Sling modules) you'd have something like I am not sure, whether one thing (use an o.a.s.api root package) or the other (leave it as is) is the better solution. I think leaving it as is provides a clear structure of the Sling API and it aligns nicely with other API specs like JCR, Servlet. But These specs live in their own, isolated namespace below javax., which is reserved for API only, while the implementations are in namespaces generally defined after their project name, e.g. o.a.jackrabbit for the JCR RI. Going further ahead towards Sling and OSGi bundles, where we generally try to have all code in a single and specific package space upto the point, where the bundle symbolic name is the same as name of the root package. As such, having a root o.a.s.api package whould make lives easier. In the end, though I am at unease with the o.a.s.api idea, I agree with it because it probably is the cleanest way to separate the package spaces - unless we get javax.sling :-) But this is definitely not on my agenda. Regards Felix
Re: Sling-API
Am Freitag, den 26.10.2007, 21:52 +0200 schrieb Tobias Bocanegra: > all, and for sling to use the eclipse JSP compiler (which is way > faster (and works with OSGI) than for example japser). Well this is not quite correct :-) Sling uses Jasper with the Eclipse Java Compiler. When comparing performance, the comparison is between the Eclipse Java Compiler, which has a clean and defined API and is used just any other class, and the JDK compiler (generally from tools.jar) which is called as an external process. This gives the performance gain of Eclipse: No commandline building, no external Java startup etc. In addition, the Eclipse Compiler may work with any class loader where as the external Java Compiler requires a complex class path setup. Regards Felix
Re: Sling-API
Hi, Am Freitag, den 26.10.2007, 16:38 +0200 schrieb Torgeir Veimo: > Some suggestions: > > 1. I still feel that the mechanism to resolve a servlet is a bit too > hard coded. I'd suggest adding a ServletResolver interface, which > would work similar to the ResourceResolver. The selectSlingServlet() > method would then resolve a Servlet using the configured > ServletResolver(s). The body of the current selectSlingServlet() > method could form a DefaultSlingServletResolver to maintain current > functionality. Completely agree with you. Fact is that the sling-api project has a ServletResolver which works similar to the ResourceResolver and takes the Resource into account for resolving a Servlet to handle the request. The current microsling selectSlingServlet method in the main servlet is of course not the role model for the real task. > 2. Generalise the "Servlet" into a sort of "View" component. The best > analogy is probably Struts' ActionForward class. Wouldn't it be > appropriate to use a JSP as a view component for a Resource? I feel > that having the SlingMainServlet resolve to view components is > duplicating functionality available in the servlet container. A > SlingForward could either be initialised with a resource type, > requesting handling by the appropriate SlingServlet for the resource > type, by a normal path parameter to forward to a JSP decided by the > servlet container, or some other constant to request handling by a > script execution servlet. The above interface would then contain the > method This is too much overhead and in fact is one of the main concerns I have with Struts. I think the current solution of resolving the request to a Servlet (taking the Resource and other request properties (method, selectors, extension) into account is appropriate. If the response should be rendered by another Servlet (be it a normal servlet, be it a script, or whatever) may be implemented by standard request forwarding. > 3. Extend the MicroslingRequestContext implementation to resolve a > number of ResourceResolver and ServletResolver from the service > locator. They should be orderly configured, and each one tried until > one actually resolves a Resource / Servlet. This would be needed for > the suggested ServletResolver setup to be easily extended as > suggested above. I do not think, that this is appropriate for microsling. For the real Sling we might implement such feature of chained Resource- and ServletResolvers as actual requirements would raise. On the API level, I would not codify this. Regards Felix
Re: Sling-API
Hi, Thanks Felix for the API changes - the packages structure looks very understandable to me now, I think that's a great step in making Sling easy to understand. On 10/27/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > Bertrand: > > ...7) SlingScriptEngine > > > > Should we have two eval() methods? > > > > eval(script, props, request, response) for servlet environments > > > > eval(script, props, reader, writer) for "internal" scripts > > I think eval(Script, Map) suffices it and should > encompass enough information needed You're right, but coming back to my original motivation for the second eval() above, I think scripts need access to the logging framework. Should be add a "log" variable to the standard scripting variables defined by SlingScriptEngine? > >... 9) Constants > > ... > > I'd also move that class to the "helpers" package - it is not > > interesting to study. > > I do not actually agree. But it is just sort of a guts feeling :-)... Ok to keep Constants right under the api package. > >... 10) SlingHttpServlet... > > I'd move these classes to the "servlets" package, and maybe move the > > SlingXMethodsServlets to servlets/helpers - that's what they are I > > think, and that would prevent the package from having too much stuff. > > I do not agree as the SlingHttpServletRequest/Response interfaces are > two of the central interfaces of interest to Sling programmers: These > are the first interfaces they are confronted with, so I would rather > keep them upfront Ok about them being important, but are they *so* important as to be right in the api package? Why can't we move them to their respective "request" and "response" packages? > > ...12) javadocs > > In general I find the javadoc comments too verbose for my taste > Well, I disagree :-) The API speficies a central part of Sling and as > such should be specific as much as possible to not run the danger of > being underspecified and thus create problems in the future, where > people might expect something, which does not match the implementation I did not mean to remove any information from the javadocs, just write things in a terser way. But this is not critical to getting the API right, so I'd suggest keeping this javadocs discussion for later. -Bertrand
Re: Sling-API
On 10/27/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Am Freitag, den 26.10.2007, 16:38 +0200 schrieb Torgeir Veimo: > >... 2. Generalise the "Servlet" into a sort of "View" component. The best > > analogy is probably Struts' ActionForward class... > ...This is too much overhead and in fact is one of the main concerns I have > with Struts. ... > ...If the response > should be rendered by another Servlet (be it a normal servlet, be it a > script, or whatever) may be implemented by standard request forwarding... I see your point, but I have also this vague feeling that microsling and the Sling API could better separate (or maybe just better expose) the "processing" and "rendering" phases of a request. Felix, how would you suggest implementing a POST script that renders data when done processing? Do a request forwarding at the end of the POST script? That might be ok, but the programmer might want to specify exactly which rendering script they want to use after the POST, so some short-circuit of the standard Resource/SlingScript resolution might be needed. WDYT? > >... 3. Extend the MicroslingRequestContext implementation to resolve a > > number of ResourceResolver and ServletResolver from the service > > locator... > I do not think, that this is appropriate for microsling... Dunno...Torgeir, if you need this in microsling, and if you can provide simple code to implement it, I'd be +1 on putting this in microsling. But I agree with Felix that not having this in microsling still allows Sling to have that, based on OSGi "plugins".. -Bertrand
Re: Sling-API
On 27 Oct 2007, at 16:42, Felix Meschberger wrote: Hi, Am Freitag, den 26.10.2007, 16:38 +0200 schrieb Torgeir Veimo: Some suggestions: 2. Generalise the "Servlet" into a sort of "View" component. The best analogy is probably Struts' ActionForward class. Wouldn't it be appropriate to use a JSP as a view component for a Resource? I feel that having the SlingMainServlet resolve to view components is duplicating functionality available in the servlet container. A SlingForward could either be initialised with a resource type, requesting handling by the appropriate SlingServlet for the resource type, by a normal path parameter to forward to a JSP decided by the servlet container, or some other constant to request handling by a script execution servlet. The above interface would then contain the method This is too much overhead and in fact is one of the main concerns I have with Struts. I think the current solution of resolving the request to a Servlet (taking the Resource and other request properties (method, selectors, extension) into account is appropriate. If the response should be rendered by another Servlet (be it a normal servlet, be it a script, or whatever) may be implemented by standard request forwarding. My main concern is that I'm interested in seeing model resolution and view resolution separated. I guess with the current framework, model resolution is opaque to Sling, and the Resource component represents the "view". A better example than in my previous message is a blog. Ideally, the model for the blog would be loaded first. Then, depending on the view being RSS or normal HTML view, a view resolver would direct to the correct Servlet. With the current framework, a single component would be needed for both RSS and normal view? 3. Extend the MicroslingRequestContext implementation to resolve a number of ResourceResolver and ServletResolver from the service locator. They should be orderly configured, and each one tried until one actually resolves a Resource / Servlet. This would be needed for the suggested ServletResolver setup to be easily extended as suggested above. I do not think, that this is appropriate for microsling. For the real Sling we might implement such feature of chained Resource- and ServletResolvers as actual requirements would raise. On the API level, I would not codify this. The reason for this is to facilitate overriding the default resolver. How would you do that in a situation where you need only a few special cases, but otherwise the default behaviour? My preference for such cases would be to have it in the API, since it would otherwise require using implementation specific coding. -- Torgeir Veimo [EMAIL PROTECTED]
Re: Sling-API
Hi Torgeir, On 10/29/07, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > >> ...2. Generalise the "Servlet" into a sort of "View" component. The best > >> analogy is probably Struts' ActionForward class > ...My main concern is that I'm interested in seeing model resolution and > view resolution separated. I guess with the current framework, model > resolution is opaque to Sling, and the Resource component represents > the "view" Not sure what you mean by "Resource component". In microsling (which drives the Sling API redesign), Components are gone, there's only -The Resource, which represents, in its simplest form, a JCR Node -The Servlet (or script) which handles the request So, although MVC does not really apply here, If we want to think in MVC terms I'd say the Resource is the Model, and the Servlet is the view (in the case of a GET method), or the controller (in the case of a POST/PUT/DELETE/unsafe) method. If we follow this reasoning, you'd handle a POST request by having microsling call a first "controller" script that manipulates data, and forwards to a GET request which calls the "view" script. Does that make sense to you? I think working in this way might help people embrace the REST style, which is IMHO a nice side effect. > ...A better example than in my previous message is a blog. Ideally, the > model for the blog would be loaded first. Then, depending on the view > being RSS or normal HTML view, a view resolver would direct to the > correct Servlet. With the current framework, a single component would > be needed for both RSS and normal view?... If by component you mean a microsling Servlet/Script, then the answer is no: the request selectors (.rss.xml) or extension (.rss) will cause a different rendering script to be used. > >> 3. Extend the MicroslingRequestContext implementation to resolve a > >> number of ResourceResolver and ServletResolver from the service > >> locator > ...The reason for this is to facilitate overriding the default resolver. > How would you do that in a situation where you need only a few > special cases, but otherwise the default behaviour?... I think we all agree on that for Sling, but do we want this in microsling, and if yes how do we implement that cleanly? The easiest thing that comes to mind is a composite pattern: as seen from the API, there's only one ResourceResolver, but internally that ResourceResolver can use a chain of ResourceResolvers. -Bertrand
Re: Sling-API
On 29 Oct 2007, at 14:54, Bertrand Delacretaz wrote: Hi Torgeir, On 10/29/07, Torgeir Veimo <[EMAIL PROTECTED]> wrote: ...2. Generalise the "Servlet" into a sort of "View" component. The best analogy is probably Struts' ActionForward class ...My main concern is that I'm interested in seeing model resolution and view resolution separated. I guess with the current framework, model resolution is opaque to Sling, and the Resource component represents the "view" Not sure what you mean by "Resource component". In microsling (which drives the Sling API redesign), Components are gone, there's only -The Resource, which represents, in its simplest form, a JCR Node -The Servlet (or script) which handles the request So, although MVC does not really apply here, If we want to think in MVC terms I'd say the Resource is the Model, and the Servlet is the view (in the case of a GET method), or the controller (in the case of a POST/PUT/DELETE/unsafe) method. If we follow this reasoning, you'd handle a POST request by having microsling call a first "controller" script that manipulates data, and forwards to a GET request which calls the "view" script. Does that make sense to you? I think working in this way might help people embrace the REST style, which is IMHO a nice side effect. Yes I guess the terminology is a bit confusing. A Resource is also something used in WebDAV. But I guess the naming issue is done and dusted already. ...A better example than in my previous message is a blog. Ideally, the model for the blog would be loaded first. Then, depending on the view being RSS or normal HTML view, a view resolver would direct to the correct Servlet. With the current framework, a single component would be needed for both RSS and normal view?... If by component you mean a microsling Servlet/Script, then the answer is no: the request selectors (.rss.xml) or extension (.rss) will cause a different rendering script to be used. This is fine for new implementation. What if one need to implement legacy services, where the url patterns used are different? Providing the request selector as the default mechanism is good. Having it as the only mechanism is bad. 3. Extend the MicroslingRequestContext implementation to resolve a number of ResourceResolver and ServletResolver from the service locator ...The reason for this is to facilitate overriding the default resolver. How would you do that in a situation where you need only a few special cases, but otherwise the default behaviour?... I think we all agree on that for Sling, but do we want this in microsling, and if yes how do we implement that cleanly? The easiest thing that comes to mind is a composite pattern: as seen from the API, there's only one ResourceResolver, but internally that ResourceResolver can use a chain of ResourceResolvers. Ok, Felix also stated this clearly. My preference would be to have only one sling, where OSGi is optional though. -- Torgeir Veimo [EMAIL PROTECTED]
Re: Sling-API
On 10/29/07, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > ...Yes I guess the terminology is a bit confusing. A Resource is also > something used in WebDAV. But I guess the naming issue is done and > dusted already Yes, obviously Resource can mean different things, but in our quest to expose the REST style it seems to be the best name. We can always talk about a "Sling Resource" if we need to qualify it. > ...This is fine for new implementation. What if one need to implement > legacy services, where the url patterns used are different? > > Providing the request selector as the default mechanism is good. > Having it as the only mechanism is bad Agreed. Although microsling is not meant to be "user-extensible", it is sufficiently simple (and will be even smaller once it uses the sling-api that we're discussing here) that one can replace any part of it easily by extending classes. And in Sling OSGi, I guess pretty much everything can be replaced by way of OSGi bundles. > ...My preference would be to have > only one sling, where OSGi is optional though Considering the discussions in the last few weeks, it seems like we're headed for a lightweight microsling, meant mostly as an educational/demo tool but also usable for simple applications, and the full-blown Sling, based on OSGi, extensible, etc. Both are based on the same API, and the microsling code will be very small, so I think that's a good approach. But, depending on how people use microsling and Sling, we might migrate software components "down" or "up" until we find the right balance. -Bertrand
Re: Sling-API
Hi, Am Montag, den 29.10.2007, 11:12 +0200 schrieb Bertrand Delacretaz: > Felix, how would you suggest implementing a POST script that renders > data when done processing? Do a request forwarding at the end of the > POST script? > > That might be ok, but the programmer might want to specify exactly > which rendering script they want to use after the POST, so some > short-circuit of the standard Resource/SlingScript resolution might be > needed. WDYT? It all depends :-) It might be just send a redirect response to the client, which also would solve the reload issue on the response sent back. It might to an include of the same resource providing a request wrapper overwriting the getMethod method, it might just call the doGet method on itself, it might try to resolve a getter script I thend to like the redirect option most, as it allows for fixing the reload situation in the browsers. Regards Felix
Re: Sling API: RequestPathInfo
On 10/31/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...My opinion is: null should be returned... Agreed, that's probably easier to use. -Bertrand
Re: Sling API: RequestPathInfo
Felix Meschberger wrote: > Hi all, > > The RequestPathInfo interface is currently defined to return empty > strings (or empty array for one method) if no extension, selectors, > suffix exists in the request URL. This makes checking for existence of > any of the parts somewhat complicated. On the other hand to build a > string, you just print the respective method result and don't worry for > null values. > > I would like to quickly poll on the list, what the general impression is > on the question: Should null or an empty instance (String, array) be > returned in the absence of the respective path part ? > > My opinion is: null should be returned. > I'm definitly +1 for null for strings, I'm not sure if that's the best thing for arrays though, there I would prefer an empty array - but if I'm the only one, null is fine as well. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling API: RequestPathInfo
Felix Meschberger wrote: The RequestPathInfo interface is currently defined to return empty strings (or empty array for one method) if no extension, selectors, suffix exists in the request URL. This makes checking for existence of any of the parts somewhat complicated. On the other hand to build a string, you just print the respective method result and don't worry for null values. an empty string for selectorString is probably ambiguous. what's the selectorString for the following URI: /foo/bar..html ? I think this is the only case where it should return an empty string. I would like to quickly poll on the list, what the general impression is on the question: Should null or an empty instance (String, array) be returned in the absence of the respective path part ? I'd return an empty array, and in all other cases null if a URI part is absent. regards marcel
Re: Sling API: Script interface
On 11/2/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Am Freitag, den 02.11.2007, 09:33 +0100 schrieb Bertrand Delacretaz: > > That calls for some sort of Resolver, to get the script's InputStream ;-)... > ...One simple (stupid ?) solution would be to add a getInputStream() method > to the resource... Could we make that a sub-interface? Maybe StreamableResource, extends Resource, with the getInputStream(), getReader() and related methods? -Bertrand
Re: Sling API: Script interface
Hi, Am Freitag, den 02.11.2007, 09:33 +0100 schrieb Bertrand Delacretaz: > That calls for some sort of Resolver, to get the script's InputStream ;-) > > We might want to generalize that at some point, as the same problem > might arise with other files besides scripts: CSS stylesheets, static > images, etc. which it might be useful to retrieve from bundles. We > don't need that right now but we might want to take that into account > in the design. Right. One simple (stupid ?) solution would be to add a getInputStream() method to the resource. And maybe if the resource is to contain text a getReader() or a getCharacterEncoding() method ? Or would this be too much ? Regards Felix
Re: Sling API: Script interface
On 11/2/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...While thinking about the scripting in the real Sling yesterday I > thought, that we should not only support scripts in the repository but > also in the OSGi bundles Sounds good. > ...So Carsten and me came to the conclusion to take up Betrand's early idea > again of having a Resource in the Script instead of the script path Ok, now that we have a concrete use case that sounds good as well. > ...This way, the ScriptResolver may look up the scripts in the repository > and create JCR based Resource instances in this case. Of finding a > script in a Bundle would create a Resource whose raw data is the URL to > the script file in the bundle That calls for some sort of Resolver, to get the script's InputStream ;-) We might want to generalize that at some point, as the same problem might arise with other files besides scripts: CSS stylesheets, static images, etc. which it might be useful to retrieve from bundles. We don't need that right now but we might want to take that into account in the design. > ...By using this information, the ScriptEngine implementations can still > access the script source transparently (the getScriptReader() method is > the primary accessor to the script source) while for example JSP support > may be slightly more intelligent (and involved) and be able to find the > class files for the JSP based on the script resource raw data Sounds good, and some form Resolver that keeps track of where a Resource comes from might also help here. -Bertrand
Re: Sling API: Script interface
Am Freitag, den 02.11.2007, 09:49 +0100 schrieb Bertrand Delacretaz: > On 11/2/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > Am Freitag, den 02.11.2007, 09:33 +0100 schrieb Bertrand Delacretaz: > > > That calls for some sort of Resolver, to get the script's InputStream > > > ;-)... > > > ...One simple (stupid ?) solution would be to add a getInputStream() method > > to the resource... > > Could we make that a sub-interface? Maybe StreamableResource, extends > Resource, with the > getInputStream(), getReader() and related methods? I am not sure, whether it is worth it having a separate interface for that. What would be the advantage of NOT adding the getInputStream method to the Resource interface over having the method defined as returning null if no InputStream was available ? I am really not sure, whether actually a getReader method would be worth it... Regards Felix
Re: Sling API: Script interface
On 11/5/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Am Freitag, den 02.11.2007, 09:49 +0100 schrieb Bertrand Delacretaz: > > On 11/2/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > ...One simple (stupid ?) solution would be to add a getInputStream() > > > method > > > to the resource... > > > > Could we make that a sub-interface? Maybe StreamableResource,... > ...I am not sure, whether it is worth it having a separate interface for > that. What would be the advantage of NOT adding the getInputStream > method to the Resource interface... If it's just one method, ok. But if we need more than one method for StreamableResources, I think that should be a separate interface. -Bertrand
Re: Sling API: Script interface
Am Montag, den 05.11.2007, 19:50 +0100 schrieb Bertrand Delacretaz: > On 11/5/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > Am Freitag, den 02.11.2007, 09:49 +0100 schrieb Bertrand Delacretaz: > > > On 11/2/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > ...One simple (stupid ?) solution would be to add a getInputStream() > > > > method > > > > to the resource... > > > > > > Could we make that a sub-interface? Maybe StreamableResource,... > > > ...I am not sure, whether it is worth it having a separate interface for > > that. What would be the advantage of NOT adding the getInputStream > > method to the Resource interface... > > If it's just one method, ok. But if we need more than one method for > StreamableResources, I think that should be a separate interface. On second thought, I doubt whether a getReader method would be needed, getInputStream would probably suffice it. Regards Felix
Re: Sling API: Script interface
Felix Meschberger wrote: > Am Montag, den 05.11.2007, 19:50 +0100 schrieb Bertrand Delacretaz: >> On 11/5/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: >> >>> Am Freitag, den 02.11.2007, 09:49 +0100 schrieb Bertrand Delacretaz: On 11/2/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...One simple (stupid ?) solution would be to add a getInputStream() > method > to the resource... Could we make that a sub-interface? Maybe StreamableResource,... >>> ...I am not sure, whether it is worth it having a separate interface for >>> that. What would be the advantage of NOT adding the getInputStream >>> method to the Resource interface... >> If it's just one method, ok. But if we need more than one method for >> StreamableResources, I think that should be a separate interface. > > On second thought, I doubt whether a getReader method would be needed, > getInputStream would probably suffice it. > Yes, getInputStream is enough, but I think we need a getContentType() as well - or add it as a predefined constant to the ResourceMetadata. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling API: Script interface
Am Dienstag, den 06.11.2007, 08:06 +0100 schrieb Carsten Ziegeler: > Felix Meschberger wrote: > > Am Montag, den 05.11.2007, 19:50 +0100 schrieb Bertrand Delacretaz: > >> On 11/5/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > >> > >>> Am Freitag, den 02.11.2007, 09:49 +0100 schrieb Bertrand Delacretaz: > On 11/2/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > ...One simple (stupid ?) solution would be to add a getInputStream() > > method > > to the resource... > Could we make that a sub-interface? Maybe StreamableResource,... > >>> ...I am not sure, whether it is worth it having a separate interface for > >>> that. What would be the advantage of NOT adding the getInputStream > >>> method to the Resource interface... > >> If it's just one method, ok. But if we need more than one method for > >> StreamableResources, I think that should be a separate interface. > > > > On second thought, I doubt whether a getReader method would be needed, > > getInputStream would probably suffice it. > > > Yes, getInputStream is enough, but I think we need a getContentType() as > well - or add it as a predefined constant to the ResourceMetadata. Not sure, whether Content Type is what we really need. To create a reader the character encoding would be required. Adding such a constant to the resource metadata (default to UTF-8 if missing) sounds reasonable. Regards Felix
Re: Sling API: Script interface
Felix Meschberger wrote: > Am Dienstag, den 06.11.2007, 08:06 +0100 schrieb Carsten Ziegeler: >> Felix Meschberger wrote: >>> Am Montag, den 05.11.2007, 19:50 +0100 schrieb Bertrand Delacretaz: On 11/5/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Am Freitag, den 02.11.2007, 09:49 +0100 schrieb Bertrand Delacretaz: >> On 11/2/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: >>> ...One simple (stupid ?) solution would be to add a getInputStream() >>> method >>> to the resource... >> Could we make that a sub-interface? Maybe StreamableResource,... > ...I am not sure, whether it is worth it having a separate interface for > that. What would be the advantage of NOT adding the getInputStream > method to the Resource interface... If it's just one method, ok. But if we need more than one method for StreamableResources, I think that should be a separate interface. >>> On second thought, I doubt whether a getReader method would be needed, >>> getInputStream would probably suffice it. >>> >> Yes, getInputStream is enough, but I think we need a getContentType() as >> well - or add it as a predefined constant to the ResourceMetadata. > > Not sure, whether Content Type is what we really need. To create a > reader the character encoding would be required. Adding such a constant > to the resource metadata (default to UTF-8 if missing) sounds > reasonable. > Hmm, yes, for character encoding makes sense for this; but I thought of content type :) So I have a chance to detect if it's either text, xml, an image etc. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling API: Script interface
Am Dienstag, den 06.11.2007, 14:46 +0100 schrieb Carsten Ziegeler: > Felix Meschberger wrote: > > Am Dienstag, den 06.11.2007, 08:06 +0100 schrieb Carsten Ziegeler: > >> Felix Meschberger wrote: > >>> Am Montag, den 05.11.2007, 19:50 +0100 schrieb Bertrand Delacretaz: > On 11/5/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > Am Freitag, den 02.11.2007, 09:49 +0100 schrieb Bertrand Delacretaz: > >> On 11/2/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > >>> ...One simple (stupid ?) solution would be to add a getInputStream() > >>> method > >>> to the resource... > >> Could we make that a sub-interface? Maybe StreamableResource,... > > ...I am not sure, whether it is worth it having a separate interface for > > that. What would be the advantage of NOT adding the getInputStream > > method to the Resource interface... > If it's just one method, ok. But if we need more than one method for > StreamableResources, I think that should be a separate interface. > >>> On second thought, I doubt whether a getReader method would be needed, > >>> getInputStream would probably suffice it. > >>> > >> Yes, getInputStream is enough, but I think we need a getContentType() as > >> well - or add it as a predefined constant to the ResourceMetadata. > > > > Not sure, whether Content Type is what we really need. To create a > > reader the character encoding would be required. Adding such a constant > > to the resource metadata (default to UTF-8 if missing) sounds > > reasonable. > > > Hmm, yes, for character encoding makes sense for this; but I thought of > content type :) So I have a chance to detect if it's either text, xml, > an image etc. How about defining metadata properties for the nt:folder/nt:file/nt:resource metadata information: creation time, last modification time, character encoding, content type. For nt:file nodes, this could be deduced from the respective properties while for other nodes it is up to the implementation whether such properties exist or not. Now, this gets long :-) Regards Felix
Re: Sling API: Script interface
Felix Meschberger wrote > > How about defining metadata properties for the > nt:folder/nt:file/nt:resource metadata information: creation time, last > modification time, character encoding, content type. For nt:file nodes, > this could be deduced from the respective properties while for other > nodes it is up to the implementation whether such properties exist or > not. +1, sounds good > > Now, this gets long :-) :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling API: Script interface
Created issue SLING-99 [1] to track this enhancement. Regards Felix [1] https://issues.apache.org/jira/browse/SLING-99 Am Mittwoch, den 07.11.2007, 09:55 +0100 schrieb Carsten Ziegeler: > Felix Meschberger wrote > > > > How about defining metadata properties for the > > nt:folder/nt:file/nt:resource metadata information: creation time, last > > modification time, character encoding, content type. For nt:file nodes, > > this could be deduced from the respective properties while for other > > nodes it is up to the implementation whether such properties exist or > > not. > +1, sounds good > > > > > Now, this gets long :-) > :) > > Carsten >
Re: Sling API: Script interface
On 11/7/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...[1] https://issues.apache.org/jira/browse/SLING-99.. +1 to what's proposed there. -Bertrand
Re: [Sling API] ResourceWrapper and SyntheticResource
> I would like to propose to create a ResourceWrapper class in the Sling > API, which is just a simple wrapper around a delegatee resource > analogous to what we have for servlet requests and responses. This > simplifies the creation of pseudo-resources, for example to create > resource based on another resource but with a different resource type. great. > Second, I propose to move the SyntheticResource class from the > jcr/resource project to the Sling API because this class is by now way > related to a JCR repository. Rather it is very usefull in general > projects. could the synthetic resource be more intelligent? i would be very convenient if it could adapt to node (if the node at the path exists.) i suggest a: ResourceResolver.createSynthetic(String path, String resorceType); regards, toby -- -< [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 >---
Re: [Sling API] ResourceWrapper and SyntheticResource
On Feb 6, 2008 9:26 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...I would like to propose to create a ResourceWrapper class in the Sling > API, which is just a simple wrapper around a delegatee resource > analogous to what we have for servlet requests and responses +1 > Second, I propose to move the SyntheticResource class from the > jcr/resource project to the Sling API ... +1 -Bertrand
Re: [Sling API] ResourceWrapper and SyntheticResource
Am Mittwoch, den 06.02.2008, 09:54 +0100 schrieb Tobias Bocanegra: > > I would like to propose to create a ResourceWrapper class in the Sling > > API, which is just a simple wrapper around a delegatee resource > > analogous to what we have for servlet requests and responses. This > > simplifies the creation of pseudo-resources, for example to create > > resource based on another resource but with a different resource type. > great. > > > Second, I propose to move the SyntheticResource class from the > > jcr/resource project to the Sling API because this class is by now way > > related to a JCR repository. Rather it is very usefull in general > > projects. > could the synthetic resource be more intelligent? i would be very convenient > if it could adapt to node (if the node at the path exists.) If you would want to just overwrite the resource type with a synthetic resource, I suggest to use a ResourceWrapper overwriting the getResourceType() method. Thus you get the resource type you want but still get the node underlying the actual resource. Regards Felix > > i suggest a: ResourceResolver.createSynthetic(String path, String > resorceType); > > regards, toby
Re: [Sling API] ResourceWrapper and SyntheticResource
> > > I would like to propose to create a ResourceWrapper class in the Sling > > > API, which is just a simple wrapper around a delegatee resource > > > analogous to what we have for servlet requests and responses. This > > > simplifies the creation of pseudo-resources, for example to create > > > resource based on another resource but with a different resource type. > > great. > > > > > Second, I propose to move the SyntheticResource class from the > > > jcr/resource project to the Sling API because this class is by now way > > > related to a JCR repository. Rather it is very usefull in general > > > projects. > > could the synthetic resource be more intelligent? i would be very convenient > > if it could adapt to node (if the node at the path exists.) > > If you would want to just overwrite the resource type with a synthetic > resource, I suggest to use a ResourceWrapper overwriting the > getResourceType() method. Thus you get the resource type you want but > still get the node underlying the actual resource. of course :-) -- -< [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 >---
Re: [Sling API] ResourceWrapper and SyntheticResource
On Feb 6, 2008, at 12:26 AM, Felix Meschberger wrote: Hi all, I would like to propose to create a ResourceWrapper class in the Sling API, which is just a simple wrapper around a delegatee resource analogous to what we have for servlet requests and responses. This simplifies the creation of pseudo-resources, for example to create resource based on another resource but with a different resource type. That would be helpful. Second, I propose to move the SyntheticResource class from the jcr/resource project to the Sling API because this class is by now way related to a JCR repository. Rather it is very usefull in general projects. +1 WDYT ? Regards Felix
Re: Sling API: Hanlding non-existing resources in ResourceResolver
Felix Meschberger wrote: > Hi all, > > Currently the ResourceResolver.resolve(ServletRequest request) method > throws a ResourceNotFoundException if the request cannot be resolved to > a resource. This makes it virtually impossible to easily and > transparently handle requests for resource creation. > > This in fact is also an overseen difference between microsling and > Sling: microsling is built around accepting missing resources while > Sling throws 404 unconditionally if a request cannot be resolved to a > resource. This prevents applications trying to create resources. > > As a fix I propose the introduction of a new special resource type > "sling:nonexisting", which is to be used by the ResourceResolver.resolve > method to create a pseudo-Resource from the request path (rawData and > object are both null). This may then be used to create the resource, > such as in the DefaultSlingServlet. (The nice thing about the > sling:nonexisting resource type is, that of course scripts may be > created to handle respective methods for these types). > > Consquences in the API: The methods of the ResourceResolver and > ResourceManager interfaces throwing a ResourceNotFoundException are > modified to return null if a Resource cannot be found (except the > resolve method which always returns a Resource instance, with the > sling:nonexisting resource type in the case of nonexisting resources). > And of course the ResourceNodeFoundException is dropped as it is not > needed any more. > > I will modify the API to reflect this proposal. > > WDYT ? > +1 :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling API: Hanlding non-existing resources in ResourceResolver
On 11/1/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...As a fix I propose the introduction of a new special resource type > "sling:nonexisting", which is to be used by the ResourceResolver.resolve > method to create a pseudo-Resource from the request path (rawData and > object are both null) Ok, and I'd make this pseudo resource an API class. Having a NonExistingResource class with resourceType=sling:nonexisting might make things clearer, and exposing this class in the API makes the mechanism more obvious. > ...I will modify the API to reflect this proposal... +1 -Bertrand
Re: Sling API: Hanlding non-existing resources in ResourceResolver
Sounds good to me, I never like throwing an exception if something cannot be found, as that seems to be a normal state when looking things up. -paddy On Nov 1, 2007, at 5:53 AM, Carsten Ziegeler wrote: Felix Meschberger wrote: Hi all, Currently the ResourceResolver.resolve(ServletRequest request) method throws a ResourceNotFoundException if the request cannot be resolved to a resource. This makes it virtually impossible to easily and transparently handle requests for resource creation. This in fact is also an overseen difference between microsling and Sling: microsling is built around accepting missing resources while Sling throws 404 unconditionally if a request cannot be resolved to a resource. This prevents applications trying to create resources. As a fix I propose the introduction of a new special resource type "sling:nonexisting", which is to be used by the ResourceResolver.resolve method to create a pseudo-Resource from the request path (rawData and object are both null). This may then be used to create the resource, such as in the DefaultSlingServlet. (The nice thing about the sling:nonexisting resource type is, that of course scripts may be created to handle respective methods for these types). Consquences in the API: The methods of the ResourceResolver and ResourceManager interfaces throwing a ResourceNotFoundException are modified to return null if a Resource cannot be found (except the resolve method which always returns a Resource instance, with the sling:nonexisting resource type in the case of nonexisting resources). And of course the ResourceNodeFoundException is dropped as it is not needed any more. I will modify the API to reflect this proposal. WDYT ? +1 :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
