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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
