On 02.01.11 21:51, "Markus Joschko" <markus.josc...@gmail.com> wrote: >1) It is more a finding then a question: I miss the C in MVC. I read >that a controller is not required when using SLING as the selection of >scripts happens content driven.
The nice thing about Sling is that you don't have to write the controller (or at least most of it), especially no URL-wiring. > However I have seen code on top of some jsps that is typical for a >controller: E.g. checking whether a user is logged in (or has the >appropriate role) and redirecting if that's not the case. Authentication is so generic and required by most web apps that it is generally handled in Sling. Also, with the JCR repository the general concept is to have authentication and authorization as part of the repository infrastructure, so when Sling provides a JCR session for each request, it must log in with a given user. The details of how certain auth mechanisms works (such as http basic, form login, OpenID, etc.) can be plugged in as authentication handlers. For more see http://sling.apache.org/site/authentication.html > I would like to see that code in a controller, long before my HTML >view template is about to render and not mixed into my view. Is there >any concept in SLING to provide a better separation? > Speaking about separation: I have seen a lot of code on top of the >esp and jsps files. That's fine for samples but for the last years I >always tried to avoid that kind of mixture in my projects. > Is there a way to provide all that code in java services which can >make use of DI and just provide calculated values to the HTML view? >Something I'd do normally in the controller? > (I am aware of JSPs taglibs but, hm, I don't like the programming >model. Any alternatives?) I think this all is an aspect of maximizing code-reuse and code readability in the rendition (view) layer. The access to the model comes with the JCR API (using Node as your flexible domain object) and/or Resource API in Sling (just a simpler API abstraction on top). This can already lead to short JSPs (e.g. just printing the properties of a node). For extracting more complex code, I would use helper classes, wrapper objects (wrapping the JCR or Resource API) or yes, even write a custom tag lib (JSP specific, though, and probably only for very common things). I think it is wrong that those things are placed inside the (web application) controller - they are either part of the model (here: mainly JCR) or simply helpers in the rendering logic. But this might also be a philosophical question ;-) I know that in the Spring MVC world people write a lot of domain objects and restrict people to use only what these provide in the JSPs. With Sling and JCR however, the underlying data model is much more flexible because it is unstructured and thus allows for faster development cycles and less layers of code to maintain. Also there is this rule "no JSP snippets", which IMHO is totally arbitrary and comes from the (wrong) notion, that only web designers work on the JSPs and they should not be messing with the code... In many cases you have a very rendering-specific logic and why not use all what the JSP technology provides in the first place? >2) How is input validation done? The postservlet allows the client to >post nearly everything in every structure to the repository. I am sure >there are ways to restrict that ability. > I guess part of this is to define ACLs on the repository and to >not use nt:unstructured as nodetype but a more precise one (see next >question). But how would I do more low level validation like checking >that a number is in a certain range, > a string matches a given regex or a given e-mailadress is not >already existent in the repository? Sling Post processors are a way to combine that with the post servlet. They are run after the Sling POST operation has been executed on the current JCR session, but before it has been saved: http://sling.apache.org/apidocs/sling5/org/apache/sling/servlets/post/Sling PostProcessor.html Or use a custom filter that runs before the Sling POST servlet. Otherwise, in most cases the validation can (or must also) already happen on the UI side. This in combination with unstructured gives you the best flexibility, while providing a good experience for users. Don't be afraid of using nt:unstructured, for most cases you don't want hard constrains in the repository! If you start using strongly constrained node types = fixed schema, you loose a lot on the niceness of JCR. In this regard, also have a look at David's model: http://wiki.apache.org/jackrabbit/DavidsModel >3) How do I interact with the underlying jackrabbit repository? In the >slingbucks sample I have seen some json files to setup a basic >structure. Can I use that mechanism to also setup custom node types >and define ACLs? Or how would I do that? http://wiki.apache.org/jackrabbit/JcrLinks#Open_Source_Tools_and_Libraries And/or use the JCR API for application-specific administrative tasks. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
