...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
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
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
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
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
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
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
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
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
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
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
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
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
-Posthandling-thougts-about-the-current-behavior-tp4024713p4024751.html
Sent from the Sling - Dev mailing list archive at Nabble.com.
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.
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
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
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
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
+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
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
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
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
23 matches
Mail list logo
