Hi, I have long thought SlingPostOperations should be registered against the resource type in the same way SlingServlets are registered against a resource type.
If the operation requested is not found against the resource type then the parent resource types are tried until the global scope. That will give operations like move becoming meaningless in anything other than the global context. I dont think it would that hard to do, Sling already has a resource type hierarchy and extension mechanism. Best Regards Ian On 26 June 2013 20:35, Dominik Süß <dominik.su...@gmail.com> 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 >
