The first two frames are in static context. The LMs share a reference
to a user agent object, of type
layoutmgr.AbstractLayoutManager.userAgent. Would this be the right
object to hold a reference to the user configuration?
On first thought, yes. But I feel the scope of the FOUserAgent is still
somewhat undefined. Maybe we need to finally settle this issue. Until
this is done I consider it safe to hold the user configuration in there.
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?
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.
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.
Glen
