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 :-)
> A while back I sent a lick to an article on javaworld.
I bet that was a suprise for the Editor :-)
> The articule basically discussed the separation between
> "procedural" and "declarative" parts of a system. Can't seem
> to find think at the moment ...
>
> Blocks are definetly the procedural part of the system. They do things.
>
> I see listeners as the delacarative part. Essentially they manage
> rules such
> as
>
> * "All SOAPable Blocks are exported via a SOAPServer Block"
> * "All Blocks are managed by MyManager Block"
> * "All Persistable Blocks are persisted by MyPersistentManager Block"
> * "All RMIEnabled Blocks are exported by MyRMIExporter Block"
> * "All Repository Blocks are registered with all Store Blocks"
> * "All ... Blocks are ... by ... Block(s)"
What your decribing here is "one-potential-set-of-semantic" that a
listener may have. That set of semantics is much more fine-grained
than the listener interface itself. It is also a set of semantics
that has nothing to do with my application case.
> 1-to-1 listeners may also be viable and this is essentially the
> reason why I allow Configuration for Listeners.
>
> So Listeners still == Gaffer tape for Blocks ;)
For your use-case, not mine!
> > I objected to that
> > because I have "application" level logic that does not belong
> > in a block - it belongs in the listener. I think we both
> > agree that when logic is exposed to blocks, this done through
> > a block acting as a proxy to the listener.
>
> no - I definetly dont agree with that ;)
I'm not going to explore this one.
> Blocks provide the logic and may interact/provide services to
> other blocks.
> Listeners are only enablers of block interaction.
>
> > What we apparently
> > don't agree on is allowing a listener to be a component (i.e.
> > has a lifecycle covering contextualization, composition,
> > initialization, dispose, etc.
>
> 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
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). 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.
There are alternative such as extending the embeddor but this
means creating a different Phoenix which I want to avoid.
Configurable - I'm holding my application policy here.
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.
Disposable - arguments are the same as initalize.
> > 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
> 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.
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.
Cheers, Steve.
> --
> Cheers,
>
> Pete
>
> ---------------------------------------------------------
> Clarke's Third Law: "Any technology distinguishable from
> magic is insufficiently advanced".
> ---------------------------------------------------------
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
