Justin, Thanks, that is exactly what I was looking for. Is there any documentation on these annotations? The best I've been able to find is: http://blogs.adobe.com/aaa/2012/09/cq-tips-and-tricks-1-how-to-define-a-slingservlet-cq5-5-5-6.html
Would there be any interest in creating some documentation for the annotations? I've also seen another set for creating adapters. Is there some sort of list of high priority items which should be documented? -Dan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Justin Edelson Sent: Tuesday, November 27, 2012 3:05 PM To: [email protected] Subject: Re: Adding dependencies Dan- Have you looked at the @SlingServlet annotation? It does something almost identical to your second code example. Justin On Tue, Nov 27, 2012 at 2:40 PM, Dan Klco <[email protected]>wrote: > > > -----Original Message----- > From: Alexander Klimetschek [mailto:[email protected]] > Sent: Friday, November 16, 2012 5:28 AM > To: [email protected] > Subject: Re: Adding dependencies > > On 14.11.2012, at 19:06, Dan Klco <[email protected]> wrote: > > > > create a framework in Sling allow defining resource based servlets > > > via > annotating methods > > > That would break Sling's RESTful mantra "addresses resources, not > scripts". Servlets are scripts and do not define > resources - this is > done through the resource API as the first step in request handling, > before the servlet is > > selected based on the resource type. > > I think I may have not been clear. I am no proposing addressing > scripts, but just simplifying the process of creating servlets. So > you'd have a set of annotations which would be more specific to > creating servlets than the current general-purpose annotations. > > Ideally, it would be very neat to see annotations which could be used > on methods within a class similar to how you can do so in Spring: > > @Component(label = "Very Important Servlet", name = > "com.me.SomeServlet") @Service(value = { Servlet.class }) > @Properties({ > @Property(name = "service.vendor", value = "My Company"), > @Property(name = "service.description", value = > "Servlet for serving resources") }) public class SomeServlet { > > @RequestMapping(resourceType = "app/components/type", > extension="json", method = RequestMethod.POST) > public void postData(HttpServletRequest request, > HttpServletResponse response) { > > } > @RequestMapping(resourceType = " app/components/type ", > extension="json", method = RequestMethod.GET) > public void getData(HttpServletRequest request, > HttpServletResponse response) { > > } > @RequestMapping(resourcePath="/bin/servlet") > public void getAllData(HttpServletRequest request, > HttpServletResponse response) { > > } > } > > But honestly, even being able to have some more servlet specific > annotations which would be error checked would be a help. Something > more > like: > > @Component(label = "Very Important Servlet", name = > "com.me.SomeServlet") @Servlet(resourceType = "app/components/type", > extension="json", method = > RequestMethod.POST) > @Properties({ > @Property(name = "service.vendor", value = "My Company"), > @Property(name = "service.description", value = > "Servlet for serving resources") }) public class SomeServlet extends > SlingAllMethodsServlet { > public void doGet(HttpServletRequest request, > HttpServletResponse > response) { > > } > public void doPost(HttpServletRequest request, > HttpServletResponse > response) { > > } > } > > > > > and add support serializing responses > > > What do you think is missing here? > > > > and loading parameters from the request. > > > Same question here. You can have a service or helper that you use > > from > within your servlets to read parameters > > the way you want. To generalize, you could have an abstract base > > servlet > that does that for you. > > > In general, it's not a good idea when web frameworks try to > > completely > abstract away the protocol (HTTP & REST-> style). > > Fair enough on both points, I do love the convenience, but yeah it > does come with a cost in complexity. > > > Cheers, > > Alex > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.2793 / Virus Database: 2629/5896 - Release Date: > 11/15/12 > > ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2793 / Virus Database: 2629/5922 - Release Date: 11/27/12
