On 12.02.2006 21:18:56 Andreas L Delmelle wrote:
> On Feb 8, 2006, at 22:03, Simon Pepping wrote:
> 
> Simon / Jeremias,
> 
> >
> > 6. D5 (The FOUserAgent can return the FopFactory instance. (needed
> >    internally by FOP)): Why? Because FOUserAgent is the programmed way
> >    to get at configuration settings? Could it be better to implement
> >    get methods on the user agent which get the settings from the
> >    factory object (factory object not exposed)? Or even pass the
> >    factory object instead of the user agent (Cf. question 2)?
> 
> I agree with this comment in particular. I'd prefer to not expose the  
> Factory, but implement accessors for the persistent settings. It even  
> allows for a sort of flexibility where it comes to the so-called  
> persistent data across multiple rendering runs...?
> A bit unclear maybe, so some further explanation: I'm also thinking  
> in terms of on-demand loading of certain data, if requested so by the  
> user agent. Once it's loaded, it will be readily available for  
> another user agent. If no user agent ever requests it, it will never  
> be loaded into memory.

Uhm, I can't follow you here. I understand that you prefer that all
rendering-run-level and environment-level info is accessed directly
by methods on the FOUserAgent, whereas I proposed to access the
environment-level data only on the factory to have a clear distinction
between the two levels. But: What data is loaded on-demand and requested
by the user agent?

> If the factory would be exposed, and a lot of classes access it  
> directly, the implied amount of checks whether certain features have  
> already been loaded would be enormous. If this is centralized in the  
> user agent, it becomes a lot easier to maintain.

I don't see any of that. I decided that I will implement my proposal in
a new branch. There, everyone can have a look at the real thing and
we'll adjust as necessary to make everyone happy. You'll see that the
whole thing is much less complicated than you might think. When
everybody's happy, we can merge back or, in the worst case, discard the
branch.

Jeremias Maerki

Reply via email to