>>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).
How do you get hold of the services in the JSP? Sorry I am not very
familiar with OSGI.
Is there a registry that can be used to get hold of a service?
Can services be injected into a taglib?
> 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.
Is there an example somewhere on how to do that? I would be interested.
>>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.
Mhm, correct me if I am wrong but nt:unstructured allows the user to
define own properties on the fly as well, or?
I can name at least one security consultant who would freak out if
people can store content "uncontrolled" in the repository.
>
>> 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).
OK, then the message is: If I want to have support for input
validation it makes sense to have custom node types (which might
inherit from nt:unstructured).
>
>>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.
That's where I see the types. They ensure that mandatory properties
are ... mandatory.
If in the future certain properties become optional it'll still be
possible to introduce these checks.
>
> 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
Excellenct read. Very helpful.
But it won't cure me from wanting to define strong types for
everything that I already know about my data model.
I think in most applications it's not the user who defines the content
because he is dependent on the developer
to provide him with a UI. And if the developer is adding a field to
the UI he can adopt the datamodel/nodetype as well.
And there I'd like to rely on IDE refactoring support. Another reason
to keep code away from JSPs.
Also strong types can be used as interface definition. Imagine a
second and a third application that use the JCR through the sling REST
services.
It would certainly ease the communication if the developers of these
apps know which properties to expect in a node.
Anyway, JCR gives the freedom to choose on approach or the other.
Thanks so far,
Markus
