On Sat, 12 Jan 2002 14:23, Jose Alberto Fernandez wrote: > > Umm ... I have talked about this before - this wont be a problem if they > > extend AbstractTaskContainer because they will never be exposed to low > > level APIs. > > Well maybe I do not understand the code. Can you explain how this > simplifies doing whatever one wants to do with configuration? The code seem > to just provide the default Configurator and use it. But if that is the > case then why did I needed to implement Configurable in the first place?
I don't recall what the code looks like at this point in time but I have said that it will eventually look like something such as setAttribute( name, value ); addElement( name, value ); execTask( myTask ); etc. This should cover most of the normal stuff. I guess we could make AbstractTaskContainer implement configurable and then allow subclasses to get config tree via getConfiguration() - that would be less work to them and expose less complexity. -- Cheers, Pete --------------------------------------------------- "If you don't know where you want to go, we'll make sure you get taken." Microsoft ad slogan, translated into Japanese. --------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
