On 25.01.2008 21:57:46 Simon Pepping wrote: > 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?
The user agent will instantiate and provide the broadcaster (isn't implemented, yet). FOP code uses the broadcaster to send events through a single location (the broadcaster). The user registers listeners with the broadcaster in order to react to events. > Who creates the listener? The user? Registered with his > self-instantiated broadcaster? The user gets access to the FOP-instantiated broadcaster through the user agent to register his listener(s). > The FOP events are created in the FOP code, not? Are they only created > if there is a broadcaster? Events are created in FOP code, yes. The broadcaster will always be there, one per rendering run. > The wiki page is not clear because it contains contributions from > different persons, but it is not clear who wrote what. The Blammo proposal comes from Wilfred Springer, the other two below that from me. > 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 know of only one QDox: http://qdox.codehaus.org/ There used to be a SourceForge project but that has moved to Codehaus. ALv2 = Apache License version 2.0, yes. > 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? The XML file is read once in the static initializer of DefaultEventBroadcaster: http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_ProcessingFeedback/src/java/org/apache/fop/events/DefaultEventBroadcaster.java?view=markup Lookups at runtime are done using two get() operations to HashMaps and should be very fast. Note that the event frequency is far lower than logging calls, but the events are unconditional. No modifications will happen to the EventModel at runtime which should avoid potential multi-threading problems because of concurrent access to the same resources. The static initializer is guaranteed to be synchronized. I intend to add an optimization that will stop event broadcasting at the earliest possible point if there are no listeners. > 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? I guess you're referring to my choice to split the broadcaster into interface and default implementation. In the normal case, I don't expect anyone to implement another EventBroadcaster but maybe someone finds a reason to subclass DefaultEventBroadcaster, for example to do filtering. I want to leave that possibility open. Furthermore, the interface is better readable than the implementation. Normally, it should be enough to implement a listener. Basically, I somewhat designed this whole thing to be reused outside the FOP domain as nothing in there is really FOP-specific. The naming of FopEvent somehow bugs me in this regard but I haven't found a better name, yet, to distinguish the event object from java.util.EventObject. Suggestions welcome. HTH > 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 Jeremias Maerki