Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java
[Glen] 2.) Appended EN_ to enumeration constants to [J.Pietschmann] Yuk. Having a large number of identifiers in the same scope with an identical prefix isn't very good for autocompletion both in Emacs and Eclipse. [Glen] We've been doing the same with PR_ (properties) and FO_ (FO's) for quite some time. To avoid a name conflict somewhere. After hitting the EN_, you're at the same place you would be without the prefix. Furthermore, you can now hunt away for your enumeration constants without them being intermixed with the PR_'s and FO_'s. It was also a commenting issue: TRUE and FALSE, for example, without a prefix, just weren't self documenting enough to emphasize that we're working with enumeration constants here. (Remember, we removed the old interfaces--per your desire as well as mine--such as WritingMode.LR_TB or whatever that previously provided that emphasis.) How about having 3 interfaces: 'Properties', 'Elements' and 'Enums' which contains the constants without any prefix. And then decide that these interfaces are never implemented, but the constants are always accessed using the interface name: Enums.TRUE That would keep the searchability and perhaps even help us when (if) we move to typesafe enums. regards, finn
Re: cvs commit: xml-fop/src/java/org/apache/fop/traits LayoutProps.java SpaceVal.java
--- Finn Bock [EMAIL PROTECTED] wrote: We've been doing the same with PR_ (properties) and FO_ (FO's) for quite some time. To avoid a name conflict somewhere. Yes, I was wondering why you didn't originally do that for the enumeration constants as well. I like their self-documenting value in particular though. How about having 3 interfaces: 'Properties', 'Elements' and 'Enums' which contains the constants without any prefix. And then decide that these interfaces are never implemented, but the constants are always accessed using the interface name: Enums.TRUE That would keep the searchability and perhaps even help us when (if) we move to typesafe enums. -0. I prefer the simplicity of the current method, and like the way the code looks as-is. But I can easily see how others may view this solution as more professional. Glen
Preview for a general XSL-FO processing API
I've talked about it before, so in case anybody is interested I've uploaded the Javadocs [1] for a general XSL-FO processing API I've been working on during the last few weeks. It's basically my API proposal that is (or rather was) on the Wiki. I've called it JAFOP (Java API for XSL-FO processing) for now. But naming can change... The implementations for FOP maintenance branch and FOP HEAD already work for simple use cases. No fancy stuff, yet (no events, no userconfig.xml...). The main motivation to do this was a general FO webservice I wrote so I could integrate FOP into a Delphi (Win32) application. FOP and the webservice are deployed inside a Jetty instance which is started through a small JNI wrapper. I found JNI to be quite hard to debug so only having to look after a start() and stop() is quite nice. The webservice is either deployed embedded into the Delphi heavy client or separately on a server, depending on customer needs. Another nice feature [2] of the helper package in there is the ability to easily load multiple implementations in the same VM through ClassLoaders. I needed that to get PDF output from FOP 0.20.5 and RTF output from FOP HEAD. If there's enough interest I can put the source code for the API plus implementations on my website (or to a SF project or somewhere else). I believe this common API could be interesting in the following months when FOP HEAD advances. It can be used to easily switch implementations or during development/testing. And I've got a few additional ideas. As time allows... It might also be interesting to have implementations for Foray, Defoe, XEP and maybe even ol' JFOR. I hope the design is flexible enough to accomodate all Java implementations. [1] http://www.maerki.org/jeremias/dev/jafop/javadocs/ [2] http://www.maerki.org/jeremias/dev/jafop/javadocs/org/xml/fo/helper/DynamicFOProcessorFactory.html Jeremias Maerki
Re: Preview for a general XSL-FO processing API
Jeremias Maerki wrote: If there's enough interest I can put the source code for the API plus implementations on my website (or to a SF project or somewhere else). I believe this common API could be interesting in the following months when FOP HEAD advances. It can be used to easily switch implementations or during development/testing. And I've got a few additional ideas. As time allows... It might also be interesting to have implementations for Foray, Defoe, XEP and maybe even ol' JFOR. I hope the design is flexible enough to accomodate all Java implementations. As long as a FOP user is not *required* to use it, (i.e., they can ignore JAFOP entirely and still call FOP's native JAXP-based API as in our embed examples), and as long as JAFOP is implemented using our current API, then I don't think I would have much problem with it. I don't want us to lose our present JAXP capabilities though--JAXP is a useful skill for our users to become proficient in, and something I would like us to continue promoting. But your idea -- an interface that allows for run-time swapping of FO processors (like JAXP allows for Xalan and Saxon to be switched) is not bad at all. I wish the folks at AH and RX would create such an interface that we could just implement. Two thoughts come to mind: (1) perhaps we should try to reactivate that EXSLFO group and move this topic to them, and (2) you may wish to take a look at the JAXP specification, if you haven't recently, and see if there are any issues/ideas/things you perhaps forgot to take into account, etc., with JAFOP. That spec should show you what needs to be done for a common interface to be accepted, including things you may have missed. Glen
