On Tue, 13 Nov 2001 04:52, Stephen McConnell wrote: > > > After playing around with the Phoenix BlockListener I decided > > > to transfer our human interface centric block implementation > > > to a block listener instance. The resulting code is much > > > cleaner - however - I found some limitations with the way > > > LifecycleHelper handles listener instances. Under the CVS > > > LifecycleHelper implementation the only component phase > > > handled by the helper is to configure the listener. I want > > > my listener to be log enabled, contextualized, configured, > > > and initalized. So, I have updated LifecycleHelper to do > > > exactly that by changing the startupListener method. > > > I though it would be worthwhile adding the updated version > > > to the CVS (source attached). > > > > Im not sure you are using the BlockListener in the way that I > > intended it to be used ;) Basically the purpose of a > > BlockListener in my mind is to act as an enabler for > > relationships between blocks (besides a dependency > > relationship). > > I'm looking at BlockListener as open mechanisms (open in the sence > that it declared in assembly.xml) though which I can plug a component > that monitors the starting up and shutting down of any block > installed in a particular sar.
right. > > So it should not under any circumstances have any real logic > > included in it. > > BlockListener provides a clean mechanism for extension of > Phoenix. agreed. BlockListeners were intended to provide all those features that are not general enough to be kernel services - like BlockPersistence, exporting via RMI/SOAP/Other, exporting via a Management system or whatever. > While this may not have been the intent - (a) such a > mechanism is needed, and (b) the "no real logic" principal your > noted seems to be relevant to the use case you had in mind (i.e. > handling inter-working of blocks). still think it is ;) > > The Blocks should contain the logic. The Listener is just there > > to link the "client" blocks with the "server" block. > > In my case, the functions I am implementing under the listener is > not a block - it is a component that extends the functionality > of the Phoenix platform. Right. But the question is - could it be a Block? I mean - what would be the negative side of making it a Block and having other Blocks "registered" with management system. The registration (and unregistration) would be done via the BlockListener. Making this .sar wide service a Block has the advantage that other Blocks may choose to depend on it. If the only differences between BlockListener and Block are; * listeners get events about other blocks * blocks can have dependency relationships then I don't see an advantage of making a distinction between the two. -- Cheers, Pete "Artists can color the sky red because they know it's blue. Those of us who aren't artists must color things the way they really are or people might think we're stupid." -- Jules Feiffer -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
