I am very interested in this discussion, and will have more time to think of the overall structure after the release of JSR-168 Reference Implementation (Pluto).
At a cursory level, i see Struts provides very simple and elegant flow controllers of what-to-do and how-to-do based on standard Servlet container. Tiles is an elegant dynamic templating engine, also based on standard Servlet container. I see JSP tiles as a plus rather than a short-coming since J2EE has JSP as its dynamic page assembling. JSR-168 portal/portlet containers are official extension of Servlet container. It seems not a very major issue to make Struts and tiles a 1-2 punch for JSR-168 portal/portlet containers. Tiles context may be refactored into Portlet context. Tiles already has a facility to dynamically generate tile attributes for changing the page assembling. This is probably what the JSR-168 authors mention that "Portlet can act as controller, fill a bean with data, and include a JSP to render the output". See this pattern?
The effort is valuable, since many Struts Plug-ins can be parts of our tools. I see Jetspeed is too heavy, not simple and elegant enough to realize the potential of JSR-168 and WSRP. We can learn many designs from Jetspeed to bring them into this new portal/portlet framework with simple and elegant design infrastructure. I hope many designers and developers interested in this relevant topic: Struts-Tiles-Portal-Portlet framework and container.
BaTien DBGROUPS
Mete Kural wrote:
Hello Struts developers,
I wanted to get your opinions on how Struts should be used as a portlet framework. I think that it would be great if a portlet framework was part of the standard Struts distribution in the near future. JSR-168 which defines standard portlets will be finalized pretty soon (a month?), although the specification draft is pretty much stable hereafter.
I have two main questions:
1) My first question is technical. How do you think portlet support would be best added to Struts? Which classes should be extended? Are there necessary changes at the core classes of Struts in order to provide an efficient framework for building portlets?
2) Second question is about how a Struts-based or Struts-like portlet framework should be distributed. Should it be part of the core Struts distribution? Should there be two different Struts distributions within the Struts project: "Struts for Webapps" and "Struts for Portlets"? Or should it be a seperate Jakarta project?
I look forward to hearing your opinions.
Thank you very much. Mete
--------------------------------------------------------------------- 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]
