Aaron Evans wrote:
On 3/23/06, David Sean Taylor <[EMAIL PROTECTED]> wrote:
Aaron Evans wrote:
On 3/23/06, David Sean Taylor <[EMAIL PROTECTED]> wrote:
What do you think about a new feature where Jetspeed can execute secured
ajax actions in portlet applications. The actions would just be POJOs
like in the Jetspeed AJAX API, and we could secure the actions in the
security policy
ets> >
Yes, that sounds like a dandy idea. But it might be nice if the
actions were actually implementations of some simple interface whose
'doAction' method or whatever had access to the request and response.
Take a look at the interfaces here in the Jetspeed API:
http://portals.apache.org/jetspeed-2/multiproject/jetspeed-api/apidocs/org/apache/jetspeed/ajax/package-summary.html
I had a look. The AJAXService says it "Performs invocation of the
actual AJAX request and returns a result object to converted into
XML.". It is unclear to me how one controls what the resulting XML
would look like.
The uppercase AJAXService is the one I do not use, so Im not the person
to respond on that. (We really need to combine these 2 prototypes into
one solution). Take a look at AjaxService and see if that helps
Yes, I agree. Java class names should not be exposed to the client.
A run time binding of action names to action implementations (bound to
a portlet app) with security constraints would be ideal. Something
similar to the way URIs map to actions in struts (but obviously in
this case, we can't use a URI pattern, but rather a request
parameter).
There is already something in place for that, see ajax-layout.xml, a
Spring configuration solution
Lets not let this feature (executing ajax actions on portlets or pojos)
not slip through. Could you create a JIRA issue for a new feature with a
brief description of how you would like it to work?
Thanks
I suppose I should look into this possibility for my immediate
requirements. To be honest, I haven't really experimented with the
portlet pipeline as there isn't much documentation (at least that I
found) about it. I only recently was tipped off by cubehead that you
can invoke a portlet using a URL of the form:
/jetspeed/portlet/?portlet=portlet-app::portlet-name&entity=id
The portlet pipeline has been around for a while.
Its embedded in several other portal products, including Jetspeed 1.6.
I have slides describing it from the 2005 ApacheCon. I will try to get
those into the main documentation stream. Not sure if you are on
jetspeed-dev mailing list or not. See the commits that have gone in this
week with the Jetspeed Desktop feature. We are using the portlet
pipeline quite a bit there, lots of examples.
By the way, I assume this invokes the portlet's render method, is
there a way to invoke the processAction?
Timely question.
Steve and I are working on a solution for exactly that today.
Recommend subscribing to jetspeed-dev and monitor the commits
I have found that when I call a portlet page with request parameters
in the URL, they are accessible from within the RenderRequest of all
Portlets in the page. Wouldn't the same apply to the portlet pipeline
(ie. if I appended additional request parameters)?
If so, since render parameters and request parameters are accessed via
the same API call (request.getParameter), it may not be necessary to
actually create render parameters from the request parameters since
that would only make them "sticky" (ie. they'd still be present for
subsequent calls to the render method).
Yup, this is something Im looking into too. I need to do a bit more
digging and I'll comment back later
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
