On Wed, Jul 29, 2009 at 9:02 PM, Paul Mietz Egli<p...@obscure.com> wrote: > Like Andreas, I'm exposing database tables as a virtual resource tree in > Sling. I'm using Dojo's JsonRestStore as a front-end for this resource tree > and have successfully set up ResourceProvider implementations for each table > that will be served through Sling. The problem that I'm facing is that > JsonRestStore uses the Content-Range HTTP header and query params to narrow > the number of records that are returned by the server. I could get that > information from the servlet request, but the getResource(ResourceResolver, > HttpServletRequest, String) method in my custom resource provider is never > called by JcrResourceResolver2.resolve(HttpServletRequest, String). As far > as I can tell, the getResource() method with the servlet request isn't > called anywhere in the Sling codebase. > > Any ideas on how to get headers and parameters from the servlet request into > my ResourceProvider class?
I think for fully virtual resource providers Sling still misses the "ResourceResolverFactory" [1]. That would probably make this use case easier to implement. But anyway my gut feeling tells me that you should not make the Resource depending on request parameters or HTTP headers. These should rather define how the resource should be rendered. In your case the resource would most likely simply the table to be addressed. Limits, offsets, and other "query" parameters would then be handled in a servlet that provides a query rendering of this resource/db table. That would most likely make that servlet and the resource implementation generic for all tables, but you could still have specific overrides for special tables (by using a more specific resource type and a "generic/table" super resource type). In your Resource implementation you could implement adaptTo to elegantly get to the underlying JDBC connection or whatever the raw database access it and use that in your Database query servlet. [1] http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
