Right, you don't need the changes directly - however you need to know which resource(s) to validate - and this can be calculated based on the changes
Carsten 2013/7/8 Radu Cotescu <[email protected]> > 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] > > > -- Carsten Ziegeler [email protected]
