It is wonderful to be misunderstood. Because struts does so much of the work a big chunk of what is left is the tags. I would compare it to the fit and finish of a car. How many car purchasing decisions are made because the driving is pleasurable or the color is correct.
I can understand the groups wanting to minimize the tags importance since you are comparing a non MVC situation to a situation with MVC. That is missing the point, since now you have a framework (many thanks to those who have spent the time putting it together). My point is that the tags should not be second class citizens. Yes you want to minimize and focus them so that the effort put into them is worthwhile. But we as a user community shouldn't have to rewrite the tags to make them useful to our projects or spend silly time triing to work through gaps in the usefullness. Anyway, I will stop swimming upstream. Edgar -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 12:56 AM To: 'Struts Users Mailing List' Subject: RE: future of struts 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
