On 05.01.11 13:02, "Markus Joschko" <[email protected]> wrote:
>That's for the input side. I am also interested in the output
>verification.
>If I can't rely on my data having a certain format, I need to check
>every property before accessing it.
I don't understand: if you do validate on input and/or use node types to
enforce a certain schema in your repository, why do you want to validate
it on output again?
If you have a model with more "relaxed" constraints, I agree, you want to
have some basic validation of the content. But I think this is the domain
of the application. A different application/template etc. might have a
slightly different view on the data. To do that, wrappers around Node or
Resource are what is IMHO typically used. You still get access to the
unstructured node, but you also can provide more complex, validating
getter-methods to use in your JSP templates.
And as I said, it is easy with JCR to for example read a long from a
property accidentally stored as string (see [1] and [2]).
>I can do it in my view/template/script as it is done in the
>options.esp from slingbucks
> // If field has a jcr:title property, we can use it.
> if(f["jcr:title"]) { ...
>
>or I check this before I pass the node/type/object to the
>view/template to render it.
>I'd prefer the later one to keep the template clean. Can this check be
>done in a filter?
For output, a servlet filter (we are talking about plain standard javax
servlet filters here!) would need to parse the html/response format
created by your JSPs, which is probably a bit too complex ;-)
>I am not talking about checking just a single property but instead
>verifying that the data that I load from the repository is
>representing
>the type that I expect:
>
>title,text,email = blog comment object that I can render in my view
>email, picture = something is wrong here. My view can't handle this
>one -> error page
In Sling, you have the sling:resourceType that defines all the rendering.
It is a bit like a more flexible node type. Sling will resolve the right
JSP for a given resource type, so inside that JSP you can expect a certain
structure, if you otherwise ensure that these are properly created.
But in most cases the flexibility I was talking about is about adding new
properties (in future versions or for other apps), without having to
change your schema. This won't affect existing renderers (e.g. a JSP) at
all, if they just access the properties they expect and know.
Finally, from a general standpoint, it is a good practice to show as much
as possible instead of throwing an error at the user. So in your example
above you could at least show the email and have some default values for
the missing title and text, for example.
[1]
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#PropertyTypeConver
sion
[2] http://www.day.com/specs/jcr/1.0/6.2.6_Property_Type_Conversion.html
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
