You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2005/09/17 07:19:42 UTC
DO NOT REPLY [Bug 36439] -
[shale] Allow user to supply their own Dialog DTD
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 craig.mcclanahan@sun.com 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org