You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Sean Schofield <se...@gmail.com> on 2005/07/13 15:39:39 UTC
[shale] Suggestion to improve dialog
Craig,
I've been playing with the dialog stuff for some time by now. Its
working quite well and the design is such that I can customize most of
what I need using the Action State. There is one thing that I need to
extend DialogImpl for though and the current code makes that
difficult.
I suggest modifying ConfigurationInit to make this easier.
Step 1.)
Make the REGISTRATIONS[] field protected so that a subclass can
specify its own DTD. Even better would be to make it setable through
an attribute in <dialog>. Making it setable combined with Step 2.
would mean that I wouldn't even have to subclass Configuration Init.
Step 2.)
Allow user to specify a (optional) classname attribute for <dialog>.
Default can be DialogImpl but I'd like to create my own class without
duplicating all of the digester code in a subclass. The existing
"addSetProperties" will automatically set the new properties I'm
adding to my custom Dialog class.
I can provide a patch if you're interested.
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Suggestion to improve dialog
Posted by Sean Schofield <se...@gmail.com>.
A refinement to my earlier suggestions...
Forget making the REGISTRATIONS[] field protected. I'm ok with
skipping the DTD and I noticed that you have the class as final
anyways.
I still would like to see a object creation rule that would create the
dialog based on classname. I have a patch if you are interested.
sean
On 7/13/05, Sean Schofield <se...@gmail.com> wrote:
> Craig,
>
> I've been playing with the dialog stuff for some time by now. Its
> working quite well and the design is such that I can customize most of
> what I need using the Action State. There is one thing that I need to
> extend DialogImpl for though and the current code makes that
> difficult.
>
> I suggest modifying ConfigurationInit to make this easier.
>
> Step 1.)
>
> Make the REGISTRATIONS[] field protected so that a subclass can
> specify its own DTD. Even better would be to make it setable through
> an attribute in <dialog>. Making it setable combined with Step 2.
> would mean that I wouldn't even have to subclass Configuration Init.
>
> Step 2.)
>
> Allow user to specify a (optional) classname attribute for <dialog>.
> Default can be DialogImpl but I'd like to create my own class without
> duplicating all of the digester code in a subclass. The existing
> "addSetProperties" will automatically set the new properties I'm
> adding to my custom Dialog class.
>
> I can provide a patch if you're interested.
>
> sean
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org