avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: BlockListener and LifecycleHelper
Date Fri, 16 Nov 2001 23:00:04 GMT
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 ;)

A while back I sent a lick to an article on javaworld. 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)"

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 ;)

> 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 ;)

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)

contextualization I just don't see a need for. There is no acceptable usecase 
I can think of but I am sure if one was found I may change my mind.

> 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. 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 ;)

-- 
Cheers,

Pete

---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from 
magic is insufficiently advanced".
---------------------------------------------------------

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message