[Xmlgraphics-fop Wiki] Update of "ProcessingFeedback" by WilfredSpringer

[Apache Wiki <wi...@apache.org>]

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 WilfredSpringer:
http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback

------------------------------------------------------------------------------
   * The layout engine should be able to provide some information per-page, for example: An important information for users producing book-style documents is, for each page, the difference between the available page heigth and the actual content height. Even if it is not a real "error" to create unfilled pages, underfull pages are not beautiful. This information, that could be taken from the !PageBreakPositions, would allow users to easily check if fop produced "good" pages without the need to open the pdf and look at it.
   * Furthermore, editor writers might be interested to know what IDs ended up on which page to provide quick "jump-to-problem" functions, for example.
  
+ = Suggestions =
+ 
+ == Blammo ==
+ 
+ I would like to propose using something like Blammo. Blammo is extremely simple. You simply define an interface in which all of the operations represent event conditions in which you are interested. I am not aware of the specific conditions that you might want to track, but gathering from the above, I could imagine something like this:
+ 
+ {{{
+ interface FopLogger {
+ 
+   void logMissingResource(String path);
+ 
+   void logInvalidFoElement(String xpath);
+ 
+   ...
+ }
+ }}}
+ 
+ Then you use classic JavaDoc annotations how this should be bound to a lower-level logging API:
+ 
+ {{{
+ interface FopLogger {
+ 
+   /**
+    * @blammo.level warn
+    * @blammo.message Failed to locate resource {path}
+    */
+   void logMissingResource(String path);
+ 
+   /**
+    * @blammo.level error
+    * @blammo.message Invalid FO content located here: {xpath}
+    */
+   void logInvalidFoElement(String xpath);
+ 
+   ...
+ }
+ }}}
+ 
+ In the FOP code, you would instantiate an implementation of the logger using the [http://blammo.sourceforge.net/blammo-core/apidocs/com/agilejava/blammo/BlammoLoggerFactory.html BlammoLoggerFactory.create(...)] operation. This will construct an implementation that is bound to a lower level logging API, which could be the one of your choice. In my case - I want to wire it to the Maven plugin logger. So I would pass in a [http://blammo.sourceforge.net/blammo-core/apidocs/com/agilejava/blammo/LoggingKitAdapter.html LoggingKitAdapter] that would map all logging to the Maven logger. 
+ 
+ There are a couple of benefits for dealing with it like this:
+ 
+  * You can always trap specific conditions yourself in your own code, by implementing your own implementation of the interface, or a proxy that forwards to the Blammo generated implementation. 
+  * Blammo is generating message IDs. 
+  * Blammo generates an ID to human readable error description, as a Maven report.
+ 
+ 

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org