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 JeremiasMaerki: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback The comment on the change is: Start documenting the extended proposal ------------------------------------------------------------------------------ ''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 == + == Minimal Approach == {{{ public class FopEvent extends EventObject { @@ -187, +187 @@ * No check mechanisms for detecting missing messages/message translations * No check mechanisms for detecting mismatches between used parameters and the parameters that are available + == Extended Approach == + + This one is based on the above and extends it to address the negative points. The basic interfaces above remain unchanged. It uses similar ideas like the Blammo proposal but tries to address the negative points, too. + + A marker interface is created: + + {{{ + public interface EventProducer { + } + }}} + + Multiple interfaces deriving from !EventProducer are created, for example: + + {{{ + public interface BasicFOValidationEventProducer extends EventProducer { + [..] + + /** + * @severity error + */ + public void missingChild(EventBroadcaster broadcaster, Object source, + FObj element, String elementName, String contentModel, Locator locator); + + [..] + }}} + + 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. + + 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. + + (to be continued after an experiment...) + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
