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]
