Re: Sling Posthandling - thougts about the current behavior
...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üß 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
Re: Sling Posthandling - thougts about the current behavior
Hi Alex, why do you think registering logic by path is bad. Especially if I look at potential for multitenantsupport it would be great to be able to register postbehavior that is tenantspecific. And the tenantsupport of Sling is completely based on paths. Regarding usage of Servlet Filters as pipelline I personally think this could probably get a bit intransparent for develpers. As previously mentioned the various phases should/would give the option to have a contract about what can be done during that phase. A filterbased handling just would give the option to control order of execution, but any filter could break this transactional contract. The injection of such a pipeline without the need to touch the existing servlet could be done via a filter, but I think it would make sense to optimize the current implementation when introducing such a mechanism. Just my 2 cents Dominik On Tue, Jul 2, 2013 at 8:38 PM, Alexander Klimetschek aklim...@adobe.comwrote: Ack on the overall goal. The way I see it, it boils down to having the sling post servlet (or more specifically that new POST-pipeline) not just one special servlet out of many, but an integral part of Sling. Registering operations, post processors or whatever we need by resource type sounds good. By path not so much, don't know. IMHO, the rt would be taken from the addressed resource (what the URL addresses, to be 1:1 with how GET servlet resolution works; not any resources that additional request parameters might address) and if not present (creating a new resource) from the sling:resourceType param. It would actually be nice if those operations or postprocessor could become servlets or servlet filters again. They could get the necessary state passed via a request attribute for example + a utility to fetch them. And thinking about it, filters are actually the right thing, they are designed for pipelines. I am not sure if adding a :selector parameter as proposed by Justin (SLING-2936) is a good idea - maybe the integration with this new pipeline is the better long-term approach. You'd register by resource type + http method + :operation. Having both :operation and :selector (in the combined overall picture) seems like duplication. But it's difficult. It was mentioned that using selectors in the URL for POST requests, such as POST /content/page.createChild.html, is not RESTful. Is that really the case? As long as the server provides the URL instead of the client building it himself, such as path + .createChild.html as it happens way too much, and you use the right HTTP methods for changing/deleting content, nothing here would be unRESTful afaics. It would only look nicer if you put all the POST related information into the request parameters instead of into the URL. But then it's the old action=create topic again, which should be covered very well with the default features of the Sling post servlet already, which only requires you to add custom code (actions) for very specific things. This is even less once we have a validation framework in place (also resource type based), where Radu did a lot of work already! Cheers, Alex On 02.07.2013, at 15:26, Dominik Süß dominik.su...@gmail.com wrote: Well, if locking is just about permission I do agree with ACLs being the right solution (the permission set on the node itself might be sufficient for that case) - if it is about businessconstraints that need to be fullfilled an ACL cannot solve this requirement[0]. This is why validation and so on should be performed first, I would think of a pipeline having a contract on each phase what can be done and what cannot be done, while a first phase might not write any data (even as transient changes) the next phase might be perform (transient) change, then the postoperations would be performed in a transient followed by another phase that might perform transient changes and/or stop the processing, followed by a last phase that is called after the resourceResolve has performed a commit(). This is purely about giving developers a contract on what they can and cannot do (and therefore what they can expect 3rd party code to do) at a specific point in this pipeline. [0] a businessconstraint to control sepecific operations by permissions could be solved by a shadowstructure like proposed by Bertrand. -- Dominik On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz bdelacre...@apache.orgwrote: On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß dominik.su...@gmail.com wrote: Facing some questions about how to prevent the SlingPostServlet to be able to perform a change I had a closer look at the current implementation and it looks like there is currently no secure way of doing that beside locking the target on persistancelevel (alias setting ACLs)... ...which looks to me like the right way of locking things. But maybe for the post servlet we need a parallel
Re: Sling Posthandling - thougts about the current behavior
Hi, On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß dominik.su...@gmail.com wrote: ...why do you think registering logic by path is bad. Especially if I look at potential for multitenantsupport it would be great to be able to register postbehavior that is tenantspecific. And the tenantsupport of Sling is completely based on paths In general we want people to get away from the notion that paths drive your app, it should be resource types that do. Also, the problem with paths is that they are usually hidden in code, whereas resource types are transparently exposed in the content. For the POST handling, we could very well take the resource type of the parent/ancestors into account, instead of relying on paths. -Bertrand
Re: Sling Posthandling - thougts about the current behavior
Hi Bertrand, while I agree that paths should not drive the app they might build a scope for the logic, since the content is organized in a tree structure and not in by it's resourceType hierarchy, Therefore you often do have pathspecific operations (just think of workflows and workflowlaunchers in CQ). Or to come up with another scenario. Changing resourceTypes depending on the location of the same data on the other hand would be redundant information. So - the main Driver should be the resourceType is what is defining the behavior of a component while the contentpath in my eyes could act as restricting criteria. WDYT? On Wed, Jul 3, 2013 at 1:22 PM, Bertrand Delacretaz bdelacre...@apache.orgwrote: Hi, On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß dominik.su...@gmail.com wrote: ...why do you think registering logic by path is bad. Especially if I look at potential for multitenantsupport it would be great to be able to register postbehavior that is tenantspecific. And the tenantsupport of Sling is completely based on paths In general we want people to get away from the notion that paths drive your app, it should be resource types that do. Also, the problem with paths is that they are usually hidden in code, whereas resource types are transparently exposed in the content. For the POST handling, we could very well take the resource type of the parent/ancestors into account, instead of relying on paths. -Bertrand
Re: Sling Posthandling - thougts about the current behavior
Hi Dominik, Wouldn't a ResourceDecorator be a better solution in those case? I.e. if a resource is of type app/foo and is under /content/bar, decorate the resource to app/bar ? The fact that you can register servlets by path should *not* in my opinion be a reason to extend behavior-by-path to other parts of Sling. Regards, Justin On Wed, Jul 3, 2013 at 8:22 AM, Dominik Süß dominik.su...@gmail.com wrote: Hi Bertrand, while I agree that paths should not drive the app they might build a scope for the logic, since the content is organized in a tree structure and not in by it's resourceType hierarchy, Therefore you often do have pathspecific operations (just think of workflows and workflowlaunchers in CQ). Or to come up with another scenario. Changing resourceTypes depending on the location of the same data on the other hand would be redundant information. So - the main Driver should be the resourceType is what is defining the behavior of a component while the contentpath in my eyes could act as restricting criteria. WDYT? On Wed, Jul 3, 2013 at 1:22 PM, Bertrand Delacretaz bdelacre...@apache.orgwrote: Hi, On Wed, Jul 3, 2013 at 12:55 PM, Dominik Süß dominik.su...@gmail.com wrote: ...why do you think registering logic by path is bad. Especially if I look at potential for multitenantsupport it would be great to be able to register postbehavior that is tenantspecific. And the tenantsupport of Sling is completely based on paths In general we want people to get away from the notion that paths drive your app, it should be resource types that do. Also, the problem with paths is that they are usually hidden in code, whereas resource types are transparently exposed in the content. For the POST handling, we could very well take the resource type of the parent/ancestors into account, instead of relying on paths. -Bertrand
Re: Sling Posthandling - thougts about the current behavior
On Wed, Jul 3, 2013 at 2:53 PM, Dominik Süß dominik.su...@gmail.com wrote: ...I bet a bunch of scripts/servlet currently check the contentpath first and react on this... Those servlets should die ;-) -Bertrand
Re: Sling Posthandling - thougts about the current behavior
Hi, On Tue, Jul 2, 2013 at 2:38 PM, Alexander Klimetschek aklim...@adobe.comwrote: Ack on the overall goal. The way I see it, it boils down to having the sling post servlet (or more specifically that new POST-pipeline) not just one special servlet out of many, but an integral part of Sling. Registering operations, post processors or whatever we need by resource type sounds good. By path not so much, don't know. IMHO, the rt would be taken from the addressed resource (what the URL addresses, to be 1:1 with how GET servlet resolution works; not any resources that additional request parameters might address) and if not present (creating a new resource) from the sling:resourceType param. It would actually be nice if those operations or postprocessor could become servlets or servlet filters again. They could get the necessary state passed via a request attribute for example + a utility to fetch them. And thinking about it, filters are actually the right thing, they are designed for pipelines. I am not sure if adding a :selector parameter as proposed by Justin (SLING-2936) is a good idea - maybe the integration with this new pipeline is the better long-term approach. You'd register by resource type + http method + :operation. Having both :operation and :selector (in the combined overall picture) seems like duplication. But it's difficult. Why wouldn't you register by resource type + method + selector? After all, that's what you do now. For pipeline components, we could add a phase registration property (or maybe ranking is enough). IMHO :operation is an aspect of the current default POST servlet. If we are going to move more POST-specific handling into the engine, then we should be using selectors. Justin It was mentioned that using selectors in the URL for POST requests, such as POST /content/page.createChild.html, is not RESTful. Is that really the case? As long as the server provides the URL instead of the client building it himself, such as path + .createChild.html as it happens way too much, and you use the right HTTP methods for changing/deleting content, nothing here would be unRESTful afaics. It would only look nicer if you put all the POST related information into the request parameters instead of into the URL. But then it's the old action=create topic again, which should be covered very well with the default features of the Sling post servlet already, which only requires you to add custom code (actions) for very specific things. This is even less once we have a validation framework in place (also resource type based), where Radu did a lot of work already! Cheers, Alex On 02.07.2013, at 15:26, Dominik Süß dominik.su...@gmail.com wrote: Well, if locking is just about permission I do agree with ACLs being the right solution (the permission set on the node itself might be sufficient for that case) - if it is about businessconstraints that need to be fullfilled an ACL cannot solve this requirement[0]. This is why validation and so on should be performed first, I would think of a pipeline having a contract on each phase what can be done and what cannot be done, while a first phase might not write any data (even as transient changes) the next phase might be perform (transient) change, then the postoperations would be performed in a transient followed by another phase that might perform transient changes and/or stop the processing, followed by a last phase that is called after the resourceResolve has performed a commit(). This is purely about giving developers a contract on what they can and cannot do (and therefore what they can expect 3rd party code to do) at a specific point in this pipeline. [0] a businessconstraint to control sepecific operations by permissions could be solved by a shadowstructure like proposed by Bertrand. -- Dominik On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz bdelacre...@apache.orgwrote: On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß dominik.su...@gmail.com wrote: Facing some questions about how to prevent the SlingPostServlet to be able to perform a change I had a closer look at the current implementation and it looks like there is currently no secure way of doing that beside locking the target on persistancelevel (alias setting ACLs)... ...which looks to me like the right way of locking things. But maybe for the post servlet we need a parallel structure to define who's allowed to do what. You could for example have /user-rights/sling/post-servlet/post/content/foo and whoever's allowed to read that is allowed to post to /content/foo, barring other ACL limitations. Just thinking outloud mostly...my point is that any security-related stuff should be driven by ACLs, and in some case indirect ACLs can be useful. -Bertrand
Re: Sling Posthandling - thougts about the current behavior
On Wed, Jul 3, 2013 at 2:58 PM, Justin Edelson jus...@justinedelson.com wrote: ...Why wouldn't you register by resource type + method + selector? After all, that's what you do now. For pipeline components, we could add a phase registration property (or maybe ranking is enough) And phase could be just a fake selector, PPP_foo or something where PP_ means POST Pipeline Phase. -Bertrand
Re: Sling Posthandling - thougts about the current behavior
If I got the implementation right you always trigger exactly one, so this is not an aspect, this is wat actualy is done to perform the post. Aspects are handled via PostProcessors. On Wed, Jul 3, 2013 at 2:58 PM, Justin Edelson jus...@justinedelson.comwrote: Hi, On Tue, Jul 2, 2013 at 2:38 PM, Alexander Klimetschek aklim...@adobe.com wrote: Ack on the overall goal. The way I see it, it boils down to having the sling post servlet (or more specifically that new POST-pipeline) not just one special servlet out of many, but an integral part of Sling. Registering operations, post processors or whatever we need by resource type sounds good. By path not so much, don't know. IMHO, the rt would be taken from the addressed resource (what the URL addresses, to be 1:1 with how GET servlet resolution works; not any resources that additional request parameters might address) and if not present (creating a new resource) from the sling:resourceType param. It would actually be nice if those operations or postprocessor could become servlets or servlet filters again. They could get the necessary state passed via a request attribute for example + a utility to fetch them. And thinking about it, filters are actually the right thing, they are designed for pipelines. I am not sure if adding a :selector parameter as proposed by Justin (SLING-2936) is a good idea - maybe the integration with this new pipeline is the better long-term approach. You'd register by resource type + http method + :operation. Having both :operation and :selector (in the combined overall picture) seems like duplication. But it's difficult. Why wouldn't you register by resource type + method + selector? After all, that's what you do now. For pipeline components, we could add a phase registration property (or maybe ranking is enough). IMHO :operation is an aspect of the current default POST servlet. If we are going to move more POST-specific handling into the engine, then we should be using selectors. Justin It was mentioned that using selectors in the URL for POST requests, such as POST /content/page.createChild.html, is not RESTful. Is that really the case? As long as the server provides the URL instead of the client building it himself, such as path + .createChild.html as it happens way too much, and you use the right HTTP methods for changing/deleting content, nothing here would be unRESTful afaics. It would only look nicer if you put all the POST related information into the request parameters instead of into the URL. But then it's the old action=create topic again, which should be covered very well with the default features of the Sling post servlet already, which only requires you to add custom code (actions) for very specific things. This is even less once we have a validation framework in place (also resource type based), where Radu did a lot of work already! Cheers, Alex On 02.07.2013, at 15:26, Dominik Süß dominik.su...@gmail.com wrote: Well, if locking is just about permission I do agree with ACLs being the right solution (the permission set on the node itself might be sufficient for that case) - if it is about businessconstraints that need to be fullfilled an ACL cannot solve this requirement[0]. This is why validation and so on should be performed first, I would think of a pipeline having a contract on each phase what can be done and what cannot be done, while a first phase might not write any data (even as transient changes) the next phase might be perform (transient) change, then the postoperations would be performed in a transient followed by another phase that might perform transient changes and/or stop the processing, followed by a last phase that is called after the resourceResolve has performed a commit(). This is purely about giving developers a contract on what they can and cannot do (and therefore what they can expect 3rd party code to do) at a specific point in this pipeline. [0] a businessconstraint to control sepecific operations by permissions could be solved by a shadowstructure like proposed by Bertrand. -- Dominik On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz bdelacre...@apache.orgwrote: On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß dominik.su...@gmail.com wrote: Facing some questions about how to prevent the SlingPostServlet to be able to perform a change I had a closer look at the current implementation and it looks like there is currently no secure way of doing that beside locking the target on persistancelevel (alias setting ACLs)... ...which looks to me like the right way of locking things. But maybe for the post servlet we need a parallel structure to define who's allowed to do what. You could for example have /user-rights/sling/post-servlet/post/content/foo
Re: Sling Posthandling - thougts about the current behavior
On 03.07.2013, at 14:58, Justin Edelson jus...@justinedelson.com wrote: IMHO :operation is an aspect of the current default POST servlet. If we are going to move more POST-specific handling into the engine, then we should be using selectors. Yes, my main point was to have only one. You are right, selector is the broader concept, so we could drop operation here. Looking at the existing operations [0], IMO all of them could/should be replaced by a param@Something style notation. We do this with @CopyFrom already, same could be done with @Checkin etc. Even import can be done this way. This moves it down from some request-global operation to a parameter specific option, with the benefit of allowing multiple ones in a single request. Then the POST is always the default create-or-modify operation. With the new pipeline, things can hook in and either overlay the default behaviour for certain parameters or handle custom ones (as PostProcessors typically do). We should make it simpler to read and modify the special RequestParameter map that is passed through, it is currently quite some work to read a custom @Something and get the right path for it etc. [0] http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html#ManipulatingContent-TheSlingPostServlet%2528servlets.post%2529-SlingPostServletOperations Cheers, Alex
Re: Sling Posthandling - thougts about the current behavior
On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß dominik.su...@gmail.com wrote: Facing some questions about how to prevent the SlingPostServlet to be able to perform a change I had a closer look at the current implementation and it looks like there is currently no secure way of doing that beside locking the target on persistancelevel (alias setting ACLs)... ...which looks to me like the right way of locking things. But maybe for the post servlet we need a parallel structure to define who's allowed to do what. You could for example have /user-rights/sling/post-servlet/post/content/foo and whoever's allowed to read that is allowed to post to /content/foo, barring other ACL limitations. Just thinking outloud mostly...my point is that any security-related stuff should be driven by ACLs, and in some case indirect ACLs can be useful. -Bertrand
Re: Sling Posthandling - thougts about the current behavior
Well, if locking is just about permission I do agree with ACLs being the right solution (the permission set on the node itself might be sufficient for that case) - if it is about businessconstraints that need to be fullfilled an ACL cannot solve this requirement[0]. This is why validation and so on should be performed first, I would think of a pipeline having a contract on each phase what can be done and what cannot be done, while a first phase might not write any data (even as transient changes) the next phase might be perform (transient) change, then the postoperations would be performed in a transient followed by another phase that might perform transient changes and/or stop the processing, followed by a last phase that is called after the resourceResolve has performed a commit(). This is purely about giving developers a contract on what they can and cannot do (and therefore what they can expect 3rd party code to do) at a specific point in this pipeline. [0] a businessconstraint to control sepecific operations by permissions could be solved by a shadowstructure like proposed by Bertrand. -- Dominik On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz bdelacre...@apache.orgwrote: On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß dominik.su...@gmail.com wrote: Facing some questions about how to prevent the SlingPostServlet to be able to perform a change I had a closer look at the current implementation and it looks like there is currently no secure way of doing that beside locking the target on persistancelevel (alias setting ACLs)... ...which looks to me like the right way of locking things. But maybe for the post servlet we need a parallel structure to define who's allowed to do what. You could for example have /user-rights/sling/post-servlet/post/content/foo and whoever's allowed to read that is allowed to post to /content/foo, barring other ACL limitations. Just thinking outloud mostly...my point is that any security-related stuff should be driven by ACLs, and in some case indirect ACLs can be useful. -Bertrand
Re: Sling Posthandling - thougts about the current behavior
Ack on the overall goal. The way I see it, it boils down to having the sling post servlet (or more specifically that new POST-pipeline) not just one special servlet out of many, but an integral part of Sling. Registering operations, post processors or whatever we need by resource type sounds good. By path not so much, don't know. IMHO, the rt would be taken from the addressed resource (what the URL addresses, to be 1:1 with how GET servlet resolution works; not any resources that additional request parameters might address) and if not present (creating a new resource) from the sling:resourceType param. It would actually be nice if those operations or postprocessor could become servlets or servlet filters again. They could get the necessary state passed via a request attribute for example + a utility to fetch them. And thinking about it, filters are actually the right thing, they are designed for pipelines. I am not sure if adding a :selector parameter as proposed by Justin (SLING-2936) is a good idea - maybe the integration with this new pipeline is the better long-term approach. You'd register by resource type + http method + :operation. Having both :operation and :selector (in the combined overall picture) seems like duplication. But it's difficult. It was mentioned that using selectors in the URL for POST requests, such as POST /content/page.createChild.html, is not RESTful. Is that really the case? As long as the server provides the URL instead of the client building it himself, such as path + .createChild.html as it happens way too much, and you use the right HTTP methods for changing/deleting content, nothing here would be unRESTful afaics. It would only look nicer if you put all the POST related information into the request parameters instead of into the URL. But then it's the old action=create topic again, which should be covered very well with the default features of the Sling post servlet already, which only requires you to add custom code (actions) for very specific things. This is even less once we have a validation framework in place (also resource type based), where Radu did a lot of work already! Cheers, Alex On 02.07.2013, at 15:26, Dominik Süß dominik.su...@gmail.com wrote: Well, if locking is just about permission I do agree with ACLs being the right solution (the permission set on the node itself might be sufficient for that case) - if it is about businessconstraints that need to be fullfilled an ACL cannot solve this requirement[0]. This is why validation and so on should be performed first, I would think of a pipeline having a contract on each phase what can be done and what cannot be done, while a first phase might not write any data (even as transient changes) the next phase might be perform (transient) change, then the postoperations would be performed in a transient followed by another phase that might perform transient changes and/or stop the processing, followed by a last phase that is called after the resourceResolve has performed a commit(). This is purely about giving developers a contract on what they can and cannot do (and therefore what they can expect 3rd party code to do) at a specific point in this pipeline. [0] a businessconstraint to control sepecific operations by permissions could be solved by a shadowstructure like proposed by Bertrand. -- Dominik On Tue, Jul 2, 2013 at 2:47 PM, Bertrand Delacretaz bdelacre...@apache.orgwrote: On Tue, Jul 2, 2013 at 2:38 PM, Dominik Süß dominik.su...@gmail.com wrote: Facing some questions about how to prevent the SlingPostServlet to be able to perform a change I had a closer look at the current implementation and it looks like there is currently no secure way of doing that beside locking the target on persistancelevel (alias setting ACLs)... ...which looks to me like the right way of locking things. But maybe for the post servlet we need a parallel structure to define who's allowed to do what. You could for example have /user-rights/sling/post-servlet/post/content/foo and whoever's allowed to read that is allowed to post to /content/foo, barring other ACL limitations. Just thinking outloud mostly...my point is that any security-related stuff should be driven by ACLs, and in some case indirect ACLs can be useful. -Bertrand
Re: Sling Posthandling - thougts about the current behavior
Hi everyone, I stand corrected, such a feature would not remove the SlingServlets entirely from the picture, since they are still needed for GET requests. +1 for the pipeline of operations concept. __ Dan -- View this message in context: http://apache-sling.73963.n3.nabble.com/Sling-Posthandling-thougts-about-the-current-behavior-tp4024713p4024751.html Sent from the Sling - Dev mailing list archive at Nabble.com.
Re: Sling Posthandling - thougts about the current behavior
As far as I got it right most agree that it would be great to have an optimized way to utilize the SlingPostServlet. I also +1 the idea of having a pipeline with different stages of processing where a dev can hook in based on some criteria (like resourcetype, path, extension and so on) to be able to break down the processing in the various aspects and therefore be able to implement reusable parts. There also where some concerns about having this as the only way of posting. And I also +1 that the support of custom Servlets should be optimized anyway and not be dropped. If a developer decides to get rid of this pipeline and taking care of all the aspects on his own he should be free to do that. In this case he would (intentionally) lose all the implicit logic provided by the SlingPostServlet and is completely on his own just having the SlingHttpServletResquest Response like for the GET Servlets. I think the next step would be to define the pipeline, the serverside logic that is applied on each step and the criteteria that shall be available to register the extensions. An interesting aspect of that is transactional behavior (like preventing session.save() up to a certain point in the pipeline to have a contract how long the data in any case is just in a transient state). Another idea that came into my mind on validation is the possiblity to have the post params returned in an annotated response that allows the client to resolve the problems and resubmit this (like Oak will be able to return such Conflictannotations on Concurrent Changes on a node). And this could also be used to implement multistepforms that need to be verified on the intermediate steps without actually persisting something (creating a restfull multistep form that way). WDYT? Dominik On Fri, Jun 28, 2013 at 8:51 AM, Daniel Platon dpla...@gmail.com wrote: Hi everyone, I stand corrected, such a feature would not remove the SlingServlets entirely from the picture, since they are still needed for GET requests. +1 for the pipeline of operations concept. __ Dan -- View this message in context: http://apache-sling.73963.n3.nabble.com/Sling-Posthandling-thougts-about-the-current-behavior-tp4024713p4024751.html Sent from the Sling - Dev mailing list archive at Nabble.com.
Re: Sling Posthandling - thougts about the current behavior
Hi Thanks Dominik for bringing this up. I really like the direction this discussion is taking. We really learned a lot about the Sling POST Servlet since we first created it and it is probably time for a complete rearchitecture. If we can also consider the post servlet as a pipeline of operations (validate, pre-process, store etc.) we'd have a flexible mechanism where you can avoid registering too many global things. A Pipeline sounds great. As for validation: This is something we are sourely lacking in Sling anyway. I think input validation is definitely something which should be part of the default Sling POST Servlet processing. But it should also be a feature, which is available independently for those cases, where the POST request is fully handled outside of the POST servlet. I have long thought SlingPostOperations should be registered against the resource type in the same way SlingServlets are registered against a resource type. +1 I think all extension points for the POST servlet (as well as the future input validation framework) should be configurable with a resource type. I also +1 the idea of having a pipeline with different stages of processing where a dev can hook in based on some criteria (like resourcetype, path, extension and so on) to be able to break down the processing in the various aspects and therefore be able to implement reusable parts. But I think neither the request selectors nor the request extension should be taken into account. The request URL should solely be addressing the resource and -- as a compromise to not being able to fully influence the Accept request header -- the resource representation. It should never contain request methods. Taking the resource path into consideration is interesting, though: For now we completely ignore the resource path in any resolution of scripts, filters and servlets. I fully agree, it may make sense for POST processing and for filters. But, would it maybe also make sense for general script and servlet resolution ? And if so, how ? (please spawn a new thread if you want to discuss this, thanks) Regards Felix Am 28.06.2013 um 11:15 schrieb Dominik Süß: As far as I got it right most agree that it would be great to have an optimized way to utilize the SlingPostServlet. I also +1 the idea of having a pipeline with different stages of processing where a dev can hook in based on some criteria (like resourcetype, path, extension and so on) to be able to break down the processing in the various aspects and therefore be able to implement reusable parts. There also where some concerns about having this as the only way of posting. And I also +1 that the support of custom Servlets should be optimized anyway and not be dropped. If a developer decides to get rid of this pipeline and taking care of all the aspects on his own he should be free to do that. In this case he would (intentionally) lose all the implicit logic provided by the SlingPostServlet and is completely on his own just having the SlingHttpServletResquest Response like for the GET Servlets. I think the next step would be to define the pipeline, the serverside logic that is applied on each step and the criteteria that shall be available to register the extensions. An interesting aspect of that is transactional behavior (like preventing session.save() up to a certain point in the pipeline to have a contract how long the data in any case is just in a transient state). Another idea that came into my mind on validation is the possiblity to have the post params returned in an annotated response that allows the client to resolve the problems and resubmit this (like Oak will be able to return such Conflictannotations on Concurrent Changes on a node). And this could also be used to implement multistepforms that need to be verified on the intermediate steps without actually persisting something (creating a restfull multistep form that way). WDYT? Dominik On Fri, Jun 28, 2013 at 8:51 AM, Daniel Platon dpla...@gmail.com wrote: Hi everyone, I stand corrected, such a feature would not remove the SlingServlets entirely from the picture, since they are still needed for GET requests. +1 for the pipeline of operations concept. __ Dan -- View this message in context: http://apache-sling.73963.n3.nabble.com/Sling-Posthandling-thougts-about-the-current-behavior-tp4024713p4024751.html Sent from the Sling - Dev mailing list archive at Nabble.com.
Re: Sling Posthandling - thougts about the current behavior
Something might come up this afternoon for SLING-2803 [1]. :) [1] - https://issues.apache.org/jira/browse/SLING-2803 As for validation: This is something we are sourely lacking in Sling anyway. I think input validation is definitely something which should be part of the default Sling POST Servlet processing. But it should also be a feature, which is available independently for those cases, where the POST request is fully handled outside of the POST servlet.
Re: Sling Posthandling - thougts about the current behavior
Hi Radu That would be great ! Thanks. Regards Felix Am 28.06.2013 um 12:49 schrieb Radu Cotescu: Something might come up this afternoon for SLING-2803 [1]. :) [1] - https://issues.apache.org/jira/browse/SLING-2803 As for validation: This is something we are sourely lacking in Sling anyway. I think input validation is definitely something which should be part of the default Sling POST Servlet processing. But it should also be a feature, which is available independently for those cases, where the POST request is fully handled outside of the POST servlet.
Re: Sling Posthandling - thougts about the current behavior
On Thu, Jun 27, 2013 at 12:52 AM, Ian Boston i...@tfd.co.uk wrote: ...I have long thought SlingPostOperations should be registered against the resource type in the same way SlingServlets are registered against a resource type Absolutely - there are other things (validation etc.) where we would benefit from using a similar same resource - X resolution that we have for resource - servlet, so we should generalize the mechanism. If we can also consider the post servlet as a pipeline of operations (validate, pre-process, store etc.) we'd have a flexible mechanism where you can avoid registering too many global things. -Bertrand
RE: Sling Posthandling - thougts about the current behavior
+1 That would be very nice. Jeff. -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: 27 June 2013 08:26 To: dev@sling.apache.org Subject: Re: Sling Posthandling - thougts about the current behavior On Thu, Jun 27, 2013 at 12:52 AM, Ian Boston i...@tfd.co.uk wrote: ...I have long thought SlingPostOperations should be registered against the resource type in the same way SlingServlets are registered against a resource type Absolutely - there are other things (validation etc.) where we would benefit from using a similar same resource - X resolution that we have for resource - servlet, so we should generalize the mechanism. If we can also consider the post servlet as a pipeline of operations (validate, pre-process, store etc.) we'd have a flexible mechanism where you can avoid registering too many global things. -Bertrand
Re: Sling Posthandling - thougts about the current behavior
Hi everyone, Although I don't have that much experience with Sling, I'd +1 any feature that allows the developer to attach behaviour to content (at least this is what a PostProcessor sounds to me). I made extensive use of such a feature when I use to developer content management application on Documentum. Also, I think such a feature would make binding the SlingServlets to resource type obsolete... _ Dan -- View this message in context: http://apache-sling.73963.n3.nabble.com/Sling-Posthandling-thougts-about-the-current-behavior-tp4024713p4024725.html Sent from the Sling - Dev mailing list archive at Nabble.com.
Re: Sling Posthandling - thougts about the current behavior
On Thu, Jun 27, 2013 at 2:03 PM, Daniel Platon dpla...@gmail.com wrote: ...I think such a feature would make binding the SlingServlets to resource type obsolete... Now you got my attention...but you'll need to clarify your use case and ideas I guess ;-) -Bertrand
Re: Sling Posthandling - thougts about the current behavior
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
