Now I feel like I have to reply to anyone that falls on the side of IDEs and tools :) I really don't have to, but I'm an a***ole like that :)
You, and Brian as well, certainly make fair points. It is certainly fair as well though to say that different people learn better in different ways. I for one don't feel like I have a degree of comfort with a new technology until I've really gone into at as close to the lowest possible level and messed around. For instance, although I had build a number of Struts-based applications, at least two of which would be considered large and complex by most people, and while those experiences allowed me to become a recognized expert in Struts here at work, I didn't really feel like I knew what was going on until I did my Struts Web Services project because only then did I really tear into it and really try to understand why everything was the way it was. That being said, there are plenty of people out there who will never get into it to that degree and yet will still be perfectly capable Struts developers, even exceptionally good Struts developers (and certainly many of them better than me!) As I said to Brian, I think the middle ground here is to say that using any tool for Struts or anything else can be a big helper, whether in the beginning when learning and certainly later on when you know more, AS LONG AS you don't allow the tool to do all the work for you. It's when the tool says "ok, struts-config.xml had problem X and Y, and I've corrected them" and you say "ok, great!" without understanding what the problem was, why it was a problem and how it was resolved. That's the mindset I would stress people not fall into, and I suspect no one here would disagree. I think it's fair to say that can only happen with IDEs and tools... -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, February 11, 2005 12:30 pm, Duncan Mills said: > To play the other side of the argument, with all due respect to Frank) > I'm a whole hearted supporter of IDE tools for Struts like Exadel or > Oracle JDeveloper > <http://www.oracle.com/technology/products/jdev/index.html>. For > several reasons: > 1) My team builds one - so I'll declare an interest there > 2) Diagrammers & IDEs can give you a real kick start to learning the > absolute basics of Struts, there's nothing more frustrating than failing > to get a simple two-page flow working simply because you've made an > error in the web.xml, or your editor doesn't validate the Struts config > against the DTD. People get put off before they've even got started. > However, the big BUT here, is that the tool must help you, but not get > in your way. If you want to hack the XML then it better let you do so. > 3) I actually feel that page flow diagrams are a useful tool, both for > documentation and for requirements gathering. > 4) A good way to learn is to draw and then see what the tool has done > for you. > > This all being said, an IDE can really only help you with the basics of > Action mappings and configurations. So you're going to have to get dirty > at some point although I'd probably stop at downloading the Struts > source and not reach for my copy of Peter Norton's Guide to x86 > Assembler :-) > The real fun comes later with that pesky data, but that's a whole > separate topic. > My 2p > > Regards > > Duncan Mills > www.groundside.com/blog > > > > Frank W. Zammetti (MLists) wrote: > >>To answer your question, no, I haven't used it. But, since you are new >> to >>Struts, I'd actually caution against using such a tool. >> >>As a general rule, I believe it is better to do things manually by hand >>when you are new to them. I think you will get a better understanding of >>how everything works that way. Then, later on, you can use the tools >> that >>make the more mundane tasks easier and quicker. >> >>I've always felt that the best developers I've ever known, by and large, >>were better at least in part because they knew Assembly to some degree >>(even if they haven't actually coded in Assembly for a long time, like >>me). I think it helps you when you start working at a high level to know >>what's going on "under the covers", to at least some degree. There are >> of >>course plenty of exceptions everyone could point out to this, but I >>generally feel this is true. The same holds true for IDEs and code >>generators and any tool that takes some of the coding work away from you. >> >>Just one man's opinion anyway. >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
