On Tue, Jul 22, 2008 at 1:31 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> ...Following the Lars cheatsheet, I would have expected to have the step
> 2 (content resolution) being able to handle queries, and then having
> step 3 deriving a nice ressource type (employee/list for instance)
> followed then by normal rendering steps....
That sounds interesting, but given the following structure, how do you
decide which resource should map to a query and which should not?
employee
+ bob
+ firstname
+ lastname
Is employee.html meant to be a query? What about employee/bob.html?
I'm not sure if there is a general rule that can be used for that.
Now, in your case, if you set sling:resourceType=employee/list on the
employee node, you can map that to a script or servlet that executes a
query, something like /employee.html?name=bob*&offset=2...
What might be interesting is to create a generic servlet for such use
cases, and map that to a sling/query resource type for example. Query
result renderers for different extensions could then be created, and
the existing json query servlet would be one of those.
-Bertrand
