While rethinking the hierarchy problem and other things I came to the conclusion, that the best point for validation is when ResourceResolver#commit is called. At this point all changes are known. Validation should be based on resource types and validate a resource - therefore the validation service does not only need to validate new/updated values but also existing values. Especially as soon as you have dependencies between properties. Basing the validation on the transient space elegantly solves this problem. Adding this - maybe as an optional service - into the resource resolver makes it also impossible to bypass validation - the validation is always done regardless whether the changes are done through the post servlet, any other servlet, or some server side code running in the background. For this to work, we only have to build up a list of added and changed resources and then validate these resources, each resource can be adapted to a value map to validate it's properties. For the hierarchy we can add validators which check for the existence of a child node with a specific resource type (or whatever is required).
I think this is the most flexbile way and does validation at the right place. Carsten 2013/7/4 Radu Cotescu <[email protected]> > To sum things up: > a. there's also a need for hierarchical structures validation > b. we shouldn't rely on the ValueMap to provide the properties of child > resources - there's only one ValueMap implementation that provides this, > and only for read operations > > The proposed API currently: > a. does not assume hierarchical structures - they could be defined in the > ValidationModel (by extending the Field concept to also contain children) > b. validates only ValueMaps and, given the recent discussions, should not > assume that the ValueMaps provide the properties of a tree-like structure > c. can be used to validate requests and resources as long as we don't > expect tree-like structures > > However the ValueMap accepted by the validation service could contain > path-like keys if it was obtained by adapting a request to it. > > Depending on what we need in Sling I see two solutions: > 1. extend the current API and implementation to be able to validate > tree-like structures - better suited for validating requests rather than > resources, given that most ValueMap implementations don't provide us with > the children's properties > 2. erase and start over with a new validation framework at the > ResourceResolver level that would handle validation right before the commit > phase - this implies that we actually validate changed resources (credits > to Carsten for this idea) > > Devs, which solution sounds better to you and why? > > Thanks, > Radu > > > On Thu, Jul 4, 2013 at 8:54 AM, Carsten Ziegeler <[email protected] > >wrote: > > > As I wrote, a hierarchy is only supported by a single implementation for > > reading - not for writing, so it doesn't make sense to me to support this > > in validation as this can't be written through the resource api in the > same > > way. The post servlet is splitting paths and creates a resource for each > > part of the path except the last part which is the property on the last > > resource. > > > > Carsten > > > > > > 2013/7/4 Radu Cotescu <[email protected]> > > > > > Hi, > > > > > > Found what Alex was talking about in the > > > org.apache.sling.jcr.resource.JcrPropertyMap class. I'm sorry for my > > > previous answer. The implementation wasn't that obvious at first. > > > > > > What do you think the best approach would be given the hierarchical > > > structures problem and the currently proposed validation API? The > > > ValidationModel could describe the expected tree structure if we change > > the > > > Fields to allow them to have children (in which case, judging from a > JCR > > > perspective, these Fields would actually translate to nodes instead of > > > properties). > > > > > > Thanks, > > > Radu > > > > > > > > > Radu Cotescu | Software Engineer, Tech Blogger, Author > > > Web:radu.cotescu.comEmail:[email protected]:+40 744 406 353 > > > > > > > > > On Wed, Jul 3, 2013 at 10:18 PM, Carsten Ziegeler < > [email protected] > > > >wrote: > > > > > > > 2013/7/3 Alexander Klimetschek <[email protected]> > > > > > > > > > On 03.07.2013, at 17:34, Radu Cotescu <[email protected]> wrote: > > > > > > > > > > > 1. Currently there's no support for hierarchical structures. > > ValueMap > > > > > > doesn't provide this kind of support. > > > > > > > > > > Yes, the jcr property value map implementation supports relative > > paths. > > > > > This should definitely be supported, as you very quickly have a > > nested > > > > > structure with JCR and the sling post servlet. > > > > > > > > > > So field names supporting relative paths should all there is > > required - > > > > > this is in line with the sling post servlet. > > > > > > > > > > > > > > It was a mistake to add support for paths to the jcr value map - note > > > that > > > > the jcr implementation of the modifiable value map does not support > > > setting > > > > a property with a path - same with the whole create and update stuff > in > > > > Sling's resource api. Other resource implementations don't allow > paths > > > for > > > > properties. > > > > If I could turn back the time I wouldn't add path support to the > value > > > map. > > > > It creates several problems implementation wise and blures the > > difference > > > > between a resource and its properties. > > > > For all future things we should have clean approaches. > > > > > > > > There might be resource types which require child resource (types) to > > > exist > > > > - and we need a way to validate this. I think the correct way would > be > > to > > > > have a validator which checks for such a child resource of a type and > > > have > > > > separate validator sets for both, the parent and the child resource. > > > > > > > > Carsten > > > > > > > > > 2. As long as the Field from the ValidationModel specifies a > certain > > > > > > Validator to be used for validating the field's value I don't see > > why > > > > we > > > > > > couldn't have a Validator that checks the data in an external > > system. > > > > The > > > > > > single current constraint of a Validator is that it has to > provide > > a > > > > > > validate method, returning a boolean. The implementation can be > > done > > > > > > however the developer sees fit. > > > > > > > > > > If the Validator is a service/component, then it can easily > reference > > > > > other services. > > > > > > > > > > Cheers, > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > -- > > > > Carsten Ziegeler > > > > [email protected] > > > > > > > > > > > > > > > -- > > Carsten Ziegeler > > [email protected] > > > -- Carsten Ziegeler [email protected]
