Hi, I don't think the validation API needs the changes from the transient space, but rather the latest "snapshot" and the model according to which the validation should be performed. Therefore we could keep the ValidationModel in place (maybe rename the Field to Property or smth similar) and use the Sling Resource API for traversing the structures.
For request validation we could maintain the current implementation to which we just add the part for resource tree validation. WDYT? Regards, Radu On Mon, Jul 8, 2013 at 5:57 PM, Carsten Ziegeler <[email protected]>wrote: > Of course, validation is a separate service - my idea was that the resolver > could call this (optionally) on commit() - please note we're talking about > the Sling API here, so we deal with a resource resolver and resources - not > with sessions and nodes. > > I'm fine with having the validation as a separate step, which needs to be > called explicitly. But I repeat, validation should keep the resource API in > mind and in general a ValueMap gives you just the properties of a resource > and paths are not working. And also, validation has to be usable without a > request. > And then again, I guess the transient space of the resource resolver is the > best place. > > In order to do proper validation on the transient space, you need to know, > what has been created/updated/deleted. So the validator API needs a way to > give this as an input. > > > Carsten > > > 2013/7/8 Alexander Klimetschek <[email protected]> > > > On 08.07.2013, at 14:42, Radu Cotescu <[email protected]> wrote: > > > > > 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) > > > > I think Validation should be its own service that you can call for > > resource /foo explicitly, an entire subtree or based on transient changes > > in JCR. This separates concerns properly. > > > > Then the question is in which places it gets called. Sling POST servlet > is > > the main use case. > > > > But -1 on building it into ResourceResolver.save() for now - this is a > > huge change we should not do before we don't have experience and feel > > comfortable. I am not sure if we should ever do it... because it bakes in > > validation into the infrastructure layer, which is just another schema > and > > as we know with JCR, less schema is better for evolution. For example, > > nobody is using extended node types with value constraints in JCR, and in > > Sling we always point out the great flexibility of the sling:resourceType > > property. There are good reasons for it. > > > > So IMO applications should be in control over validation, by explicitly > > calling that validation service before they do a session.save(). > > > > And regarding the mentioned imports: especially for imports, you usually > > want to switch off validation to make things faster or avoid little > issues > > (that you can fix/migrate later) break the entire import. > > > > If we learn more how those validations are used and once the framework is > > stable and performance-proven, we can start again to think about hooking > > that automatically in for everthing. > > > > Just my 2 cents, > > Alex > > > > > > > -- > Carsten Ziegeler > [email protected] >
