Ate Douma wrote:
Serge Huber wrote:
On Mar 17, 2005, at 6:59 PM, David Sean Taylor wrote:
Im wondering if any of the Struts bridge can also be leveraged here.
Well I'm not an expert of the Struts bridge, but from my understanding the Struts bridge uses Struts' internal dispatching system to cut things in two : Struts action is processed in processAction, and the forwarding to the JSP happens in render().
Actually, the preferred way to use Struts within a Portlet is to use two
Struts Actions: one for processAction forwarding to a RenderAction which
in the end dispatches to a JSP.
But yes, if an Struts Action forwards to a JSP from within an ActionRequest
the Struts bridge will break in and defer the JSP rendering.
Unfortunately for regular servlets this is not possible, as we don't necessarily have a two-phase process (controller -> view). If one wanted, they could do everything with just a JSP, or just a servlet, and it would still have to work.
Well, how are you going to process posted data? In a portlet you *have* to process these during ActionRequest because the parameters will be lost in the RenderRequest. Whatever way you look at it, you will have to split the controller and view for that. I never looked deeply into the PHP/Perl portlet bridges but I'm wondering how it is solved there if they neither use the ActionRequest.
The PERL/PHP portlet bridges implement the ActionRequest for processing posted data. Post data is not available in the Render Request. The perl/php specific data from the post is extracted in the ActionRequest and "re-packed" in a session object that then is processed by the RenderRequest.
One possible (but ugly) solution might be capturing all ActionRequest
parameters and store them in the PortletSession and restore them in the
next RenderRequest. I've provided something of that kind (but then for
saving ActionRequest Attributes) in the Struts bridge which can be
configured through the struts-portlet-config.xml. Maybe that feature of the
Struts bridge can be of use to your proposed bridge...
Maybe Ate could look at the code and tell me if there are synergies I might have missed.
Looking at the HTMLPostProcess class, and it looks to me like it doesn't use the rewriter framework that Perl/PHP use, but instead uses straight Java logic and string processing.
Well actually I re-used the original code that Roger did in ScriptPostProcess (and renamed it to HTMLPostProcess), but I have to modify it to add some logic to bypass URL rewriting in the case of URLs that look like this :
<a href="javascript:doSomething()">action link</a>
<a href="portlet-download:http://localhost:8080/context/ servletThatOutputsDataStream">download link</a>
(portlet-download: is a marker that the parser recognizes as an URL that shouldn't be transformed. The prefix is stripped during post processing and sent to the browser starting at http://...)
I changed the Perl portlet bridge so that it uses the rewriter class. The PHP portlet still uses the ScriptPostProcess but I plan to use the rewriter component for the PHP portlet bridgs as well. I suggest that we use the rewriter instead of custom implementation since it's more flexible.
I don't know if this behavior is desired in the default ScriptPostProcess behavior, but if it is we could remove the HTMLPostProcess class and simply use ScriptPostProcess (which was what I originally did until I had the problem with the javascript links and URLs that shouldn't be rewritten).
Regards, Serge Huber.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
