comments on new configuration subsytem

[Kelly Campbell <ca...@camk.net>]

I'm adding the list of default filter types for PDF streams into the new
configuration subsystem, and I just had a few comments on that. It seems
to me that separating the various configuration files out is designed for
having many settable parameters which we don't have yet, but I think it
also adds complexity that isn't neccessary, and could cause some confusion
because of the extra files.

Also, as it's currently implemented, it seems like it would be hard for 
users to override items from one config file because they'd have to make 
separate calls into Driver for each role to load their config.

I think it would be cleaner to have one config file and add a role 
attribute to each entry. Then only one default file has to be loaded 
(which can be done automatically by the Driver constructor rather than 
requiring clients to call loadDefaultConfiguration). And the user could 
override any entries they need to within one local configuration file. It 
would also clean up the implementation because we wouldn't need separate 
PDFConfiguration and AWTConfiguration classes. Instead, everything could 
go through on centralized configuration class which handles user overrides 
and the various roles.

For example in config.xml:

<entry><!-- role defaults to standard ?? -->
 <key>version</key>
 <value>fop 0.16</value>
<entry>
<entry role="pdf">
 <key>stream-filter-list</key>
 <list>
  <value>flate</value>
  <value>ascii-85</value>
 </list>
</entry>

Then when the PDF renderer wants to get its list of filters, it makes a 
call something like this:

Configuration.getListValue("stream-filter-list","pdf");
  
What do you think?

-Kelly
-- 
Kelly A. Campbell                        Software Engineer
camk@channelpoint.com                    Channelpoint, Inc.
camk@camk.net  camk@merlotxml.org        Colorado Springs, Co.

Re: comments on new configuration subsytem

[Fotis Jannidis <fo...@lrz.uni-muenchen.de>]

I changed the configuration package in the way Kelly proposed it. 

Standard configuration goes into xml-fop/conf/config.xml. this file is 
compiled into the fop.jar file and automatically loaded by the 
constructor of Driver. 

You can call Configuration in your code this way:

Object Configuration.getValue(String key, int role) 

values for role are 
Configuration.STANDARD
Configuration.PDF
Configuration.AWT

there are some convenience methods in Configuration:

String getStringValue (String key, int role) 
Boolean getBoolean (String key, int role) 
int getIntValue(String key, int role) 
Vector getListValue(String key, int role) 
Hashtable getHashtableValue(String key, int role)

and the same list of methods with the signature (String key)
which retrieve from the standard configuration, like
String getStringValue (String key) 

The user can provide her own configuration file which is read in 
after the standard configuration file and overwrites the values there, 
if the are already defined.

XalanCommandLine and CommandLine can be called with the 
option -x which dumps the contents of configuration, after the user 
file has been read in, to give the user the possibility to check in 
cases of unwanted behaviour. 

Kelly's example of the config.xml works now, that is: if entry has no 
attribute, role defaults to standard.


Fotis


> For example in config.xml:
> 
> <entry><!-- role defaults to standard ?? -->
>  <key>version</key>
>  <value>fop 0.16</value>
> <entry>
> <entry role="pdf">
>  <key>stream-filter-list</key>
>  <list>
>   <value>flate</value>
>   <value>ascii-85</value>
>  </list>
> </entry>
> 
> Then when the PDF renderer wants to get its list of filters, it makes a 
> call something like this:
> 
> Configuration.getListValue("stream-filter-list","pdf");
>   
> What do you think?
> 
> -Kelly
> -- 
> Kelly A. Campbell                        Software Engineer
> camk@channelpoint.com                    Channelpoint, Inc.
> camk@camk.net  camk@merlotxml.org        Colorado Springs, Co.

Re: comments on new configuration subsytem

[Fotis Jannidis <fo...@lrz.uni-muenchen.de>]

Kelly,
you are absolutely right. I started out with the idea (and that was, I 
think, also the proposal discussed on the list) to have different 
classes, but then saw that this is a too big a solution and just did 
StandardConfiguration. The other classes are really only dummies 
at the moment. The idea was, that all configuration is put there and 
the reader overrides it with just one user file. I played with the idea 
to have the roles as part of the configuration file but then thought, it 
probably isn't necessary as this will be replaced soon by some 
Avalon based solution (Steve, maybe you want to comment this?) 

Anyway, I will change it following your outline (putting the loading of 
the configuration into the Driver constructor is a good idea). 

Fotis