On Saturday 01 May 2004 22:19, [EMAIL PROTECTED] wrote: > it was a very good system you brought up, but hte problem is that we do not > have control over the listener interface.
Huh?? Just create what you need. If you want to keep existing listener interfaces, and have intermediary components, nothing would stop you from that. The suggested listener interface was 'generic'. The Provider can always forward the Event from the Device to the 'SoftKey' (in my example), which keeps the registration of listeners, and the 'SoftKey' fire the events. > We are using the J/Xfs spec for > our hardware drivers and wrap the devices with a very thin layer just to be > able to introduce some decoupling later on. However, these wrappers have > method getDevice() that returns the J/Xfs driver device directly in order > to be able to do finegrained configuration for e.g. the state machine > component. Sorry, but I fail to see why that would be relevant. Don't look at underlying implementations when deciding how to do the right thing, which should be straight forward, decoupled and easy to understand. > The question - is it possible to do this with several providers for the > same stage? That would probably provide the flexibility we need and we can > scrap our HardwareManager that all HardwareWrappers register in since alla > interested parties have references anyway this way. Doesn't sound like the proper way to go. But it is your choice. Typically, I find LifeCycleExtensions somewhat less useful than they initially seem, and coupling the whole system with them, triggers the Gut to say "Nahhh".... > Is there a way to enable/choose/disable several extension providers for the > same extension? In runtime? That would be for the extension not to do anything, I guess. > What do you think? As I said, I fail to understand why you are trying to make it more complex than it has to be... Introduction of 'thicker' wrappers and intermediary components is probably far superior than the introduction of LifeCycleExtensions. Maybe you have been too locked into a particular way of how you think it should be done, and that I plainly disagree that this is the best way forward. You have to be the judge of that. Niclas -- +---------//-------------------+ | http://www.bali.ac | | http://niclas.hedhman.org | +------//----------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
