I'm sure the real brains will reply to this in more detail. Here's my 2 cents:
> 1) "Object explosion" for large sites--1-to-1 > mapping of URLs to objects can > lead to hundreds of small classes. It really bothers > me that Struts > encourages this kind of situation. Although the > DispatchAction helps a lot. I avoid the situation you describe by mapping multiple URLs to the same action and using the "parameter" attribute of the mapping to indicate the "command" that the Action will execute. This is basically a finite state model: <action path="/customer/add" type="CustomerAction" parameter="add"/> <action path="/customer/delete" type="CustomerAction" parameter="delete"/> Then I just use a if/switch logic to do the right thing. However if you do this to extremes, you end up with one big action and no OO design. Maintaining "high cohesion" is the key. > 2) Meaningless method signatures, like > execute(Mapping, Form, Request, > Response). All the methods look the same, regardless > of what data they're > actually expecting. This often makes it necessary to > go into the Java code > just to figure out what data a method uses. Not to > mention losing > compile-time type checking. I fear you're making a big deal over nothing here. The only real thing that you lose type checking on is the Form. It does kind of suck that you have to know what specific form to cast to. But, it's not that big a deal, IMHO. I suppose Struts is like any other framework I've ever used. It has it's share of shortcomings, but it beats the pants off writing it myself :-) Dave __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
