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]
