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