You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <je...@outline.ch> on 2002/02/27 16:01:59 UTC
Re: Options
I hope you forgive me my switching over to fop-dev which is the right
place for this discussion.
First, I'd like to start asking if you intend to work on this in the
maintenance or the main branch. If you're working on the main branch, I
wouldn't go down to details on how to fix this, because IMHO the current
config mechanism has to be completely replaced.
For the maintenance branch I'm not so sure that you can do with only a
little tweaking. The problems lies in
org.apache.fop.configuration.Configuration which has multiple static
fields that are accessed by the whole project. This is a simple
mechanism to work with but can limit the flexibility of FOP.
Options.java itself contains no static stuff but works with
Configuration.java a lot.
I think, we shouldn't mix CommandLineOptions and Options, because they
are different concerns (One is for command-line interpreting, the other
for loading a configuration).
The problem with refering to the userconfig in the systemconfig is (IMO)
that you cannot have multiple (user-)configurations with one
installation of FOP. You'd limit the usefulness of FOP again somewhat.
If you ask me, I wouldn't change the configuration stuff in the
maintenance branch. What needs to be done is to improve the
documentation on loading the userconfig file. I'll see to it that I can
finally scrape together some time to work on FOP.
> Pardon my ignorance, but could you sketch out the nature of the problem
> for me?
>
> I ask in particular because the current situation is dirty. There is a
> lot of talk going on about the plumbing, which is generally over my
> head, but, in the short term I would like to see the Options
> rationalized in the following way:
>
> recognise that Options is currently completely static - aim to make it a
> non-instantiable class.
> remove the CommandLineOptions class (use String[] where necessary, and
> integrate the parsing functions into the now static Options class.)
> provide an Options.configure static method in a number of guises to
> cover the current use cases.
>
> Of course, you couldn't actually make Options non-instatiable, and you
> couldn't actually remove CommandLineOptions, but you could pretend, and
> provide an alternative to instantiating Options and CommandLineOptions
> objects.
>
> I have mentioned in a previous post the setting of user config file in
> the system config.
>
> Thanks
> Peter
>
>
> Jeremias Maerki wrote:
>
> >>So I can call options once (at application start) and it will affect all transformations thereafter?
> >>That's nice, as I think I was calling this every transformation.
> >>
> >
> >Right. Not that I find this overly nice, because using statics can be A
> >Bad Thing (TM) in server environments. We're going to change that
> >eventually.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Options
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeremias
The files are *rather*, but not *entirely* static, especially scripts at
the moment. It seems to me that in principle such file should be able
to be changed completely independently of the code base.
Peter
Jeremias Maerki wrote:
>
>I see. Are those three not rather static so it would make sense to place
>the resource files with the classes and hard-code the validation code.
>That would make it simpler. Or do you see a case where you need to use a
>different validation file? If you code something like this I'd
>apreciate if validation could be switched of for performance reasons.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Options
Posted by Jeremias Maerki <je...@outline.ch>.
Peter
> >You'll have to create a GUI or use OS X. :-) Well, that leads me to the
> >question: What are you actually trying to do? We're talking about
> >solutions here, but not what you need them for (I think).
> >
> There's a very useful discussion going on about logging, Avalon, etc,
> which covers this territory in more general terms. Anything that
> rationalises and makes consistent and readily understandable the
> invovation and setup of FOP will be a very good thing. I'm just talking
> about the very limited aim of unifying and making more useful the
> existing maintenance branch options/configuration code.
Right, I got that. And I appreciate your effort in this. My problem is
that I haven't yet seen the benefit of what you're trying to do. I
really think which we should have a least a third opinion on this.
> >>>I don't get you here. What do you need the language validation for?
> >>>
> >>For completeness. I can specify country, language and script, and these
> >>may be acted upon in respect of hyphenation. Two situations may arise.
> >> 1) That particular language/country/script may have no support in this
> >>version of FOP. 2) There is no such language/country/script. When I'm
> >>parsing one of these attributes, I like to be able to detect the second
> >>situation at the point of parsing.
> >>
> >
> >I'm lost. Sorry, but I really can't follow you.
> >
> My fault. In the middle of this discussion about options processing, I
> came across the references to the language file in the config file, so I
> dragged them in, kicking and screaming. "I can specify country.language
> and script..." should read, "The user can specify country, language and
> script..." as properties in the FO file that I'm processing. See 7.9.2
> "language", 7.9.1 "country", and 7.9.3 "script" in the Recommendation.
> When I was looking at the parsing of such properties, I wanted to be
> able to validate the element attributes immediately after they were
> parsed by the expression parser. I either had to hard-code the lists,
> or provide for a way of updating them outside the code, so I went for a
> configuration file, pointed to by the the general config file.
I see. Are those three not rather static so it would make sense to place
the resource files with the classes and hard-code the validation code.
That would make it simpler. Or do you see a case where you need to use a
different validation file? If you code something like this I'd
apreciate if validation could be switched of for performance reasons.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Options
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeremias,
Jeremias Maerki wrote:
>Hi Peter
>
...
>You'll have to create a GUI or use OS X. :-) Well, that leads me to the
>question: What are you actually trying to do? We're talking about
>solutions here, but not what you need them for (I think).
>
There's a very useful discussion going on about logging, Avalon, etc,
which covers this territory in more general terms. Anything that
rationalises and makes consistent and readily understandable the
invovation and setup of FOP will be a very good thing. I'm just talking
about the very limited aim of unifying and making more useful the
existing maintenance branch options/configuration code.
...
>>>I don't get you here. What do you need the language validation for?
>>>
>>For completeness. I can specify country, language and script, and these
>>may be acted upon in respect of hyphenation. Two situations may arise.
>> 1) That particular language/country/script may have no support in this
>>version of FOP. 2) There is no such language/country/script. When I'm
>>parsing one of these attributes, I like to be able to detect the second
>>situation at the point of parsing.
>>
>
>I'm lost. Sorry, but I really can't follow you.
>
My fault. In the middle of this discussion about options processing, I
came across the references to the language file in the config file, so I
dragged them in, kicking and screaming. "I can specify country.language
and script..." should read, "The user can specify country, language and
script..." as properties in the FO file that I'm processing. See 7.9.2
"language", 7.9.1 "country", and 7.9.3 "script" in the Recommendation.
When I was looking at the parsing of such properties, I wanted to be
able to validate the element attributes immediately after they were
parsed by the expression parser. I either had to hard-code the lists,
or provide for a way of updating them outside the code, so I went for a
configuration file, pointed to by the the general config file.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Options
Posted by Jeremias Maerki <je...@outline.ch>.
Hi Peter
<snip/>
> >Now, I think you're really start mixing things. I strongly recommend to
> >separate configuration (as the filename says) and processing
> >instructions. What you want to do means creating a new userconfig.xml
> >for each call to FOP. This is much easier using the command line (and
> >faster).
> >
> >Any other opinions?
> >
> No, it doesn't mean creating a new userconfig file for each invocation;
> that's what the command line is for. It's a convenience for special
> requirements for, e.g., developers. Command line trumps userconfig. Is
> it nice? No. Is it useful? Yes. In any case, it seems that in Java
> environments, the command line may not be the best way to pass such
> things around. What do you do on a Mac?
You'll have to create a GUI or use OS X. :-) Well, that leads me to the
question: What are you actually trying to do? We're talking about
solutions here, but not what you need them for (I think).
> >>The language file (see attached) is just a validation mechanism for
> >>certain attribute/property values. It (currently) requires the
> >>org.apache.fop.configuration.LanguageFileReader class which reads the
> >>xml-lang.xml file and builds three HashMaps, which are installed in
> >>Configuration.
> >>
> >
> >I don't get you here. What do you need the language validation for?
> >
> For completeness. I can specify country, language and script, and these
> may be acted upon in respect of hyphenation. Two situations may arise.
> 1) That particular language/country/script may have no support in this
> version of FOP. 2) There is no such language/country/script. When I'm
> parsing one of these attributes, I like to be able to detect the second
> situation at the point of parsing.
I'm lost. Sorry, but I really can't follow you.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Options
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeremias,
Jeremias Maerki wrote:
>Peter
>
>(comments inline)
>
>>In config.xml:
>>
>> <entry>
>> <key>userConfigFileName</key>
>> <value>userconfig.xml</value>
>> </entry>
>>
>
>Ok, that means FOP looks in the current directory for userconfig.xml.
>I can agree with that. I guess there are pros and cons: This mechanism
>can reduce the work that needs to be done to get FOP running in embedded
>mode. But on the other hand, I'm not sure if it cuts on flexibility when
>you want to provide a special configuration.
>
Then you use the command line.
>> <entry>
>> <key>languageConfigFileName</key>
>> <value>xml-lang.xml</value>
>> </entry>
>>
>>(More on languageConfigFileName later.)
>>
>>In userconfig.xml, allow things like
>>
>> <entry>
>> <key>foFileName</key>
>> <value>/home/pbw/public_html/xml/newtest3.fo</value>
>> </entry>
>>
>> <entry>
>> <key>inputMode</key>
>> <value>fo</value>
>> </entry>
>>
>> <entry>
>> <key>foFileName</key>
>> <value>/home/pbw/public_html/xml/newtest3.fo</value>
>> </entry>
>>
>> <entry>
>> <key>outputMode</key>
>> <value>pdf</value>
>> </entry>
>>
>> <entry>
>> <key>outputFileName</key>
>> <value>/home/pbw/public_html/xml/newtest3.pdf</value>
>> </entry>
>>
>
>Now, I think you're really start mixing things. I strongly recommend to
>separate configuration (as the filename says) and processing
>instructions. What you want to do means creating a new userconfig.xml
>for each call to FOP. This is much easier using the command line (and
>faster).
>
>Any other opinions?
>
No, it doesn't mean creating a new userconfig file for each invocation;
that's what the command line is for. It's a convenience for special
requirements for, e.g., developers. Command line trumps userconfig. Is
it nice? No. Is it useful? Yes. In any case, it seems that in Java
environments, the command line may not be the best way to pass such
things around. What do you do on a Mac?
>>The language file (see attached) is just a validation mechanism for
>>certain attribute/property values. It (currently) requires the
>>org.apache.fop.configuration.LanguageFileReader class which reads the
>>xml-lang.xml file and builds three HashMaps, which are installed in
>>Configuration.
>>
>
>I don't get you here. What do you need the language validation for?
>
For completeness. I can specify country, language and script, and these
may be acted upon in respect of hyphenation. Two situations may arise.
1) That particular language/country/script may have no support in this
version of FOP. 2) There is no such language/country/script. When I'm
parsing one of these attributes, I like to be able to detect the second
situation at the point of parsing.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Options
Posted by Jeremias Maerki <je...@outline.ch>.
Peter
(comments inline)
> In config.xml:
>
> <entry>
> <key>userConfigFileName</key>
> <value>userconfig.xml</value>
> </entry>
Ok, that means FOP looks in the current directory for userconfig.xml.
I can agree with that. I guess there are pros and cons: This mechanism
can reduce the work that needs to be done to get FOP running in embedded
mode. But on the other hand, I'm not sure if it cuts on flexibility when
you want to provide a special configuration.
> <entry>
> <key>languageConfigFileName</key>
> <value>xml-lang.xml</value>
> </entry>
>
> (More on languageConfigFileName later.)
>
> In userconfig.xml, allow things like
>
> <entry>
> <key>foFileName</key>
> <value>/home/pbw/public_html/xml/newtest3.fo</value>
> </entry>
>
> <entry>
> <key>inputMode</key>
> <value>fo</value>
> </entry>
>
> <entry>
> <key>foFileName</key>
> <value>/home/pbw/public_html/xml/newtest3.fo</value>
> </entry>
>
> <entry>
> <key>outputMode</key>
> <value>pdf</value>
> </entry>
>
> <entry>
> <key>outputFileName</key>
> <value>/home/pbw/public_html/xml/newtest3.pdf</value>
> </entry>
Now, I think you're really start mixing things. I strongly recommend to
separate configuration (as the filename says) and processing
instructions. What you want to do means creating a new userconfig.xml
for each call to FOP. This is much easier using the command line (and
faster).
Any other opinions?
> User configuration is loaded as follows. The basics of reading from
> user space (untested by me) and system space are simply lifted from the
> existing code and re-arranged. So the answer to your question as to
> where it used to look is, I assume, at the absolute or relative filename
> location, and failing that, in a conf directory at a place detemined by
> one of the class loaders.
>
> public static void loadUserConfiguration(String userConfigFileName)
> throws FOPException {
> // read user configuration file
> boolean readOk = true;
> userConfigFile = new File(userConfigFileName);
> if (userConfigFile != null) {
> ConfigurationReader reader = new ConfigurationReader(
>
> InputHandler.fileInputSource(userConfigFile));
> try {
> reader.start();
> } catch (org.apache.fop.apps.FOPException error) {
> readOk = false;
> }
> if (! readOk) { // same method also loads config.xml
> loadConfiguration(userConfigFileName);
> }
> }
> }
>
> The language file (see attached) is just a validation mechanism for
> certain attribute/property values. It (currently) requires the
> org.apache.fop.configuration.LanguageFileReader class which reads the
> xml-lang.xml file and builds three HashMaps, which are installed in
> Configuration.
I don't get you here. What do you need the language validation for?
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Options
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeremias Maerki wrote:
> Hmm, why not? What would your default entry in the system config be (or
> better: where does it look for the userconfig by default)?
Jeremias,
In config.xml:
<entry>
<key>userConfigFileName</key>
<value>userconfig.xml</value>
</entry>
<entry>
<key>languageConfigFileName</key>
<value>xml-lang.xml</value>
</entry>
(More on languageConfigFileName later.)
In userconfig.xml, allow things like
<entry>
<key>foFileName</key>
<value>/home/pbw/public_html/xml/newtest3.fo</value>
</entry>
<entry>
<key>inputMode</key>
<value>fo</value>
</entry>
<entry>
<key>foFileName</key>
<value>/home/pbw/public_html/xml/newtest3.fo</value>
</entry>
<entry>
<key>outputMode</key>
<value>pdf</value>
</entry>
<entry>
<key>outputFileName</key>
<value>/home/pbw/public_html/xml/newtest3.pdf</value>
</entry>
User configuration is loaded as follows. The basics of reading from
user space (untested by me) and system space are simply lifted from the
existing code and re-arranged. So the answer to your question as to
where it used to look is, I assume, at the absolute or relative filename
location, and failing that, in a conf directory at a place detemined by
one of the class loaders.
public static void loadUserConfiguration(String userConfigFileName)
throws FOPException {
// read user configuration file
boolean readOk = true;
userConfigFile = new File(userConfigFileName);
if (userConfigFile != null) {
ConfigurationReader reader = new ConfigurationReader(
InputHandler.fileInputSource(userConfigFile));
try {
reader.start();
} catch (org.apache.fop.apps.FOPException error) {
readOk = false;
}
if (! readOk) { // same method also loads config.xml
loadConfiguration(userConfigFileName);
}
}
}
The language file (see attached) is just a validation mechanism for
certain attribute/property values. It (currently) requires the
org.apache.fop.configuration.LanguageFileReader class which reads the
xml-lang.xml file and builds three HashMaps, which are installed in
Configuration.
Peter
Re: Options
Posted by Jeremias Maerki <je...@outline.ch>.
Hmm, why not? What would your default entry in the system config be (or
better: where does it look for the userconfig by default)?
> Yes you can, if you allow the command line configuration to take
> precedence. The system config file then contains your default user
> config, which defaults to null (as it does at the moment.) It's very
> handy for testing. My test environment goes in the user config, and
>
> java org.apache.fop.apps.Fop
>
> runs it all. Note that the loadUserConfig funtionality checks for the
> user config file first in user space, then in system space, which would
> by default pick up the null distributed user config example if the user
> does nothing. And it that's too dangerous, comment out the definition
> of the user config file in the system config.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Options
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeremias,
Jeremias Maerki wrote:
>I hope you forgive me my switching over to fop-dev which is the right
>place for this discussion.
>
Of course.
>
>First, I'd like to start asking if you intend to work on this in the
>maintenance or the main branch. If you're working on the main branch, I
>wouldn't go down to details on how to fix this, because IMHO the current
>config mechanism has to be completely replaced.
>
Maintenance, for the reasons you mention.
>
>For the maintenance branch I'm not so sure that you can do with only a
>little tweaking. The problems lies in
>org.apache.fop.configuration.Configuration which has multiple static
>fields that are accessed by the whole project. This is a simple
>mechanism to work with but can limit the flexibility of FOP.
>Options.java itself contains no static stuff but works with
>Configuration.java a lot.
>
...configuration.Configuration is unaffected.
>
>I think, we shouldn't mix CommandLineOptions and Options, because they
>are different concerns (One is for command-line interpreting, the other
>for loading a configuration).
>
I want to merge them because they are so alike. System congfig, user
config and command line are a hierarchy of configuration options, and
should be unified, with each one overriding the next.
>
>The problem with refering to the userconfig in the systemconfig is (IMO)
>that you cannot have multiple (user-)configurations with one
>installation of FOP. You'd limit the usefulness of FOP again somewhat.
>
Yes you can, if you allow the command line configuration to take
precedence. The system config file then contains your default user
config, which defaults to null (as it does at the moment.) It's very
handy for testing. My test environment goes in the user config, and
java org.apache.fop.apps.Fop
runs it all. Note that the loadUserConfig funtionality checks for the
user config file first in user space, then in system space, which would
by default pick up the null distributed user config example if the user
does nothing. And it that's too dangerous, comment out the definition
of the user config file in the system config.
>
>If you ask me, I wouldn't change the configuration stuff in the
>maintenance branch. What needs to be done is to improve the
>documentation on loading the userconfig file. I'll see to it that I can
>finally scrape together some time to work on FOP.
>
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org