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). So it should not under any circumstances have any real logic included in it. The Blocks should contain the logic. The Listener is just there to link the "client" blocks with the "server" block. 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. 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. LogEnabled may be an option though .. not sure. thoughts? -- Cheers, Pete --------------------------------------------------------------- The difference between genius, and stupidity? Genius has limits --------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
