You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2007/10/26 12:05:49 UTC
Sling-API
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
Posted by Felix Meschberger <fm...@gmail.com>.
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/27/07, Felix Meschberger <fm...@gmail.com> 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
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/29/07, Torgeir Veimo <to...@pobox.com> 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
Posted by Torgeir Veimo <to...@pobox.com>.
On 29 Oct 2007, at 14:54, Bertrand Delacretaz wrote:
> Hi Torgeir,
>
> On 10/29/07, Torgeir Veimo <to...@pobox.com> 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
torgeir@pobox.com
Re: Sling-API
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Torgeir,
On 10/29/07, Torgeir Veimo <to...@pobox.com> 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
Posted by Torgeir Veimo <to...@pobox.com>.
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
torgeir@pobox.com
Re: Sling-API
Posted by Felix Meschberger <fm...@gmail.com>.
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
Posted by Felix Meschberger <fm...@gmail.com>.
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
Posted by Tobias Bocanegra <to...@day.com>.
> 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
--
-----------------------------------------< tobias.bocanegra@day.com >---
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
Posted by Torgeir Veimo <to...@pobox.com>.
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
torgeir@pobox.com
Re: Sling-API
Posted by Felix Meschberger <fm...@gmail.com>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: Sling-API
Posted by Bertrand Delacretaz <bd...@apache.org>.
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 <fm...@gmail.com> 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<String, Object>) 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
Posted by Felix Meschberger <fm...@gmail.com>.
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<String, Object>) 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
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> On 10/26/07, Carsten Ziegeler <cz...@apache.org> 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
cziegeler@apache.org
Re: Sling-API
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 26.10.2007, 16:12 +0200 schrieb Bertrand Delacretaz:
> On 10/26/07, Carsten Ziegeler <cz...@apache.org> 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
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/26/07, Carsten Ziegeler <cz...@apache.org> 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
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> On 10/26/07, Bertrand Delacretaz <bd...@apache.org> 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
cziegeler@apache.org
Re: Sling-API
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/26/07, Bertrand Delacretaz <bd...@apache.org> 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
Posted by Bertrand Delacretaz <bd...@apache.org>.
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