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.
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
