Hi Radu, regarding the first part of your mail: I see validation as generic check which allows to read (and explicitly not modify, I wouldn't mess with autofixing) data from anywhere in the system (inkluding resourcetree as well as OSGi Services) and return either true or false and optionally some metadata like what caused it to fail (and probably some resoltionhints).
Best regards Dominik On Mon, Jul 8, 2013 at 2:42 PM, Radu Cotescu <r...@apache.org> wrote: > Hi, > > Apart from Carsten nobody else provided me with an answer to my question, > which in the end boils down to what kind of validation is needed in Sling: > > 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) > > > > Devs, which solution sounds better to you and why? > > > > What would be the minimum requirements for adding some validation bundles > (api + impl) in contrib? > > Thanks, > Radu > > > On Mon, Jul 8, 2013 at 3:24 PM, Dominik Süß <dominik.su...@gmail.com> > wrote: > > > +1 - validation can also be necessary on dataimport through services, to > > have a default integration of this service in the default Post Handler is > > IMHO a mandatory but not stricktly bound extension to this service. > > > > Dominik > > > > > > On Mon, Jul 8, 2013 at 12:19 PM, Carsten Ziegeler <cziege...@apache.org > > >wrote: > > > > > Even if there is processing overhead - and I think this is really > minimal > > > compared to persisting the data - storing unvalidated and therefore > maybe > > > wrong data might haver a much higher impact on the application. > > > > > > And I totally agree, this needs to be configurable (controllable) - but > > > limiting this to the post servlet is way too restrictive. > > > > > > Carsten > > > > > > > > > 2013/7/8 Alexander Klimetschek <aklim...@adobe.com> > > > > > > > On 04.07.2013, at 14:56, Carsten Ziegeler <cziege...@apache.org> > > wrote: > > > > > > > > > Adding this - maybe as an optional service - into the resource > > resolver > > > > > makes it also impossible to bypass validation - the validation is > > > always > > > > > done regardless whether the changes are done through the post > > servlet, > > > > any > > > > > other servlet, or some server side code running in the background. > > > > > > > > We should be careful with the imposed new processing overhead of > this. > > > > There needs to be control over it, and IMO an active whitelisting for > > > which > > > > validators (i.e. resource types) this would happen and when. And the > > > > simplest way to do that is to have custom application code call the > > > > validation service (one-liner) themselves and do it automatically > only > > in > > > > the post servlet (but also with an option to enable/disable > individual > > > > validators). > > > > > > > > Cheers, > > > > Alex > > > > > > > > > > > > > > > -- > > > Carsten Ziegeler > > > cziege...@apache.org > > > > > >
