Hi, ok, I suggest we could start by defining a java api for the model, We can then experiment a little bit with it and see what works and what not.
Regards Carsten 2011/9/20 Markus Joschko <[email protected]>: > 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] >> > -- Carsten Ziegeler [email protected]
