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: Design of extended approach finished ------------------------------------------------------------------------------ /** * @severity error */ - public void missingChild(EventBroadcaster broadcaster, Object source, + public void missingChild(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. + 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. QDox will become a build-time dependency only. ''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.'' ''Comment by JeremiasMaerki: In general, I agree but annotations will not make the method parameter names accessible. Reflection doesn't offer that, either. If we go this way, QDox will likely remain for a while. + Using XSLT (or using Java, TBD) and based on that XML file 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. A unit test will make sure there is at least an English message template for each event. The event ID for each event is derived from the interface and method name. + 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 readable and less error-prone. - (to be continued after an experiment...) + The implementations for the !EventProducer interfaces will be provided as dynamic proxies which will make Java code generation unnecessary. Since the necessary metadata can be extracted from the XML file created at code generation time it becomes possible to map the individual event parameters into the Map of the !FopEvent object (Reflection doesn't provide the names of the method parameters). + Acquisition of an !EventProducer and event production: + {{{ + BasicFOValidationEventProducer producer = + (BasicFOValidationEventProducer)getUserAgent().getEventBroadcaster().getEventProducerFor( + BasicFOValidationEventProducer.class); + + producer.missingChild(this, this, getName(), "marker* (%block;)+", locator); + }}} + + !EventBroadcaster will create and cache the dynamic proxies implementing the various !EventProducer interfaces. For this, the !EventBroadcaster is extended by the above method (compared to the first approach). This should all be quite fast once all the translations have been loaded. + + Good: + + * Only new build-time dependencies (QDox, ALv2) + * Good type-safety and consistency/completeness checking for the translations + * No Java code generation necessary + + Bad: + + * More complex to implement + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
