Peter Donald wrote: > Sent: Monday, 12 November, 2001 08:02 > To: Avalon Developers List > Subject: Re: BlockListener and LifecycleHelper > > > Hi, > > On Sun, 11 Nov 2001 18:36, 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. > So it should not under any circumstances have any real logic > included in it. BlockListener provides a clean mechanism for extension of Phoenix. 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). > 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. > I just updated the documentation to include a blurb about block > listeners (see what-is-a-block-listener.xml). See if that makes > it clearer and if you agree. The definition in what-is-a-block-listener.xml describes a scenario where a particular "block" is using the information about available blocks within an application instance as the principal arguments. In that example, the notion of "no real logic" makes sence. However, my scenario (an extension to Phoenix application management) also meets the description in the BlockListener is a "component" (and according to the Avalon "what-is-a-component.xml", a component has a managed lifecycle which is exactly the point that I'm addressing. > I am still not sure about the wisdom of allowing listeners to be > configured but I really don't think listeners should be contextualized or > initialized. If you think about the listener as an extension to the Phoenix/sar context, the listener should be treated as a component (i.e. a component that can have a logger assigned, can receive context, can be configured and initalized. I think this comes down to the question of handling Phoenix extension - how can Phoenix functionality be extended in a way that is orthogonal to the question of blocks. Cheers, Steve. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
