GUIApp (was Re: Honest Opinion, Take it for what its worth)

[Berin Loritsch <bl...@d-haven.org>]

Alex Karasulu wrote:

> BTW I wound up using Merlin and my copy of the event bus instead because of 
> time constraints to build a GUI.  I really wanted the custom lifecycle you 
> have to snap in a component onto the event bus.  I would like to see these 
> kinds of features made as pluggable aspects to Merlin.  The GUI app stuff 
> seemed a little too new and complex for me or at least too complex for me 
> to understand within a couple of hours.  But I do intend to focus more on
> it in the near future: I have not given up.  There are some excellent 
> concepts there for those that want to make their GUI components real 
> components in the Avalon sense.

The most complex part of GUIApp is really the config file.  It doesn't map
logically to the way a Swing GUI person would think.  That is enforced somewhat
due to the way Fortress reads in the configuration, so I am thinking about how
to improve that in the future.  But specifics about GUIApp belong on the d-haven
list.

What is relevant to Avalon though is that more and more the configuration file
formats lend a great deal to the perceived complexity of the containers.  As
LSD has been good to point out, too much magic is not good.  Sylvain put it best
as "Too much magic spoils the confidence".  If you can't readily see how
something maps at a glance, you tend not to trust it.

Perhaps a lesson for moving forward...


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

RE: GUIApp (was Re: Honest Opinion, Take it for what its worth)

[Alex Karasulu <ao...@bellsouth.net>]

> What is relevant to Avalon though is that more and more the configuration
> file
> formats lend a great deal to the perceived complexity of the containers.
> As
> LSD has been good to point out, too much magic is not good.  Sylvain put
> it best
> as "Too much magic spoils the confidence".  If you can't readily see how
> something maps at a glance, you tend not to trust it.
> 
> Perhaps a lesson for moving forward...

Noted this is another area where we can re-factor in simplification.  But
the complexity to configurations you speak about has to do with where a
container keeps it right because the content of the config is essentially
determined by a component.  The nature of the component determines the
perceived complexity of the configuration.  Take the data source component
whose config looks messy and complex verses the thread manager component.
One looks more complex than the other.

However again I think you were referring to how the container deals with the
placement and handling of configurations.  

We need to capture all this in one place to make a good list of areas of
potential improvement.

Alex



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