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
