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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
