Listeners can now receive Loggers. I will look into exposing the other events and their parameters a bit later on - maybe Monday night. If I forget - prod me ;)
On Thu, 10 Jan 2002 22:19, Stephen McConnell wrote: > Peter Donald wrote: > [on BlockListener] > > > Stephen do you recall when that was or have a pointer into the archives ? > > Pete: > > Here is your email to me which I have not yet replied to. > (I was swamped by external events at the time and need to get > my head back around this stuff - but not right now - other things > that I have to deal with just at the moment). > > Steve. > > ===================================================================== > > > -----Original Message----- > > From: Peter Donald [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, 18 November, 2001 02:23 > > To: Avalon Developers List > > Subject: Re: BlockListener and LifecycleHelper > > > > On Sun, 18 Nov 2001 00:27, Stephen McConnell wrote: > > > Peter Donald wrote: > > > > On Sat, 17 Nov 2001 00:16, Stephen McConnell wrote: > > > > > I want LifecycleHelper to invoke component lifecycle phases > > > > > on a listener. > > > > > > > > right. I don't mind LogEnabled but I don't like any of the others ;) > > > > > > > > > You objected to this because you said that > > > > > listener logic should reside in a block. > > > > > > > > I said there was no such thing as listener logic. Listeners are > > > > just glue to stick together blocks appropriately ;) > > > > > > And I said that happended to by your use-case, not mine :-) > > > > Right but the functionality you want to implement is already > > supported. My > > use-case was designed for application wide aspects / policy / > > facilities / > > whatever. So far you have yet to say where this model breaks down in your > > case. You just said it does. I need facts not opinions ;) > > > > So what is missing from the model I propose that would; > > * degrade quality of implementation/design > > * make it impossible to implement some functionality > > etc > > > > The only thing I have considered is maybe that not enough events are > > supported. It may be useful to support other events such as > > > > void applicationStarting() //before blocks are startedup > > void applicationStarted() //when all blocks are started up > > void applicationStopping() //before blocks are shutdown > > void applicationStopped() //when all blocks are shutdown > > void applicationFailure() //when application fails to load > > > > It is possible that the above may be useful to add ... not sure aty this > > stage. (or at minimum the appStarted + appStopping) > > > > > > coposition can't be done as there is no notion of dependencies. > > > > initialization shouldn't really be done as no listener should be > > > > allocating any significant resources (same reason for KB'ing > > > > dispose) > > > > > > Agree - I should not have included compose (my mistake). Let me > > > outline the "component" interface that I want to see support > > > for and the reasons why: > > > > > > LogEnabled - If I'm logging anything within an object that's > > > declared as a listener, I don't want to have to set-up > > > another logger - just want to be supplied automagically > > > > reasonable. > > > > > Contextualizable - this one is a little tricky - the code > > > I have is doing validation of the environment before blocks > > > kick in - validation needs the information about the > > > application context (available under the application meta-data > > > receivable under contextualization of a listener). > > > > hmmm - is this a local modification? The only thing you can get from > > BlockContext as far as I see is the Application name and application dir. > > Have you modified it locally to get other stuff? > > [yep - its a local modification - sorry about that] > > > > To veto > > > start-up, I need to be in application space (no block space) > > > because I can throw an exception and halt/suspend start-up. > > > > Would adding notification of the events mentioned above work for this? > > > > > Initializable - Because I'm following Avalon component > > > pattern and this is the trigger to start working and I don't > > > like changing that without having some tangible > > > justification. > > > > I need to know what "work" you are doing before I can judge whether it is > > something we want to support ;) > > > > > > > I need to understand why your objecting to that. > > > > > > > > Put it this way. I see listeners as not doing any logic - they are > > > > declarative constructs for establishing relationships. I want > > > > to know why > > > > > > this will not work in your case. > > > > > > 1. because I am NOT wiring blocks together > > > 2. because I don't have an alternative mechanism > > > 3. because I object to assertion that the current listener declaration > > > is a valid "declarative constructs for establishing relationships" > > > (it only references a class name within the scope of the application > > > and declares nothing about relationships) > > > 4. because I'm dealing with application policy > > > 5. because I'm stubborn and you haven't given me a good tangible > > > technical argument why this is inappropriate > > > 6. because I wanted to have a least six bullet points > > > > ;P > > > > > > So far you have only indicated that you > > > > "want" to do logic in listeners. I want to know why the listeners as > > > > declaratives model doesn't work in your case or makes it harder > > > > to construct your application. So far I haven't seen any > > > > indication that > > > > > > this is so ;) > > > > > > I'm handling application level policy. The registration of a listener > > > is the only access point I have to plug-in an application-level > > > > facility. > > > > right. > > > > > This > > > is a different use-case to yours - but that does not make it > > > > invalid - just > > > > > different. All I'm proposing is that IF a class, registered as > > > > a listener, > > > > > exposes any of the above component interfaces, then, give the > > > > class what it > > > > > needs to do its stuff correctly. > > > > You still haven't really told me exactly what you want to do and why the > > current model doesn't work for you. If LogEnabled was supported and some > > extra events were added (like above) would you be able to > > implement what you > > want to implement? > > > > -- > > Cheers, > > > > Pete -- Cheers, Pete -------------------------------- These aren't the droids you're looking for. Move along. -------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
