Jeremias Maerki wrote:
> On 22.10.2009 19:36:14 Vincent Hennebert wrote:
>>> Issue an error when attempting to render an intermediate XML file in
>>> accessibility mode, but that file wasn't generated with accessibility
>>> (i.e., does not contain the structure tree)
>>> (with props)
>>> (with props)
>> After creating the AccessibilityEventProducer.xml file and running ‘ant
>> resourcegen’ I discovered that an empty message had been added to
>> src/java/org/apache/fop/events/EventFormatter.xml. Why?
> Because the new files wasn't reflected in the build. All events not
> specifically directed into a special file go into the catch-all file in
> the events package. I've updated the build accordingly:
I have trouble seeing the necessity of adding something to the build
file I must say. (That build file, BTW, is already 1441 lines long. We
should think twice before adding anything to it IMO.)
All eventResourceGenerator tasks are exactly the same. Couldn’t we set
the convention that the translation file corresponding to a certain
EventProducer interface must have the same name and be in the same
directory as the interface itself?
Example: a PDFEventProducer.java file is found in the
org/apache/fop/render/pdf directory; a PDFEventProducer.xml file
containing the translation is expected in that same directory.
Using a catch-all file kills the modularity of the thing IMO. Also, the
individual translation files are called *EventProducer.xml but the
catch-all file is called EventFormatter.xml!?
>> Also, after re-building FOP I regularly find myself with modified
>> *EventProducer.xml files, where the sole modification is an
>> added/removed line break. This is annoying. How can that be avoided?
> These are small differences in behaviour of XML serializers. I guess if
> that is so annoying, we'd have to make sure we always use the same
> serializer (make & version) somehow. We could also experiment with
> removing the XML declaration  at the beginning of the file. That
> might get rid of the problem but that's not for sure. I've stumbled over
> this myself a number of times but found it to be only a minor nuisance
> which is why I didn't do anything about it.
I can see the interest of filling the translation file with empty
messages having correct keys (those are not exactly trivial —although
necessary, I guess). However, there is IMO a non-negligible danger that
the user then forgets to fill in those messages appropriately.
Also, I’m not sure I like having a file that is both manually edited and
automatically generated. That usually doesn’t go well together, as the
automatic generation usually messes up any manual formatting. The above
is an illustration.
If there were the convention that the translation file must be put in
the same package as the EventProducer interface, the key wouldn’t need
to be fully qualified, only the method name would be necessary. Then
I think it’s reasonable to expect the user to fill in the translation
file accordingly, and just check at build time that both the interface
and the translation file are consistent.
Is there anything wrong with that?