> > * Clear interface for people configuring xwork. Let's say I > > get this OSS package from the net that uses webwork and I'd > > like to use it in my project. A clear marker would again > > make it easy for me to integrate 3rd party packages b/c I > > know what to look for. > > This is a documentation issue, IMHO.
I don't agree here. A system, where reasonable, should try to be self documenting so developers don't have to spend a lot of time recreating the wheel. > How about if I implement the CommandDriven pattern as a core part of > Xwork, then we can take a look at it and see where to go from there. Go fer it ;) > Yes, I'm arguing for multiple entry points. But I'm not sure why we have > to limit what those entry points can be called? I agree and think multiple entry points would be useful. While I would prefer to limit the entry point names (a la JavaBean set/get, JUnit test, and EJB create), I'm not dead set on it. However, I do feel like it would be useful to have a entry point search path that includes a prefix. Another plus for prefixes means that tools could be written that take advantage of the convention. Cheers! -- Matt Ho Principal Indigo Egg, Inc. http://www.indigoegg.com/ ------------------------------------------------------- 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
