> On Wed, 2002-05-29 at 17:18, Jeremias Maerki wrote:
> > > - Configurable FOUserAgent (have default FOUserAgent that can be
> > > used/extended without config)
> > > To make it possible to setup all the various options like dpi.
> > 
> > I'm still at a lack of knowledge on these new things. :-( But it sounds
> > reasonable. I think a lot of thinking when using Avalon goes into which
> > classes are components (they get a logger, configuration etc. and
> > provide some sort of service) and which are merely data-holding classes
> > like an InlineArea. Correct me if I'm wrong: UserAgents are those
> > classes that do the heavy work that was formerly distributed in many
> > different classes directly on classes that change into simple
> > data-holding classes at the moment.
> That is essentially it.
> The FOUserAgent holds a bunch of decision making values that people may
> want to change.

:-) Cool.

> > > The image cache and other cache are similar. These can be set with a
> > > static method and through the driver respectively.
> > 
> > I'd like to avoid the static stuff, if possible. There's the concept of
> > a ComponentManager (or after an evoluntionary step the ServiceManager),
> > which allows components to look up services provided by the
> > container/parent. There are multiple implementations in Avalon:
> > ExcaliburComponentManager (ECM), Fortress, Merlin, Phoenix. Using this
> > mechanism forces us to think again about some interfaces, or helps us to
> > easily provide multiple implementations of the same interface.
> I see what you mean. Maybe this could do with a bit more thought.
> I was thinking that there are two scenarios, the common cache for all
> images and the context cache for instances of rendering.
> With a situation such as cocoon we could have a third based on the
> cocoon context and this may be more easily handled within the component
> manager. Everything else should remain the same I think.

Sounds good. To keep up I would really have to dive in. Too bad.


> Any help is much appreciated.
> I just want to get the ball rolling with the intentions.
> We should be able to tackle this in parts.

Yes, absolutely. I'm sure we can get more Avalon stuff in when the time
is right. Going with Logger/LogEnabled and Configuration/Configurable
for now is good enough. I'd just like to say that it's already half the
way if stuff gets split up into interface and implementation. This makes
one think more about exchanging implementations and helps a lot when
moving in more of Avalon.

By the way: There's also some new CascadingConfiguration class in
Excalibur that enables overloading of values. This may help with overall
configuration, too.

Jeremias Märki


Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to