On Tue, 15 Oct 2002 05:47, Gary Shea wrote:
> Given the tendency of my clients to revise the UI, I want the units to
> be as independent as possible.  I have been looking for clean ways to
> package the units, and Avalon has of course come to mind.  A few issues
> come to mind.  One, packaging an MVC unit as a component could be a
> rather small scale for COP.  I don't have enough experience with Avalon
> to know in advance if this is a bad idea.  Issue two is IOC and app <-->
> UI communication.  When a button is pressed, an event is generated, and
> may be consumed in a variety of places in the heirarchy as well as in
> the app core.  Moving that event through component interfaces would
> violate IOC.  I'm thinking of an 'event service' component to address
> that issue.  Sort of a local communications backbone orthogonal to both
> the UI and the application core.  I recently realizd that I've done
> exactly this in a previous project, but with the CORBA Notification
> service!
>
> I'd appreciate any thoughts.

You may want to have a look at projects like Eclipse or Netbeans. From what I 
have heard both have "service kernels" to host services. These "Services" 
usually do UI specific things from Undo/State management to connection to 
underlying datasources.

The way I used to do things (and I say used to as I have since stopped doing 
most GUI work) is something like the following.

Define a hierarchial EventBusService. When an even occurs you place it on 
EventBus, if not handled (or not removed during handling) it will gradually 
percolate up the EventBus. Usually I had an "Application" EventBus as a 
parent of each "Form" EventBus.

Handing off each EventBus are various actions/handlers that consume events, 
use services to perform some behaviour and then update the UI (think of them 
in same way as Struts actions and you will get what I mean).

I would recomend that you only use Avalon/Framework to implement the services 
(possibly including the EventBus). None of the service "work" interfaces or 
should include reference to any Avalon specifics.

It *may* be possible to to process top-level UI elements (ie Frames and so 
forth) through an Avalon lifecycle but I am not sure it is such a good idea. 
It can cause code convolution and extreme confusion unless you are very 
rigourous about application (and no when to stop).I have seen something 
similar end in tears ;/

-- 
Cheers,

Peter Donald
 "Man's mind stretched to a new idea never goes back to its original 
dimensions." -Oliver Wendell Holmes 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to