BaTien DBGROUPS
Mete Kural wrote:
Struts-Tiles-Portal-Portlet framework and container.
I think that there is a big difference between the framework used to build a portal server and a "portlet framework". I see that Struts+Tiles is a very good framework to build a portal server, but it seems to me that the ways in which Struts would be used as a framework for building a portal server are very different than Struts being used as a "portlet framework".
IMHO, Struts developers should focus on making Struts an efficient portlet framework. Portal server developers could tweak Struts in their own ways in order to use it as a framework for building their portal server, but I don't see the need for standardization in this area. Standardization is rather necessary in the are of using Struts as a portlet framework.
What are your opinions?
-Mete
---------- Original Message ---------------------------------- From: BaTien Duong <[EMAIL PROTECTED]> Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> Date: Wed, 13 Aug 2003 11:02:44 -0600
Greetings:
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]
--------------------------------------------------------------------- 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]
