Hi Joerg and others,
Here are some ideas. I don't consider this a better approach just an
alternative.
What are the problems we are trying to solve. Make it simple for someone
to understand and quickly use without hassle. make it configurable, fast
and customisable for specific situations like cocoon.
The api proposals are configured with each object separately. ie. the
Processor, Renderer and (by deduction, if being configured) UserAgent.
How does this relate to FOP having a single configuration. For example
from the command line it will get a single configuration file that will
contain the main configuration (Process, Driver whatever) and the
renderer and useragent configuration information. If we allow them to
create and configure parts then we no longer have a single point of
interaction.
In what cases do renderers need to be configured separately. Do they
need to be constructed outside of the Driver.
We need to provide a method to return a SAXHandler.
Do we have a single top level element Driver (or Processor).
Or are the Driver, Renderer and UserAgent peer level objects.
Could we alternatively provide multiple top level objects for different
situations.
The basic embedders converter. Converts from input stream or document
source into an output stream optionally with a mime type. No
configuration, no user agent.
FOPConverter {
convert(InputStream, OutputStream)
convert(InputStream, OutputStream, String mime)
convert(Source, OutputStream)
convert(Source, OutputStream, String mime)
createSAXResult(OutputStream)
createSAXResult(OutputStream, String mime)
}
Serious embedders use one of the following:
ConfigProcessor extends Configurable, LogEnabled, Composable {
Processor(OutputStream, String mime)
setLogger(Logger)
configure(Configuration)
compose(ComponentManager)
render(Source)
}
Processor {
Processor(UserAgent, Renderer)
render(Source)
}
SAXProcessor {
SAXProcessor(Configuration, OutputStream, String mime)
SAXProcessor(UserAgent, Renderer)
getContentHandler()
}
Renderer is same as before.
class PDFRenderer {
PDFRenderer(OutputStream o)
PDFRenderer(OutputStream o, Configuration)
}
It either configures both the user agent and render, nothing or you do
the work. Renderers are created from mime type or supplied.
So what are the problems?
This might confuse people but with clear documents it should be easier I
think.
Cocoon creates a single renderer that it reuses (for each serializer
object). Overhead needed to lookup, construct and configure new renderer
every time.
It doesn't really follow the avalon concepts of configuration, logging
etc.
Keiron
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
