+1. I think this is a possibly very common use case. BR,
Juanjo. On Wed, Nov 26, 2008 at 10:39 PM, Felix Meschberger <[EMAIL PROTECTED]>wrote: > Hi all, > > After the big reorganization of servlet resolution in April of this year > and some more experiences with using Sling, I propose the extension of > our servlet/script resolution process. > > Actually it is a single change only: Consider request selectors for all > requests. Currently request selectors are only considered for GET or > HEAD requests and ignored for any other requests. > > Over time use cases arose, which would be easier implementable if we > would support using selectors to influence servlet/script resolution for > all methods. > > Example: Say you are building an application providing a configurable > input form system. The most important configuration would be the action > upon form submission. Submitted forms are sent back to the resource > providing the form. The actual action would be encoded as a request > selector: > > For example we would like to be able to send a form based mail message. > We would have script "/apps/myapp/form/mail/POST.esp", which handles the > "myapp/form" resource type and is called using the "mail" selector. The > form itself together with some nice GUI surroundings etc. would be > stored in the /content/feedback resource. > > Now updating the /content/feedback resource should be handled by Sling's > default POST servlet. Thus POSTing to /content/feedback would update the > content. Submitting the form would POST to /content/feedback.mail.html > and should thus not store any form input but trigger the mail/POST.esp > script. > > I have prepared a prototype implementation of this new mechanism in my > sandbox at [1]. > > A nice side effect of this prototype is, that it is much simpler codewise. > > WDYT? > > Regards > Felix > > [1] > > http://svn.apache.org/repos/asf/incubator/sling/whiteboard/fmeschbe/servlet_resolver >
