Generation of *EventProducer.xml [was: Re: svn commit: r828747...]

[Vincent Hennebert-2]

Hi,

> Log:
> 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)
>
> Added:
>     xmlgraphics/fop/branches/Temp_Accessibility/src/java/org/apache/fop/accessibility/AccessibilityEventProducer.java   (with props)
>     xmlgraphics/fop/branches/Temp_Accessibility/src/java/org/apache/fop/accessibility/AccessibilityEventProducer.xml   (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?

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?


Thanks,
Vincent

[Jeremias Maerki-2]

On 22.10.2009 19:36:14 Vincent Hennebert wrote:

> Hi,
>
> > Log:
> > 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)
> >
> > Added:
> >     xmlgraphics/fop/branches/Temp_Accessibility/src/java/org/apache/fop/accessibility/AccessibilityEventProducer.java   (with props)
> >     xmlgraphics/fop/branches/Temp_Accessibility/src/java/org/apache/fop/accessibility/AccessibilityEventProducer.xml   (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:
http://svn.apache.org/viewvc?rev=828805&view=rev

> 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 [1] 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.

[1] http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/transform/OutputKeys.html#OMIT_XML_DECLARATION

Jeremias Maerki

[Vincent Hennebert-2]

Hi,

Jeremias Maerki wrote:

> On 22.10.2009 19:36:14 Vincent Hennebert wrote:
>> Hi,
>>
>>> Log:
>>> 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)
>>>
>>> Added:
>>>     xmlgraphics/fop/branches/Temp_Accessibility/src/java/org/apache/fop/accessibility/AccessibilityEventProducer.java   (with props)
>>>     xmlgraphics/fop/branches/Temp_Accessibility/src/java/org/apache/fop/accessibility/AccessibilityEventProducer.xml   (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:
> http://svn.apache.org/viewvc?rev=828805&view=rev

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 [1] 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.
>
> [1] http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/transform/OutputKeys.html#OMIT_XML_DECLARATION

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?

Vincent

[Jeremias Maerki-2]

Hi Vincent,

feel free to improve as you see fit. I have no problem with any of your
suggestions.

On 27.10.2009 11:40:21 Vincent Hennebert wrote:

> Hi,
>
> Jeremias Maerki wrote:
> > On 22.10.2009 19:36:14 Vincent Hennebert wrote:
> >> Hi,
> >>
> >>> Log:
> >>> 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)
> >>>
> >>> Added:
> >>>     xmlgraphics/fop/branches/Temp_Accessibility/src/java/org/apache/fop/accessibility/AccessibilityEventProducer.java   (with props)
> >>>     xmlgraphics/fop/branches/Temp_Accessibility/src/java/org/apache/fop/accessibility/AccessibilityEventProducer.xml   (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:
> > http://svn.apache.org/viewvc?rev=828805&view=rev
>
> 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 [1] 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.
> >
> > [1] http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/transform/OutputKeys.html#OMIT_XML_DECLARATION
>
> 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?
>
> Vincent

Jeremias Maerki