On Sun, May 09, 2004 at 11:52:31AM -0400, Glen Mazza wrote:
> Joerg I believe just recommended storing the user configuration in 
> FOUserAgent, which is already getting passed around everywhere.  Using 
> my favorite design pattern, Moving Part Reduction, I also think it would 
> be ideal if we could place all of this in FOUserAgent.  (I also suspect 
> that much of what will be in FOUserAgent/User configuration will be 
> variable over time, which may also suggest we keep this all in one 
> class.)  BTW, what other things besides hyphenation needs to go into 
> user configuration/fo user agent, say for 1.0? 

I like Joerg's idea of a Global Context object. It seems to have a
wider scope than FOUserAgent. An FOUserAgent object could be part of

>From the maintenance code's configuration it would need to have
baseDir, fontBaseDir, hyphenation-dir and strokeSVGText. Font
information per renderer has already been implemented; only the pdf
renderer really uses it. PDF filter lists have also been implemented
in the pdf renderer.
> Two more observations:
> 1.)  What does the team think of placing all the FOUserAgent information 
> into the abstract apps.InputHandler class by either (a) full 
> incorporation (i.e., getting rid of FOUserAgent and moving everything in 
> it to InputHandler), or (b) including an FOUserAgent instance variable 
> in apps.InputHandler, or (c) having InputHandler extend FOUserAgent? 
> Then, we would just pass InputHandler around instead of FOUserAgent.  I 
> mention this because InputHandler includes the file name information 
> already, that is sometimes good to have at various parts of the pipeline 
> (for example, error messages or AWTRenderer, whose refresh capability 
> requires knowing the input source file names.)
> I'm not sure of the value of this idea, but am just bringing it up for 
> others to comment.

I would prefer input file information in the Global Context
object. InputHandler has more information than needed elsewhere in the
> 2.)  For the fop.image package, and future packages which have a high 
> chance of being used for transcoder or other non-FOP purposes, I'd like 
> us to factor out the FOUserAgent.  We had a small problem a few months 
> back when Thomas DeWeese was updating our fop.image package for the 
> transcoder and had trouble trying to figure out how to create an 
> FOUserAgent in order to supply a method parameter.  (Turned out only a 
> logger within FOUserAgent was being used, so I changed the method 
> signature to just require that.) 
> More generally, explicitly send in the needed values from FOUserAgent 
> into the called package (eliminating the need for other callees to 
> create an FOUserAgent instance), or, for those packages which require 
> lots of variables in order to be properly initialized, create the 
> collection class (i.e., like a "ImageUserAgent") in that package, not in 
> the callee's package.  Then *any* callee can just import that collection 
> class, fill it up, and send it back to the called package.

Would this not be modelled by a set of interfaces? Packages or other
parts of FOP could define interfaces providing the information they
need. A Global Context would probably implement them all. Users
addressing only part of FOP may create their own implementation of the
relevant interface.

Regards, Simon

Simon Pepping
home page: http://www.leverkruid.nl

Reply via email to