DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34865>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34865 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2005-05-28 03:51 ------- I don't believe we should make the functionality of the dialog management process dependent upon any configuration file ordering, for several reasons: * It is much harder for developers to understand what will actually happen when there's lots of "magic" in the world. The proposed example is a classic use case for this -- how in the WORLD is any newcomer to the technology going to understand all the implicit transition definitions? * Implicit behavior tied to a particular configuration file format doesn't work when someone configures their Dialog beans through some means other than reading the XML file format we support by default. * Lots of magic behavior also makes it very difficult for tools to provide a high quality design time user experience. One of my goals is that such an experience be straightforward for tools supporting Shale to create. * I am not a believer that minimizing the number of characters in a configuration file equates to a technology that is easier to use. That being said, the use of XML entities can address at least 80% of the "make the developer type less stuff" goal -- and the goals that inheritance would provide as well -- with zero changes to the existing functionality. One of the key success factors for Struts 1.x was the fact that it had a well defined configuration file format that was very simple to manipulate. Yes, it can be a pain to build such things by hand (although I've seen some monstrous sized Struts based applications that do that) -- but, even there, intelligent use of XML entities can bury problems of reuse inside the XML parser. I want to see whatever configuration file format we adopt as a standard be very clean and easy to read, as well as easy for either tools or people to create. I'm going to be adamant, however, that runtime functionality should not be dependent on anything as fragile as ordering of XML elements in a document -- for the same reason that well designed JavaBeans components should not care about the order in which their setter methods are called. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
