>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]
