>>    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

Yet I found that code in the sample crx bookstore application
http://code.google.com/p/crxzon/source/browse/trunk/apps/bookstore/components/checkout/checkout.jsp?r=11

And authentication is not the only reason for "controling" the view. I
guess everything that's not a static resource lookup but a
dynamic/runtime decision
benefits from having a controller. E.g. in an onlineshop where a user
enters his address the software might check
the address and redirect the user to different payment flows depending
on the location.
Can this be cleanly expressed in sling?

>
>>    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 ;-)

There are no such things like "simple helpers" ;-)
E.g. in the Slingbucks example the price is calculated in an esp. Fine
for that example
but in a real world app you would probably have to ask other systems
for sales conditions, make a db lookup
to check blacklists etc and soon the calculation is no longer simple.
You want to have access to your ecosystem, probably services and
dependency injection to ease the wiring.
That's nothing a simple static helper or a tag library has to offer.
It's much easier to do all that in a java based controller.

>
> 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?

Mhm, because it's too easy to produce a hard to test maintenance nightmare?
Unfortunately I had to develop in a rather large site where JSPs
heavily mixed markup with code and had
multi level snippet includes. While the system originally was
developed in a very short time frame,
the maintenance was extremely painful and expensive.

>
>>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
>

Thanks for the link.

Mhm, yes validation happens on the UI side. But also on the
serverside. Otherwise it would be far to easy to circumvent
the validation by modifying the HTTP requests. Combined with a
nt:unstructured node the repository doors are then open for attackers
to put malicious content into.

So input validation is a must. And that's where I would hope to get
some help from my model. If the model already knows that a property is
not a string but a number it can help me to check the input.
And maybe it's possible to add validation rules to the nodetype so
input validation is done declaratively?
That's not possible with an unstructured nodetype.

Mhm, and I am not sure if I really see the advantages of
nt:unstructured. The model exists either in code (duck typing) or in
the repository.
If it is in code you need to validate the data and that requires code
like that one from the slingbucks options.esp

   // If field has a jcr:title property, we can use it.
 31     if(f["jcr:title"]) {
    ...

If I could rely on the fact that the currentNode has a mandatory title
attribute, I could spare this check.

I am more in favor of having strong types and less code then more code
and loose types.


>>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.

I found the information here: http://sling.apache.org/site/content-loading.html

Thanks,
 Markus

Reply via email to