I must speak up here. I would be so bold as to say that Struts is important to use on all level of sites. I have developed sites in Perl, ASP (not .NET), PHP and I would have to say they all lack in comparison to J2EE/Struts. Most of my sites are "small" non-enterprise level apps. But, there are still ample organizational needs and maintainability issues that are addressed through the use of Struts. If it requires dynamic interaction then Struts is worth the time learning an applying to any project.
The most important thing to remember is REUSE. The Struts framework is the Model2 portion that is reusable. The next step is to take Struts throw in a few useful APIS and a few other complementary frameworks and you have yourself a reusable environment that can span across several project. I have successfully been able to create "reusable" modules that are the same across several sites. This is a major time savings and it makes me profitable. A little work up front pays off later. Brandon Goodin -----Original Message----- From: Gandle, Panchasheel [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 6:59 AM To: 'Struts Users Mailing List' Subject: RE: Justifying Struts For a simple and small project it really doesn't matter whether you implement model 1 or 2 or any kind of framework. But when it comes to large projects and complexities, a more clean structured model is always desired. It all accounts when maintaining the whole application. Whether its a Java Bean, EJB, or a JSP, I prefer to write it clean, small and simple logics, in a clean, simple and small source file. I moved from a model 1 arch to model 2 and now to struts, I could definitely see the importance of all the elements in the framework, whether its a layout tiles, validator or taglibs. For larger and complex projects, definitely struts framework is WORTH, pays off in developing and maintaining. All I can say is its CLEAN and SIMPLE thats what we strive for in life as well. Panchasheel -----Original Message----- From: Mike Jasnowski [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 8:38 AM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: Justifying Struts Why can't the bean either be > generated > automatically or there be a general purpose bean (with properties that > are > created dynamically) that works for all forms? Have you looked at DynaForms? > 1) I think the separation of presentation (view) from the model and > controller > has gone too far (or probably is not done well in Struts). For > example, I like > to have my front end developers do form (field) validation. These > developers > should not have to write beans to do this (all examples I've seen so > far do > form validation in Java beans). This somewhat contradicts the J2EE > development > model where "application developers", who are basically scripters (not > OO > developers), do the front end work. I think in some cases though, validation constraints are complex enough they cannot all be done through simple means. Once you start adding on layers of complexity, without a good pattern to follow, you may get each developer doing it slightly differently. -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 5:38 AM To: Struts Users Mailing List Subject: RE: Justifying Struts Maybe he should also drop java and the servlet api while he is at it - after all you can do all of that stuff in assembly code. How hard is it to implement a web server? - just listen on the port, send some text back and forth. Piece of cake. Run a lot faster too without all that unneccesary overhead the jvm imposes. <snip> "application developers", who are basically scripters (not OO developers) </snip> Oh we are just scripters are we? I suppose its true - real programmers write straight to the metal - none of this high level language stuff... design patterns are for quiche eaters... http://www.pbm.com/~lindahl/real.programmers.html http://www.psych.usyd.edu.au/pdp-11/rp.html Ok thats probably enough since its still only Thursday... ;-> -----Original Message----- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 17:10 To: Struts Users Mailing List Subject: Re: Justifying Struts I'm sorry man, you're reservations are mostly wrong. one thing you have to bare in mind is that we're not all as clever as you, in fact i'd argue that I'm very stupid and many people are as equally stupid. If you've managed to maintain an MVC pattern using model 1 techniques what are you doing researching struts? Model 1 techniques were also attempts to encourage MVC but html'ists who are keen to overcome their programmer envy would break the pattern, if you don't have this problem and your current development practices don't break this pattern you don't need struts then do you? I'm interested in how many times "oh that's easy" is said in your team, how much unaccounted time pops up on your projects especially when completing "easy" tasks. taglibs have value in the real world and the struts taglibs more so, the overhead isn't that great and are far less than the cognitive overheads that some ropey scriptlet writing can cause. while i understand your preference for scriptlets, putting your team forward as the sole inhabitance of the "real world" sounds a little incongruous with the model 1 utopia that you're all living in. Anyway there are numerous threads like yours on this group that have been posted over the last few weeks. take a read. i'd argue that your position requires justification not struts. cheers mark I've heard about > Struts and have researched it over the last few hours. The MVC > approach makes > sense, but I'm still not sold on it yet. Here are some doubts I have. > > 1) I think the separation of presentation (view) from the model and > controller > has gone too far (or probably is not done well in Struts). For > example, I like > to have my front end developers do form (field) validation. These > developers > should not have to write beans to do this (all examples I've seen so > far do > form validation in Java beans). This somewhat contradicts the J2EE > development > model where "application developers", who are basically scripters (not > OO > developers), do the front end work. > > 2) There is just too much junk to write to do a simple form. The > samples I've > seen have involve too many files to do a simple form. Plus, why > should I have > to write a new bean for each form. Why can't the bean either be > generated > automatically or there be a general purpose bean (with properties that > are > created dynamically) that works for all forms? > > 3) We already separate business logic nicely, usually by encapsulating > the > logic in beans or EJBs. By the time the "application developers" get > to work > writing JSP/HTML, they are not writing any business logic. So why add > the > overhead of Struts (or any other framework)? > > 4) Because we separate out business logic into beans and EJBs, Java is > simply > used as a scripting langauge in our JSPs - in just the same way that > VBScript > is used in Active Server Pages. We try not to confuse the object > oriented > language called Java, with the scripting language called Java that we > use in > JSPs. We use a very small subset of Java in JSPs. > > 5) Based on #4, I don't particularly care for taglibs either. Again, > we are > simply using Java to do simple scripting. Loops are probably the most > complex > thing we do. So why add the extra overhead of taglibs. A loop is a > loop > whether it has the syntax of Java or a taglib. Plus, if I want my > front-end > developers to get any experience with serious development, I'd rather > have them > dealing with Java as opposed to taglibs, which have no value in the > real world > of programming. > > 6) Performance is unknown. I've looked through the mail archives and > have seen > requests for performance figures, but no answers (plenty of folks > pushing > Struts though). > > Mike > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- 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]
