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
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
There are actually two Ajax upshoots in Jetspeed right (three if you
count the desktop work). The two in this directory are non-compatible.
The one I use depends on the RequestContext, since its very much a
Jetspeed type API. We need to access a lot of Jetspeed components in our
Jetspeed actions.
The actions 'could' be dynamically found (there is already code to do
that in the first ajax impl). As long as the actions are secured, this
might be a good solution. Pretty cool. In the past I've tried to
abstract the Java class names from the Javascript programmer, so they
could simply be called by an action name. I prefer this method as its
easier for me when coding on the client side, and seems more secure.
Perhaps a runtime registration of actions might work, and associate the
action with a portlet application so we can get the class loader hooked
up correctly.
Im also thinking the actions could be methods on portlets.
I guess Im still in the 'thinking' stage here, thinking out loud on a
public mailing list...
For my particular use case, I'm not just triggering server side
business logic, I'm also writing XML to the response. And actually,
if you could control the response headers and write to the response,
that would also solve the download of arbitrary binary data problem.
Almost sounds to me like you want a portlet that acts upon an xml
content type. Calling the portlet pipeline, no?
The challenge there is having the Javascript send parameters to the
portlet. Perhaps the portlet pipeline should take the servlet request
parameters, if on a portlet pipeline, and send them on to the portlet as
portlet render parameters.
This sounds interesting
Of course it would be sweet if there were something in the
portal/portlet spec that we could leverage here (and not be so
proprietary), but I just don't think there is anything that fits the
bill...
The portlet spec team just started discussing this
Unfortunately Im a few weeks behind on my emails there :(
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
