Its sad just how many people seem to have the confusion that struts is just a bunch of taglibs, and spend forever asking what cool dhtml UI widgets it provides and wondering what all the fuss is about when they find it doesnt...
Ive found struts absolutely invaluable in my project, but I personally consider JSP to be the spawn of satan and dont use so much as a single JSP for my actual rendering... (Im using a homebaked xhtml DOM rendering approach) If I wanted to change the view technology I use, I could in theory just change the local forwards in my actions (for example to point to JSP pages) and leave the actions themselves unchanged. (In practice it wouldn't work too well because I took a few naughty shortcuts when I was just starting the project but thats my fault and is an 'implementation' issue rather than a 'design' one!...) If it wasnt for struts Id have been pretty lost. It would take a month of Sundays to reimplement all the struts (& commons) features I do use (ActionServlet, RequestProcessor, Actions, ActionErrors, File Upload & Multipart form parsing, Digester, Logging, BeanUtils, etc...) and of course the support struts users get on this mailing list... :-) -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 08:29 To: [EMAIL PROTECTED] Subject: RE: future of struts edgar writes: >Unfortunately, an innordinately large percentage of development >time is spent with the tag library, as even a casual perusal >of this list reveals. I think that's mostly about not understanding how to develop with tags, especially in a Model 2 architecture. It's a very different approach than developing an app with Model 1 and scriplets. Much of the problem, I think, is that people try to put old wine into new bottles. I did some work in Cold Fusion before Struts, so the tag and tool approaches seemed quite natural to me. I've also written applications in so many environments now, that I've long started to see the database as one thing and the presentation as another. So Model 2 came naturally tool. IMHO, what helps the most is drawing a firmer contrast between the Struts Core and the rest of the presentation layer. The Struts tags are one example of how to expose the Struts framework core to the presentation page. Struts-el, stxx, the Velocity View tools, and the (upcoming) struts-faces, are other ways of exposing the core framework components to the presentation page. Properly designed, you should be able to use your Struts controller with any these presentation layers. Where I think people run into problems is that they try to do controller things in the presentation page and presentation things in the controller. Like Vic said, if you are having trouble doing some thing "with" the tags, it's usually because you are doing too little with the controller. In a MVC/Model 2 application, the presentation page should be a glorified mail merge job. It shouldn't "do" anything but output what the controller has given it to output. In the future, there will be more Struts appplication using even more presentation layers, the Struts tags, the EL tags, the JSF tags, the Velocity View tools, XLST, Jelly, and whatever else we think of next =:0) But behind all this chrome, there can still be the same core framework holding all the pieces together. -Ted. -- 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]>
