Hi, Am Mittwoch, den 18.06.2008, 17:04 +0200 schrieb Bertrand Delacretaz: > I agree that replacing parts of the behavior of the standard GET and > POST servlets can be useful, but I'm not sure if this can be fully > generalized without making things too complex.
Agreed. And we should take extreme care to find out, what exactly we are trying to do ! > I have two use cases in mind where this would be useful: > > 1) Generating different flavors of JSON output, probably based on selectors Well, the JsonRendererServlet is fairly simple. If you need your own rendering, just register a servlet for json rendering (or whatever selector and/or extension you choose), copy that servlet and adapt it to suit your needs. Done. No need to worry about OO extensibility and stuff in this special case IMHO ... This was really the goal behind _not_ registering the default get servlet for specific extensions. This allows for user-supplied better/different renderings for specific extensions. If we go this way (and for simplicity etc. sake I would suggest to go this way), we might want to beautify the JsonRendererServlet to make it easier to hack up. I think the key part behind this is, that "sling/servlet/default" is actually an implicit root resource type just as java.lang.Object is the root class for all Java classes. So registering something for the "sling/servlet/default" resource type will allow you to register your own default servlets and scripts. Documentation on this is still pending (SLING-421 [2]). > 2) Allowing scripts to reuse part of the POST servlet functionality, > while customizing part of the POST request processing. This is already possible to a certain extent: The servlets/post bundle exports the SlingPostOperation interface and the AbstractSlingPostOperation abstract class to make the POST servlet extensible. Using this mechanism -- namely registering a SlingPostOperation servlet, see the interface java doc for more info -- it is possible to extend the SlingPostServlet easily. This is documented at [1]. If this does not suit your needs, we welcome any new use cases which we will certainly seek to support. Regards Felix [1] http://incubator.apache.org/sling/site/manipulating-content-the-slingpostservlet.html [2] https://issues.apache.org/jira/browse/SLING-421 > > I think 1) is fairly easy to solve by making the JsonRendererServlet > more expandable, maybe simply factoring out the instantiation of the > JsonItemWriter so that people can provide custom variants, by > registering servlets that extend JsonRendererServlet. I think this > "standard rendering customization" only makes sense for the JSON > format currently, so no need for a generalized framework. > > Solving 2) looks like a different problem, where the SlingPostServlet > functionality might need to be broken down in smaller services and > components that scripts can reuse in a modular way. > > I don't see other use cases for customizing our standard servlets at > the moment, so I feel the above two cases can be handled "locally" > without creating a generalized (and possibly complex) customization > framework. > > -Bertrand
