> 4 - if solid tools are used to generate certain elements; for example - > the > struts-config.xml? Stubs for our Actions and Forms. Does anyone have any > favorite tools that may help here? I've seen EasyStruts on > eclipse-plugins.2y.net but have not used.
FWIW, I think EasyStruts is a great tool. Regards, *===================================* * Scott T Weaver������������������� * * Jakarta Jetspeed Portal Project�� * * [EMAIL PROTECTED] * *===================================* � > -----Original Message----- > From: Tim Reilly [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 17, 2003 8:50 PM > To: Jetspeed Developers List > Subject: RE: Struts as a JSR-168 Portlet Framework > > Excellent! > I just spent the afternoon "lobbying" for Struts use at the portlet > level... > I'm not sure I did very well. > > In the end it came down to: > > * Each advocate of methodologies will present our representative > use-case:"Add Client Site" developed in their respective methodology this > coming Monday (So for me that means using IBM portlet revision of > Struts1.1-b2 to develop this functionality for Mon.) > > The main alternate contenter is using the MVC portlet. This implies coding > the if..else if..else if..else in the controller; however the point was > made > that since the responsibilities of a portlet should not be as large as > that > of a "normal" struts application this is acceptible. > > * Someone estimated a factor of 4 as the time required to develop in > Struts > versus not developing with Struts. This is also the person in our group > with > the most Struts experience, so I can't really argue against... except > perhaps to capture my time and present that as well on Monday. > > * Others in the group expressed apprehension to the fact that we are using > a > modified version of Struts. I mentioned based on a previous post on this > list, that the Struts community is behind supporting portlets as well as > servlets. Your posting here reaffirms this for us so .. thank you. > > * I mentioned that although Struts adds complexity it provides; a) a > well-known framework for application development. b) Would ease certain > development and maintainence. c) Provide a proven framework for > validation. > d) Allow new team members to "get up to speed" faster since the framework > is > so well known. > > * I added to the discussion ... that development time may not be a factor > of > 4 - if solid tools are used to generate certain elements; for example - > the > struts-config.xml? Stubs for our Actions and Forms. Does anyone have any > favorite tools that may help here? I've seen EasyStruts on > eclipse-plugins.2y.net but have not used. > > I'd love to hear people's thoughts on this topic. > > [I realize this is perhaps off-topic for jetspeed-dev, so I am posting it > on > [EMAIL PROTECTED] with same for reply-to; e.g: Trying to > move > sub-thread from dev to user? > If it doesn't work right please just reply to > [EMAIL PROTECTED] > > Thanks. Hope hear your thoughts. > > > > -----Original Message----- > > From: David Sean Taylor [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 17, 2003 2:29 AM > > To: Jetspeed Developers List > > Subject: Re: Struts as a JSR-168 Portlet Framework > > > > > > > > On Tuesday, September 16, 2003, at 09:25 AM, Mete Kural wrote: > > > > > You are right, David, Struts 2.0 does not claim to be working at the > > > portal layer. That is, as you say, the portal server's concern such as > > > Jetspeed. Struts 2.0 aims to be a framework for building portlet > > > applications (JSR-168 compliant). > > > > > > Right now, Struts committers are re-designing the RequestProcessor to > > > make it flexible for portlet environments as well as plain servlet > > > environments. They need feedback from the portal community in order to > > > make sure that the re-design is done in a way that effectively > > > satisfies the needs of portlet environments. Please take a look at the > > > code in the Struts CVS at contrib/struts-chain. I would recommend you > > > to ask any questions to the Struts committers in the struts-dev > > > mailing list. > > > > > Sounds great! > > I will have a look at the code in contrib/struts-chain > > > > -- > > David Sean Taylor > > Bluesunrise Software > > [EMAIL PROTECTED] > > +01 707 773-4646 > > +01 707 529 9194 > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > ---------- Original Message ---------------------------------- > From: David Sean Taylor <[EMAIL PROTECTED]> > Reply-To: "Jetspeed Developers List" <[EMAIL PROTECTED]> > Date: Tue, 16 Sep 2003 16:45:50 -0700 > > > > >On Tuesday, September 16, 2003, at 05:23 AM, Mete Kural wrote: > > > >> Hello all, > >> > >> The topic of adapting Struts to be a portlet framework compliant with > >> JSR-168 was discussed earlier. I remember that some of you were > >> interested in contributing to such a project. Now is the opportunity. > >> One of the goals of the next generation of Struts, Struts 2.0, is > >> "Transparent support for a portlet environment (JSR 168)". Development > >> for Struts 2.0 has already begun little by little. Here is the roadmap > >> page for Struts: > >> http://jakarta.apache.org/struts/status.html > >> Please scroll down for the part that is titled "Struts 2.0.x" and then > >> the part under it that is titled "Portlet (JSR-168) Whiteboard". > >> Struts committers are seeking out the help of others to make > >> suggestions and improvements to these initial development stages of > >> Struts 2.0. Jetspeed developers and users can be especially useful in > >> making sure that Struts 2.0 addresses the needs of portlet developers. > >> You can do this by sending your feedback to the Struts committers. > >> Here is what Craig McClanahan wrote about building portlet support in > >> Struts: > >> > >> "One approach to dealing with it has (in fact) already begun -- in the > >> "contrib/struts-chain" subdirectory in the CVS sources is the > >> beginnings > >> of a refactoring of the standard RequestProcessor based on the > >> "commons-chain" package in the Commons Sandbox. If this actually > >> works, > >> two really good things might be able to happen: > >> > >> * It'll work for both servlets and portlets (you can see how the > >> command implementations are being abstracted so that the chain will > >> just do the right thing for each environment). > >> > >> * It is likely to be backwards compatible with Struts 1.1 as well, > >> possibly with some restrictions yet to be discovered. > >> > >> The best way to get involved would be to check out CVS sources for > >> both jakarta-struts and jakarta-commons-sandbox, become familiar with > >> the code > >> referenced above, and start making suggestions and improvements. A > >> really good starting point would be portlet-specific implementations > >> of all the > >> commands that currently have only servlet-specific implementations. " > >> > >> I would recommend anyone who is interested to give feedback to the > >> Struts committers on the struts-dev mailing list. > >> > >> Thanks, > >> Mete > >> > > > >Thanks for the invitation. > > > >Are there any plans for integrating with Struts with Jetspeed-2? > >I see Jetspeed as doing one thing well: a portal server. > >Struts is good for web (and soon to be portal) development. > >Separation of concerns. > >I would see Struts working at the portal application layer, not at the > >portal layer, which is the concern of Jetspeed. > >Anyway thats just my view... > > > > > >-- > >David Sean Taylor > >Bluesunrise Software > >[EMAIL PROTECTED] > >+01 707 773-4646 > >+01 707 529 9194 > > > > > >--------------------------------------------------------------------- > >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]
