At 09:24 PM 8/1/01 -0500, Runar Bjarnason wrote:
>By the way, is there an effort underway to make a FOP API that conforms to
>Java 1.2 and the new J2EE 1.3 javax.xml packages? I find the current
>architecture rather inflexible (procedural programming practices abounds).

OK, you've got me a little bit curious. :-) What do you consider to be an 
example of "bad" procedural programming in FOP? I'm sure we have plenty of 
it; I'm just wondering where you think it is obscuring the implementation 
and _should_, rather than _could_, be replaced by pure OO?

I don't think that the processing of XSL FO is necessarily or naturally best 
represented as something to be solved by pure OO. My gut feeling is that the 
nicest solution is a hybrid - some aspects (such as properties) are handled 
through OO, and the actual formatting is handled procedurally. Not that FOP 
does it like that, that's just my personal opinion. I'm sure that one can 
come up with really nice pure-OO solutions, but I'm just as sure that very 
nice hybrid or pure-procedural solutions are possible, too.

Also, exactly what do you mean by API? That means almost anything these days 
(usually it means "we're not particularly interested in doing the work of 
writing an implementation, but we'd like to hijack the technology". As in,
Sun defines all the APIs for J2EE, but they have yet to write a reference
implementation that conforms or works...even a production implementation
for that matter, but I'll name no names). If you 
mean are we interested in well-known, stable interfaces for invoking FOP, 
configuring FOP, and plugging in different renderers, yes, we already pretty 
much have an API. Although it's always open for improvement.

Arved Sandstrom

Fairly Senior Software Type
e-plicity (
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to