I hope my original message is not taken as a slam on struts. I love it. I want to chorus in by saying "GOOD JOB STRUTS TEAM!". I am just wondering if my thoughts are totally unfounded or have some validity. I have been known to be an idiot. :-)
Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws > -----Original Message----- > From: Kenneth Stout [mailto:[EMAIL PROTECTED]] > Sent: Sunday, August 18, 2002 11:30 AM > To: Struts Users Mailing List > Subject: Re: Struts Community is going crazy! :-)) > > > Brandon, > > I agree with your cry for better "suggested" patterns. I've been working > with struts for less than six months and looking for patterns has been a > constant endeavor. I have 8-inches of printed documents plus several > megabytes of disc space dedicated to everything that I've been able to get > my hands on. This search is made more difficult as struts moves > from version > 1.0 to 1.1. (Don't get me wrong. I think the new features being > added in 1.1 > are absolutely fantastic!) However, what I have found in my search are > examples for either trivial (test) environments, or major project > environments. The former are good for testing some feature and > the later is > considerable overkill for the projects that I typically deal with. > > As I look back, I think my learning curve would have been shortened > considerably if we had a library of patterns for small, medium, and large > projects at both the 1.0 and 1.1 levels. > > As to your final point about struts being bulky with all of the included > extensions. To this I would have to disagree. I really like the idea that > some of the more common extension are included with new releases. > This makes > it much easier to update to a newer version of struts. I don't have to run > around and collect them or wait for them to become compliant with > the newer > version of struts. On the other hand if I don't want to use them I simply > don't move the jar's or configuration files into my new projects folders. > The building block approach really allows you to minimize struts to only > what you need. That's not something that you can say about some of the > alternatives to struts. > > To the struts community: keep up the good work. There are a number of very > talented programmers working on struts and with struts. And it shows! > > Kenneth. > > > ----- Original Message ----- > From: "Phase Web and Multimedia" <[EMAIL PROTECTED]> > To: "Struts User List" <[EMAIL PROTECTED]> > Sent: Sunday, August 18, 2002 9:39 AM > Subject: Struts Community is going crazy! :-)) > > > > I have seen so many extensions and ideas being developed around struts. > One > > of the things that I have noticed is that there are a lot of different > > apporaches being taken towards using Struts. In my own > conversations with > > colleagues I have found that there is a fair amount of > confusion mounting > > over proper design patterns within and extending struts. > > > > I don't know if there is a base set of "suggested" patterns > that have been > > layed out. But, maybe we can collect the wisdom of the contirbutors in > order > > to avoid development of heavy or misplaced extensions or apps. > I know Ted > > has laid down some stuff for us to view in his "Catalog". But, > there have > > been several things I've seen popping up. For example, The > debate used to > > be... do i extend the Action class or the Action Servlet... Now, we seem > to > > be extending the crap out of the Request Processor. The danger is that > there > > many ways to implement an idea and it could work in the extended Action > > class or the extended RequestProcessor. But, why should we extend the > > ReqeuestProcessor or the Action class. What extensions are best run > against > > each of the extendable classes within struts. Also, I have seen a > > processPreprocess() method that is being used in the RequestProcessor > class. > > What is the best use for processPreproccess()? > > > > Finally, from what i am seeing of the struts codebase is that it is > starting > > to get really bulky. I thought the goal was to remain lightweight and > > provide hooks for extensions. I am seeing all the nifty extensions being > > developed and put into the base. Isn't there a way we can provide > > configurable extending? Rather than work on making the base > include every > > good extension, why not make the base easier to extend and provide a > > standard set of hooks that can be used to access the internals. I think > > maybe I'm all washed up on this. I have been using struts for a year now > and > > I am constantly wondering what the heck is going on. Everyone > seems to be > > doing things different and it's getting difficult to build a > project that > is > > going to have some longevity. > > > > In summary, I am seeing people develop extensions that conflict > and do not > > play nice with other extensions. I see Action classes being > extended and I > > see RequestProccessor classes being extended which are making > for a mighty > > mess when trying to get them to play together in a single > project. It just > > seems that there needs to be a little clarity on extending > practice/purpose > > and we need to get some clarity or development focus on an > easier and more > > configurable extending of struts. > > > > Is anyone else thinking what I am? > > > > > > Brandon Goodin > > Phase Web and Multimedia > > P (406) 862-2245 > > F (406) 862-0354 > > [EMAIL PROTECTED] > > http://www.phase.ws > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
