> >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.
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]