Looks basically reasonable, but could be made more REST-compliant::

On Tue, Dec 7, 2010 at 8:14 AM, Unmesh Joshi <[email protected]> wrote:
> Hi,
>
> I tried following example by writing custom resource resolvers and
> servlets. Can someone on the list please verify if this fits 'good
> programming practices' for sling?
>
> Use Case: User Account Summary
>
> 1. User makes a GET request to /account-entry
>      a) I have a resource resolver that resolves /account-entry to a
> resource (An empty resource at this point)
>      b) Resource resolver has resource type as /apps/myapp/account-entry.jsp

You might want to specify the resource type relatively - just use
myapp/account-entry. This gives more flexibility when handling
different request methods or response formats, for example. See
http://sling.apache.org/site/servlets.html

>      c) account-entry.jsp is presented to the user
>
> 2. User enters account number and submits the form. This makes a POST
> request to /account-verify
>     a) I have a Servlet resource registered for path /account-verify
> for handling POST.

A more REST-like approach would be to post to /account-entry/*. You
would then use a SlingPostOperation or SlingPostProcessor to do the
validation and/or persisting.

>     b) Servlet makes a backend web service call to verify the account
>     c) If account is valid, it redirects (by calling
> httpResponse.sendRedirect()) to /account-summary

... or to /account-entry/some-newly-created-identifier.html, which
displays the state of the created account.

> 3.  A GET request is made to /account-summary

... account-entry/some-newly-created-identifier

>    a) I have a resource resolver which resolves /account-summary to resource
>    b) This resource resolver makes a back end web service call to get
> account details
>    c) This resource resolver has resource type as
> /apps/myapp/account-summary.jsp
>    d) account-summary.jsp is presented to the user.

So to wrap it up, instead of mapping your servlets to absolute paths,
and have the end-user request them, let the end-user request the
account resource itself.

-- 
Vidar S. Ramdal <[email protected]> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 22 00 84 76
Quando omni flunkus moritatus!

Reply via email to