Re: Processing Feedback: 3 alternatives for review

2008-01-28 Thread Jeremias Maerki
On 28.01.2008 20:41:22 Simon Pepping wrote: > Thanks for your extensive reply. > > On Fri, Jan 25, 2008 at 10:48:52PM +0100, Jeremias Maerki wrote: > > On 25.01.2008 21:57:46 Simon Pepping wrote: > > > Why does a user need to be able to write his own broadcaster, with his > > > own event producers

Re: Processing Feedback: 3 alternatives for review

2008-01-28 Thread Simon Pepping
Thanks for your extensive reply. On Fri, Jan 25, 2008 at 10:48:52PM +0100, Jeremias Maerki wrote: > On 25.01.2008 21:57:46 Simon Pepping wrote: > > 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

Re: Processing Feedback: 3 alternatives for review

2008-01-28 Thread Jeremias Maerki
On 28.01.2008 11:52:23 Vincent Hennebert wrote: > Jeremias Maerki wrote: > > On 27.01.2008 16:15:45 Vincent Hennebert wrote: > > > >>> No, the exception should always contain the cause. > >> Then I’m missing the point of the new feedback mechanism. Why would you > >> have to both create an event

Re: Processing Feedback: 3 alternatives for review

2008-01-28 Thread Vincent Hennebert
Hi Jeremias, Jeremias Maerki wrote: > On 27.01.2008 16:15:45 Vincent Hennebert wrote: >> But that mentioning of exceptions just makes me wondering of the >> following: what if an unrecoverable error occurs (say, too many cells on >> a table row)? I guess I’ll trigger an event of severi

Re: Processing Feedback: 3 alternatives for review

2008-01-28 Thread Jeremias Maerki
On 27.01.2008 16:15:45 Vincent Hennebert wrote: > > But that mentioning of exceptions just makes me wondering of the > following: what if an unrecoverable error occurs (say, too many cells on > a table row)? I guess I’ll trigger an event of severity > EventSeverity.ERROR and I

Re: Processing Feedback: 3 alternatives for review

2008-01-27 Thread J.Pietschmann
Jeremias Maerki wrote: Please see: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback I still hadn't have time to review this, sorry. Maybe next Tuesday. J.Pietschmann

Re: Processing Feedback: 3 alternatives for review

2008-01-27 Thread Vincent Hennebert
But that mentioning of exceptions just makes me wondering of the following: what if an unrecoverable error occurs (say, too many cells on a table row)? I guess I’ll trigger an event of severity EventSeverity.ERROR and I absolutely expect that /every/ listener will throw an

Re: Processing Feedback: 3 alternatives for review

2008-01-25 Thread Jeremias Maerki
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 (i

Re: Processing Feedback: 3 alternatives for review

2008-01-25 Thread Simon Pepping
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

Re: Processing Feedback: 3 alternatives for review

2008-01-25 Thread Jeremias Maerki
On 25.01.2008 17:50:44 Vincent Hennebert wrote: > Jeremias Maerki wrote: > > On 25.01.2008 12:35:50 Vincent Hennebert wrote: > >> Hi Jeremias, > >> > >> Jeremias Maerki wrote: > >>> That's actually one of the requirements, I just haven't discussed this > >>> explicitely on the Wiki page. I assumed

Re: Processing Feedback: 3 alternatives for review

2008-01-25 Thread Vincent Hennebert
Jeremias Maerki wrote: > On 25.01.2008 12:35:50 Vincent Hennebert wrote: >> Hi Jeremias, >> >> Jeremias Maerki wrote: >>> That's actually one of the requirements, I just haven't discussed this >>> explicitely on the Wiki page. I assumed everyone can throw any unchecked >>> exception in the listener

Re: Processing Feedback: 3 alternatives for review

2008-01-25 Thread Jeremias Maerki
On 25.01.2008 12:35:50 Vincent Hennebert wrote: > Hi Jeremias, > > Jeremias Maerki wrote: > > That's actually one of the requirements, I just haven't discussed this > > explicitely on the Wiki page. I assumed everyone can throw any unchecked > > exception in the listener. Introducing a checked exc

Re: Processing Feedback: 3 alternatives for review

2008-01-25 Thread Vincent Hennebert
Hi Jeremias, Jeremias Maerki wrote: > That's actually one of the requirements, I just haven't discussed this > explicitely on the Wiki page. I assumed everyone can throw any unchecked > exception in the listener. Introducing a checked exception for this > purpose would be horrible as it would go t

Re: Processing Feedback: 3 alternatives for review

2008-01-25 Thread Jeremias Maerki
On 24.01.2008 23:15:09 Andreas Delmelle wrote: > > 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 th

Re: Processing Feedback: 3 alternatives for review

2008-01-24 Thread Andreas Delmelle
On Jan 24, 2008, at 15:45, 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 ren

Re: Processing Feedback: 3 alternatives for review

2008-01-24 Thread Jeremias Maerki
That's actually one of the requirements, I just haven't discussed this explicitely on the Wiki page. I assumed everyone can throw any unchecked exception in the listener. Introducing a checked exception for this purpose would be horrible as it would go through all of FOP which I don't think would b

Re: Processing Feedback: 3 alternatives for review

2008-01-24 Thread Max Berger
Jeremias, on the message consumer side it would be nice if message handlers could throw exceptions - this would allow "strict" handlers to immediately cancel processing of a fo file, a more lenient handlers could just emit warnings (similar to sax handlers), and a batch system could ignore it. Ho

Processing Feedback: 3 alternatives for review

2008-01-24 Thread Jeremias Maerki
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 thoug