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. > 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. 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). > > 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 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 By the way, I assume this invokes the portlet's render method, is there a way to invoke the processAction? 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). > > > 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 :( > > Well no rush, I mean, I think it is better to throw ideas around first and have a well thought out solution. :) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
