Thanks Felix,

What you have suggested sounds ideal and I think that will do exactly what I want. I wont be able to do this right at the moment due to pressing deadlines, but will let you know once I get a chance to come back to this.

Cheers
Bryce

Felix Meschberger wrote:
Hi Bryce,

Sorry for chiming in late, I was distracted by other work ...

Yes, your problem might well be solved by a combination a ResourceProvider and a registered Servlet.

The ResourceProvider would make the RESTlet provides resources visible in Sling's virtual resource tree. So if you map /users to in RESTlet, your ResourceProvider would provide a Resource backed by Hibernate representing the collection of users. This collection would have a specific resource type, say "restlet".

The Servlet you provide is registered for the resource types provided by the ResourceProvider (use the sling.servlet.resourceTypes service property) and for "all" methods (set sling.servlet.methods to the special value "*"). The Servlet's service() method would simply forward to the RESTlet servlet.

Now all requests to the resources provided by the RESTlet ResourceProvider having no request extension (e.g. /users or /users/123) would be handled by your Servlet forwarding to RESTlet.

In addtion - for presentation - you might create servlets or scripts for the RESTlet resource types for specific extensions. E.g. you create a script /apps/restlet/html.jsp to handle requests to /users.html

Does this help ?

Regards
Felix

Bryce Ewing schrieb:
Ok, I think I have managed to totally confuse you, so will try to come up with a concrete example.

Restlet User example:
   POST {
       firstName: "First",
       lastName: "Last",
       address: {
         line1: "Line 1",
         line2: "Line 2",
         city: "City", ... etc.
      }
   }
to /users creates /users/123

This will now return the same json representation when a GET is performed on the /users/123 uri (PUT against this uri will update the user, and DELETE will remove them). All of this is being performed through the restlet part of the system.

Then say across the fence on the portal part of the system (which is being delivered by sling) we have a uri /addressbook/users/123.html that will display an html representation of the user along with their address, and this will be rendered into the portal template etc. by a script say /apps/addressbook/html.ftl

I think that this part might be able to be accomplished with ResourceProvider, though slightly confused how this works, but I am not sure if I would also be able to do a PUT against /addressbook/users/123 in order to update the user entry or whether I would have to go straight to the /users/123 uri to do this?

Bertrand Delacretaz wrote:
On Wed, Jul 2, 2008 at 11:41 AM, Bryce Ewing <[EMAIL PROTECTED]> wrote:
...What I have done at present is to move all the restlet based api under /api (managed by a restlet servlet). But I would also like to be able to access
the data from within Sling and use the same rendering methods etc....

That's where I'm not sure what you mean, can you give an example of an
URL that would be processed by Sling, and what you expect it to do?
And what would differentiate that URL from one that's processed by
Restlet?

-Bertrand

Reply via email to