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? > 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 *------------------------------------------------------* | "Common sense is the collection of prejudices | | acquired by age 18. " -Albert Einstein | *------------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
