Hi, I am not familiar with these technologies, so I have a few questions:
Who creates the broadcaster? The user? In the user agent? Does FOP provide the DefaultEventBroadcaster? Who creates the listener? The user? Registered with his self-instantiated broadcaster? The FOP events are created in the FOP code, not? Are they only created if there is a broadcaster? The wiki page is not clear because it contains contributions from different persons, but it is not clear who wrote what. Is there a URL for QDox? Is there only one QDox? I found two, but they may be the same. What is ALv2? The Apache License version 2? I am not clear about the role of the XML file. Does the getEventProducerFor method read the XML file and based on its content create the producer, at runtime? Does it cache producers? Maybe the cache is even static? Why does a user need to be able to write his own broadcaster, with his own event producers, besides his own listeners? Why is it not enough to let him write his own listeners? Regards, Simon On Thu, Jan 24, 2008 at 03:45:59PM +0100, Jeremias Maerki wrote: > Please see: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback > > There are now 3 different approaches we could take for an event > mechanism to better inform a user (technical or real-life) of events, > problems and progress inside FOP, per rendering run of course. > > I'd be grateful for your thoughts. I'm personally preferring the > "extended approach" even though it's the most complex one but it > provides ease of use once it's built and contains QA measures so we > don't accidentally forget any message templates. > > Of course, we could add these message templates as javadoc tags (like > the Blammo proposal, but in all languages) but that puts everything in > one file which I'd like to avoid. As long as there are only English it's > fine, but if the community starts producing all sorts of translations it > could get messy. > > Blammo is interesting and gave me some ideas but it's not "there". I'm > afraid that improving Blammo would delay the whole thing too much. > > Jeremias Maerki > -- Simon Pepping home page: http://www.leverkruid.eu
