On Mon, Sep 19, 2011 at 7:13 PM, Carsten Ziegeler <[email protected]> wrote:
> Thanks for sharing your ideas Markus - this is really appreciated and
> I encourage everyone else to do the same.
> This is what makes up a real community, getting different input,
> discussing ideas and finally implementing them :)
>
> I would like to comment on some of these ideas in combination:
>> 1) Intermediate render format
>> 2) Security
>> - Validation
>> - Property filters
>
> I think this could be done with my descriptive rendering idea I
> briefly mentioned in my talk. I'm currently about to write a prototype
> but I'm still a little bit undecided what's the best way to tackle
> this.
>
> So I could imagine having some descriptor file for a resource type,
> this file lists the properties to be rendered, maybe their types (if
> they can't be derived) and validation rules.
> This could be used for creating html, json, xml etc. for viewing, but
> also html for editing and on a post the input could be validated.
We have something similar implemented in our project. However it is
not used for rendering but just for enhancement/validation of input.
We call it a model for a node that is stored in the repository and
used by a postprocessor to validate against.
It basically looks like that:
{
"rb:name" : "individual",
"jcr:primaryType" : "rb:Model",
"title" : {
"jcr:primaryType" : "rb:Property",
"rb:name" : "rb:title"
},
"firstname" : {
"jcr:primaryType" : "rb:Property",
"rb:name" : "rb:firstName",
"reqRule" : {
"jcr:primaryType" : "rb:ValidationRule",
"rb:rule" : "required",
"rb:errorMessage" : "Please provide the first name!"
}
},....
That works out fine so far.
I always thought about the rendering as being kind of a "descriptive"
script that can be used as a default for a resource type and can also
be overwritten by more path specific scripts.
However fixing it for a resourcetype might also work.
I guess the format depends mainly on the functionality that should be
provided. My ideas on that:
- include/exclude properties
- transform property values. E.g. output escaping. This should
probably be backed by a extension point that accepts custom filters.
- map property names. Not sure if this is really required but I think
it could be handy for the output to map prop names like
longprefix:internalmaxageprop -> age in the output.
- include children. I would like to see the default include mechanism
for the descriptors as well. That allows to add children definition
and get rid of the potentially dangerous infinity or levelx selectors.
> The current json rendering implementation for example is based on the
> ValueMap. One idea would be to extend the json get servlet to look for
> such a descriptor file for the given resource type and then use this
> for json rendering. If none is found, the whole map is rendered. The
> same with xml output etc.
I see two layers here. The one is the creation of the intermediate
format (valuemap) that is either be done by the get servlet with the
help of the descriptor file,
or the manually by the developer in a servlet (e.g. if a search or
more processing is involved).
This intermediate format is then rendered in either json/xml or whatever.
As a developer I can benefit in my custom code from the abilities of
the framework to render a response differently.
> For html we need some new stuff
> The same for the post servlet, if it nows the resource type, it can
> look for the descriptor file and validate the input.
>
> This sounds easy to be done, though we would have to come up with a
> clever format.
>
> Regards
> Carsten
>
> --
> Carsten Ziegeler
> [email protected]
>
