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=36439>. 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=36439 ------- Additional Comments From [EMAIL PROTECTED] 2005-09-17 07:19 ------- Thinking about this more, I'd actually rather *not* extend Shale in this particular direction. It adds the potential for destabilizing or potentially incompatible changes to the functionality that Shale itself supports, if the custom DTD was not a proper superset of the standard DTD. It would also seriously complexify the ability of tools to support generation of appropriate dialog-config.xml resources. I'm also concerned about embedding too much, or too inappropriate, information inside the dialog configuration resources. Alternatives that make more sense to me include: (1) Context initialization parameter to turn off validation when parsing dialog-config.xml files (but the default would still be to have it turned on) (2) Support a nested <property name="foo" value="bar"/> element inside all the configuration elements to allow setting arbitrary properties of a custom implementation class specified by a className attribute. (3) Remain hard nosed and say "if you want to create dialog configuration instances with customized properties, provide your own mechanism to set up the dialog configuration instances". What do you think? -- 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]
