...what about using POST.jsp for validations, implementing custom behavior etc.
in POST.jsp * add / remove / modify / handle post parameters * call the default POST servlet to do the actually persistence * handle any errors --- The reason why it doesn't work at the moment is that: - post parameters are not mutable - it is hard to call the default implementation (perhaps I just don't know how) - exceptions coming from the POST servlet may not be detailed enough in order to provide error handling on granularity needed I think approach could be very useful for intercepting other requests as well,without need to write custom filters. Ondrej On 26 Jun 2013, at 12:35, Dominik Süß <[email protected]> wrote: > Hi everyone, > > within the last weeks I spent some time on a project that is heavily > relying on data being submitted by users of the system and setting up > complex structures, users, groups and ACLs based on the operations > performed by a user. I reallized that a lot of those things could be done > by utilizing the SlingPostServlet and extending it by custom Postprocessors > and custom operations. This worked out well but I realized some things that > I'm not so happy with and would like to start off a discussion how the > handling of Posts, and therefore the interactive part of Sling could be > improved. > > Here the points that I think are "discussabble": > a) (non-Brainer) Postoperations and Postprocessors are rarely covered by > documentation (Postprocessors are marked as TBD) this gives the impression > of not being ready for productive usage so the gap should be closed > b) Postoperations and Postprocessors are always defined and called global > so it is up to the developer to check and skip processing (Blacklisting > approach) which is errorprone if this manual check is not restrictive > enough (can lead to subtle regressions in completely different areas of the > app) - I'd propose to have a declarative approach that is a > whitelistapproach based on path and propably even by resourceType (here > comes the clash between posted resourceType and potentially already > existing resourceType > c) Sometimes data submitted should just be used as parameters for > postprocessors or operations and not persisted. Using the dot-slash > prefixing does give such options, but since the "./" notation acts as kind > of a magic trigger of behaviour I'd prefer to have a way to annotate such > fields (like name@ignore or @noPersistance) > > All in all the web is moving in a direction where almost no page is > delivered with options to interact with the the webpage - so Sling should > try to give developers the tools to do this wireing without having the dev > to write boilerplatecode for those checks over and over again and enabling > them to implement complete interactive userstories up to a certain point of > complexity in a standardized way. > > WDYT? > > Best regards > Dominik
