Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The following page has been changed by VincentHennebert: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback The comment on the change is: Added a comment about the eventual possibility to use Java 1.5 annotations ------------------------------------------------------------------------------ ''Comment by WilfredSpringer: I could change the license, and the annotations are JavaDoc-type of annotations. Think commons-attributes. In this case it's based on QDox, so you don't have to worry about Java 1.5.'' - ''Comment by JeremiasMaerki: I've removed the point about Java 1.5. You were right, of course. I just saw "@"s and thought they were annotations. I took a closer look now. A problem for us would be the current necessity for Maven for code generation. We'd need an Ant task. I get the impression that the main focus is on logging those events to a logging subsystem. For us, I think, this would only be a side-show. The most important is for the user to install an event listener so all events (including all parameters) can be inspected and acted upon (including throwing exceptions). My proposal: I'm going to sketch out a proposal (without Blammo) that I think would meet the requirements of FOP and then we can see if and how Blammo could maybe accommodate this and if it would be worth adding such a dependency. + ''Comment by JeremiasMaerki: I've removed the point about Java 1.5. You were right, of course. I just saw "@"s and thought they were annotations. I took a closer look now. A problem for us would be the current necessity for Maven for code generation. We'd need an Ant task. I get the impression that the main focus is on logging those events to a logging subsystem. For us, I think, this would only be a side-show. The most important is for the user to install an event listener so all events (including all parameters) can be inspected and acted upon (including throwing exceptions). My proposal: I'm going to sketch out a proposal (without Blammo) that I think would meet the requirements of FOP and then we can see if and how Blammo could maybe accommodate this and if it would be worth adding such a dependency.'' == Minimal Approach == @@ -215, +215 @@ QDox will be used to parse all Java interfaces which extend from !EventProducer (as part of an Ant task). For each method in every interface an event definition object will be built that contains all meta-information about the object. This meta model will be written to an XML file. The XML is then used to create Java code (using XSLT) that implements the !EventProducer interfaces with code to convert to method calls to !FopEvent objects which are broadcast through the !EventBroadcaster. The event ID is derived from the interface and method name. Furthermore, another XML is generated which contains structures for entering the message templates. An existing translation file is merged automatically so existing translations aren't lost. The same also happens for any existing files for other languages. QDox will become a build-time dependency only. A unit test will make sure there is at least an English message template for each event. + ''Comment by Vincent Hennebert: once we upgrade to Java 1.5 as a minimum requirement this should be possible to replace those Javadoc annotations with 1.5 annotations and switch back to a standard mechanism to generate the classes.'' + At run-time the XML translation files are read into memory and made available similar as with !ResourceBundle (actually a subclass of that class). XML for the translation files is used to avoid the awkward way special characters need to be escaped and to address the fact the properties files don't have an encoding indicator like XML files do. - Message production will not be done using java.text.!MessageFormat (which uses parameter indexes). Instead the parameter names defined on the interface can be used directly as message parameters which should make the whole thing more readble and less error-prone. + Message production will not be done using java.text.!MessageFormat (which uses parameter indexes). Instead the parameter names defined on the interface can be used directly as message parameters which should make the whole thing more readable and less error-prone. (to be continued after an experiment...) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
