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 it. >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 process. > 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
