Re: Struts for Portlets (requesting your opinions)
I couldn't agree more, however I'm not sure if the answer is a completely independent core like xwork or totally wrapping servlet objects and method calls like Cocoon in generic Enviroment objects. If Struts application should be able to be exposed in multiple environments, perhaps the Cocoon approach has more value. It might be nice to eventually even be able to run Struts from the commandline :) Don On Wed, 13 Aug 2003, Mete Kural wrote: Agree. I just read Craig ideal view and I think this view may be a good start. I think so too. I will re-state Craig's ideal goal below for others to catch up: I believe that we should aim for the following ideal state -- a Struts application shoud be usable either as a webapp or as a portlet, with little (ideally no) changes. Therefore, I believe that we'd build whatever it takes to support this into the standard Struts distribution, which would then be used in both environments. I would like to ask everybody what their opinions are about this topic. Is it technically possible for Struts to enable the same application to be turned into a webapp or a portlet at the switch of a button? Could the fundamental differences between a webapp and a portlet not allow such a possibility? Mete -- Original Message -- From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] Date: Wed, 13 Aug 2003 12:24:47 -0600 Agree. I just read Craig ideal view and I think this view may be a good start. 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
Re: Struts for Portlets (requesting your opinions)
Mete Kural wrote: Agree. I just read Craig ideal view and I think this view may be a good start. I think so too. I will re-state Craig's ideal goal below for others to catch up: I believe that we should aim for the following ideal state -- a Struts application shoud be usable either as a webapp or as a portlet, with little (ideally no) changes. Therefore, I believe that we'd build whatever it takes to support this into the standard Struts distribution, which would then be used in both environments. I would like to ask everybody what their opinions are about this topic. Is it technically possible for Struts to enable the same application to be turned into a webapp or a portlet at the switch of a button? Could the fundamental differences between a webapp and a portlet not allow such a possibility? Mete I think somewhere in Bea dev2dev, there is a download to make Struts app as a JSR-168 portlet running in Bea portal container. I am more interesting in using Struts with no burden and complexity of proprietary technologies. Sticking to formal standards, it is easy to adapt to any required proprietary environment. BaTien DBGROUPS -- Original Message -- From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] Date: Wed, 13 Aug 2003 12:24:47 -0600 Agree. I just read Craig ideal view and I think this view may be a good start. 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
Re: Struts for Portlets (requesting your opinions)
Agree. I just read Craig ideal view and I think this view may be a good start. I think so too. I will re-state Craig's ideal goal below for others to catch up: I believe that we should aim for the following ideal state -- a Struts application shoud be usable either as a webapp or as a portlet, with little (ideally no) changes. Therefore, I believe that we'd build whatever it takes to support this into the standard Struts distribution, which would then be used in both environments. I would like to ask everybody what their opinions are about this topic. Is it technically possible for Struts to enable the same application to be turned into a webapp or a portlet at the switch of a button? Could the fundamental differences between a webapp and a portlet not allow such a possibility? Mete -- Original Message -- From: BaTien Duong [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] Date: Wed, 13 Aug 2003 12:24:47 -0600 Agree. I just read Craig ideal view and I think this view may be a good start. 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] . -
