+20 :-) This is exactly my point about CommandDriven. The separate class per execute method sounds like the correct way to do things from a pure Command Pattern standpoint, but it's just not practical.
Jason > -----Original Message----- > From: James Cook [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 21, 2003 7:44 AM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Proposal: Removing the Action Interface > > > I think the comments are very valid from a theoretical pov, > and I was opposed to the Command-driven pattern as a means of > convenience. However, as our project progressed, the number > of classes increased tremendously because of the inheritence > model for shared data. The structure made it difficult for > all the team members to easily grasp, and the maintenance of > the project was becoming difficult. > > I see this as one of the many situations where cs theory is > counter-productive to the practical needs of the software developer. > > The command-driven actions proved to be very convenient and > useful for simplifying our models. We have no lack of > security control, it just resides programatically in our > actions. If this was implemented via interceptors, the > configuration should be able to easily be applied to > command-driven methods as well. However, I view declarative > security as another of those theory vs. practicality issues. ;-) > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On > Behalf Of > > Aleksandar Seovic > > Sent: Thursday, February 20, 2003 9:52 PM > > > I've been following this list for a while now and I really > like most > > of the stuff I've seen. However, I don't believe that removal of > > Action interface is a move in the right direction, for several > > reasons. > > > <snip> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an > edge. The most comprehensive and flexible code editor you can > use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE > 30-Day Trial. www.slickedit.com/sourceforge > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
