> I think it's worth mentioning that the "action phase" and "render phase" are > distinct concepts that come directly from the Portlet API, with or without > Struts. > > So Torsten's original confusion is ours as well - Struts2 portlet support > doesn't seem to separate the two, but rather lump them together as a single > "view phase". Obviously this is a big problem performance wise, e.g. you > really want to make your heavy service-tier invocation at action time, and > *not* each time a user resizes a portlet for instance - that would just be a > call to render.
Luckily, that is not the case :) Maybe not crystal clear, but it is mentioned in the portlet plugin documentation [1]. To summarize, when you do a state change transition (e.g. posting a form, or clicking a link with the "action" url type), if you have set up the results in a post-redirect-get fashion, the action processing the form will do so in the action phase, and the view result will be rendered in the render phase. So you can take full advantage of the portlet API features such as caching the view. > > The PortletActionContext does make mention of the RENDER_PHASE, we're > looking now at how to use that, probably in an if-then expression within the > single execute() method. > > The generic interceptor concept, while somewhat analogous to the action > phase/render phase, doesn't really solve the problem that struts lacks a > natural exposure of the underlying portlet API. Using the PortletActionContext you can access the full portlet API. There are also pre configured interceptors that can inject the portlet objects into your action (take a look at the portlet tutorial [2]). Other than that, if there are specific features that you are looking for, please let me know so we can improve the plugin. > > So I can't resist quoting the Spring Portlet MVC docs: "Most other portlet > MVC frameworks attempt to completely hide the two phases from the developer > and make it look as much like traditional servlet development as possible - > we think this approach removes one of the main benefits of using portlets." > I like to think that the Struts 2 Portlet Plugin does both: It hides it by "translating" it to regular Struts 2 and web application concepts, but it also allow you to access and do whatever with the portlet API that you wish. That way, both developers who want to quickly convert their existing web app, and developers who create the portlets from scratch can do so in a productive way. As a matter of fact, right from the beginning the portlet plugin was created with the second scenario in mind. I totally agree that you should be fully aware of the underlying portlet framework to make the best use of the plugin. > But we'd really rather use Struts2! I totally agree ;) Nils-H [1] - http://struts.apache.org/2.x/docs/portlet-plugin.html [2] - http://struts.apache.org/2.x/docs/struts-2-portlet-tutorial.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
