> I think it brings more problems than it solves. That's a pretty ignorant statement. Why would you say such a thing? How many people or projects are using Tiles (whether successfully or not)? How could you possibly know? So how could you know how many problems it brings?
With any product or feature of any software, the more popular something is, the more visibility (and critics) it generally has. Look at Validator. It has many critics and many enthusiasts. I have used Tiles on many projects, and despite the slight extra memory consumption, the pros far outweigh the cons. Just because some feature of some product is complex (and maybe poorly documented) does not mean "it brings more problems than it solves". If you don't like the way something is, change it. If enough people like your changes, submit them and they will likely be committed. But comments like these do not help in making anything better. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx ----- Original Message ----- From: "Tuncay Baskan" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, September 21, 2004 8:05 AM Subject: Re: Struts Bloat: Framework > On Mon, 20 Sep 2004 20:30:46 -0400, Rick Reumann <[EMAIL PROTECTED]> wrote: > > Michael McGrady wrote the following on 9/20/2004 7:52 PM: > > > > > I have a real concern that Struts is going to continue to be bloated > > > with what are not Struts, not part of the framework, but what are > > > instead really very useful uses of Struts. DispatchAction and its > > > progeny are just one example of this. > > > > I would disagree with some of this. Since a DispatchAction can't really > > stand on its own (unlike the commons packages do) I really think it > > belongs part of Struts. I don't see any reason not to give people the > > options from within the framework (I no longer like to use DynaForms but > > I'm not really opposed to them being an option). On top of this, if I > > was new developer I would be quite frustrated if I had to go find a ton > > of optional packages just to accomplish some common/useful things. I > > actually don't really find Struts that bloated. The jar isn't that big, > > so I'm confused what the concern is? What is it that you find being > > introduced that is currently bloating struts? Over the past 2(maybe > > more?) years there haven't even been that many 'major' changes to Struts > > (a nice bunch of improvements but no major bloat that I can see). > > > > -- > > Rick > > I *strongly* agree with Rick on DispatchAction.. Especially from the > "new developer"s perspective, Rick's words are quite right. > org.apache.struts.actions package contains only a handul of classes > which are *required* in my opinion. > > I think the only package can be considered as bloat is the tiles > package. It should not be in the default package, it can stand on its > own and there are many alternatives. Also, from the number of messages > about tiles in this list, I think it brings more problems than it > solves. I have to say that I only tried it once and hated. > > /tb. > > --------------------------------------------------------------------- > 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]
