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] >
