On 03.01.11 16:25, "Markus Joschko" <[email protected]> wrote:
>Yet I found that code in the sample crx bookstore application
>http://code.google.com/p/crxzon/source/browse/trunk/apps/bookstore/compone
>nts/checkout/checkout.jsp?r=11
That should be possible otherwise, using the plain sling auth mechanisms.
However, I didn't write this sample, so I don't know the reasoning behind
this and that.
>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?
A clean Sling approach would model the onlineshop using (JCR) resources in
a restful way. For the redirect, you could have a plain Java servlet (or
jsp) for that POST-address-resource calling into some service providing
the information for the given address and then doing an internal (sling
include/forward) or external (http) redirect to the proper payment form.
>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.
But you should still strive for a simple architecture for a simple
calculation ;-)
These "other systems" would probably be best implemented as (osgi scr)
services.
>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.
Yes, I think for most plain logic-only "scripts" you'd use a plain java
servlet, calling into those services. If they need to return some html as
well, a JSP is fine for that as well (just some service calls and then the
rendering part).
Using the simple sling include mechanism, it is also easy to build a
component system, where you might have a top-level java servlet handling
the resource type (controller-like) and then including sub-paths or using
different resource types which do jsp based rendering.
>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.
Ok, granted. Developers should not try to write complex jsps and leave
back a mess. But preventing any use of jsp snippets is also a huge
self-constraint.
>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.
You would use ACL of course that prevent people from writing into
locations they are not allowed to. The execution of scripts (setting a
resource type and uploading a script) is restricted/able to certain
folders.
>So input validation is a must.
Yes, but not for everything (personal opinion). Most cases fall into the
category of "it is possible for someone to tweak the HTTP request to write
his zip code as a string instead of a number". And JCRs implicit value
type conversion helps here more or less automatically.
If you have the need, you can write your own POST handler or a Sling post
processor, as mentioned.
> 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.
With node types, you can restrict what properties are allowed, what type
they are and for string properties you can also have value constraints
(regexps).
>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.
What if it doesn't have this title? For one, it is impossible to guarantee
that from the storage layer (not even with RDBMS, things break) and also
what if a future version doesn't require a title? The application knows
what to do when a title is there or not.
It is generally good to follow the robustness principle wrt data: "... be
liberal in what you accept." The above "duck-typing", which is simple with
JCR, does exactly that. This allows it to change your content model much
easier in the future, when different requirements arise.
>I am more in favor of having strong types and less code then more code
>and loose types.
This might be good for the short-term (less code to write and to think
about), but for most applications this is a hurdle for the long term. A
good read regarding this is
http://dev.day.com/content/ddc/blog/2009/01/jcrrdbmsreport.html
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
