On Tue, 15 Oct 2002, at 07:40 [+1000], Peter Donald ([EMAIL PROTECTED]) wrote:
> 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
Thanks for the ideas! I had forgotten about Netbeans, but have been
looking at Eclipse. Haven't started digging through the code yet.
Your EventBus idea is like what I was thinking but much more
elaborate... I originally started out with the Apache-webserver style of
hanlder that can take the event out of circulation, but never saw a case
that wanted the feature, and eventually yanked it. If you can recall
what prompted that feature in your code, and the heirarchical structure
you are describing, it would be a great help!
Regards,
Gary
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
