Re: Exploring the FOP API design space
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]
Re: Exploring the FOP API design space
Peter, I think they don't define it because it is a common well known (to them) idea that is used across many specs. Here is a quick definition I found: http://www.w3.org/TR/2000/PR-UAAG10-2310/#def-user-agent So if the user agent is FOP (+ how the document is eventually viewed) then the values and decisions are determined by FOP. My point is that these are typically things that *may* take one value or another so we should allow users of FOP to alter what values are used. Keiron. On Thu, 2002-06-06 at 03:59, Peter B. West wrote: > Keiron, > > You have nicely summarised the references to the user agent in the spec > (except for the first one, invalid markup error handling, which I think > you have added.) However, my problem with the notion in the spec of > user agent remains. The authors have never bothered to define it, and > we are left to work out what, exactly, it is from the various > references. The references that we have - certainly the references to > non-interactive agents - are all to configuration items. At the moment > these things are, as I said, in the XML files. It would, prima facie, > be straightforward to get this from the configuration, in whatever form > that eventually takes, whether we continue to use the XSLT, or introduce > the properties into the CVS tree. I.e., whatever form the expression of > the properties takes, we would need to extract certain key property > values from the configuration. > > Assuming that we have no plans to go into the interactive presentation > business as yet, we can disregard the interactive elements. Even where > an interactive agent would presumably expose the options for > modification, those elements would still require initial values. For > our purposes, I think that "user agent" functions should be merged into > configuration. > > Incidentally, I think the multi-properties, title and hot links elements > should be in the "Interactive" list. The aural properties > (pause-before, pause-after, voice-family) are not necessarly > interactive. It would be quite feasible to produce an audio file > rendering of a document within FOP. > > Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
Keiron, You have nicely summarised the references to the user agent in the spec (except for the first one, invalid markup error handling, which I think you have added.) However, my problem with the notion in the spec of user agent remains. The authors have never bothered to define it, and we are left to work out what, exactly, it is from the various references. The references that we have - certainly the references to non-interactive agents - are all to configuration items. At the moment these things are, as I said, in the XML files. It would, prima facie, be straightforward to get this from the configuration, in whatever form that eventually takes, whether we continue to use the XSLT, or introduce the properties into the CVS tree. I.e., whatever form the expression of the properties takes, we would need to extract certain key property values from the configuration. Assuming that we have no plans to go into the interactive presentation business as yet, we can disregard the interactive elements. Even where an interactive agent would presumably expose the options for modification, those elements would still require initial values. For our purposes, I think that "user agent" functions should be merged into configuration. Incidentally, I think the multi-properties, title and hot links elements should be in the "Interactive" list. The aural properties (pause-before, pause-after, voice-family) are not necessarly interactive. It would be quite feasible to produce an audio file rendering of a document within FOP. Peter Keiron Liddle wrote: >maybe this could answer your question: >http://xml.apache.org/fop/design/useragent.html > >ie. FOP is the user agent but in some cases people might want to alter >certain behaviour. So we provide a class to enable this. > >On Tue, 2002-06-04 at 19:29, Peter B. West wrote: > > >>As a result of this exercise, I remain as confused as ever. The most >>general sense of "user agent" seems to be "fo processor". There are >>"interactive user agents" which may have "user agent windows". User >>agents determine actual values for a number of enumerated values, and >>determine a number of critical default values. Things which are >>currently defined in Properties XML files, and transferred from there >>into the source code, are therefore user agent functions. >> >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
maybe this could answer your question: http://xml.apache.org/fop/design/useragent.html ie. FOP is the user agent but in some cases people might want to alter certain behaviour. So we provide a class to enable this. On Tue, 2002-06-04 at 19:29, Peter B. West wrote: > As a result of this exercise, I remain as confused as ever. The most > general sense of "user agent" seems to be "fo processor". There are > "interactive user agents" which may have "user agent windows". User > agents determine actual values for a number of enumerated values, and > determine a number of critical default values. Things which are > currently defined in Properties XML files, and transferred from there > into the source code, are therefore user agent functions. > > Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Target Interface (was: Re: Exploring the FOP API design space)
The structure handler is specifically to receive events during the SAX creation of the FO Tree so I don't see a need to have an interface and the class with empty methods would be needed anyway. So for the target format: (side note: this would be consistent with the morphos) - mime type - data output: output stream, objects Apart from that we'll see what develops. On Tue, 2002-06-04 at 14:02, Jeremias Maerki wrote: > Hi Keiron > > Oh, that's right. And there's AWT that might some kind of a speciality. > I mean, some will simply want to start the preview dialog, that's simple. > Others will want to paint on a custom panel. > > Ok, that means we probably get another interface (TargetFormat?). That's > what is looked up using the MIME type. We will have two or three > implementations of this interface (one for StructureHandler and one for > Renderer or StreamRenderer/AWTRenderer). Over this new interface FOP > finds out whether this is a structure renderer or a layouted renderer. > Now, if I'm going the right track, is TargetFormat a factory or just a > pointer for another lookup operation on the actual renderer or structure > handler? I don't know, yet. As I can see StructureHandler is a class > right now. Wouldn't it be better if this was just an interface? > > Anyway, looks like I have to look into the new code in the main branch > first. I totally forgot there's the StructureHandler now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
Hello all. There was some talk about user agents, which sent me back to the spec. I have never had any solid sense of what the user agent was all about, so I have collected all of the references to "user agent" from the spec. They should soon be available on the web site under NEW DESIGN->ALT DESIGN->User agent refs, and the xml is in the HEAD. The html can be generated from a `cvs update'd trunk by $ ./build.sh html-altdesign As a result of this exercise, I remain as confused as ever. The most general sense of "user agent" seems to be "fo processor". There are "interactive user agents" which may have "user agent windows". User agents determine actual values for a number of enumerated values, and determine a number of critical default values. Things which are currently defined in Properties XML files, and transferred from there into the source code, are therefore user agent functions. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Exploring the FOP API design space
Ah. That clears it up. This definitely sounds like a step in the right direction. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 04, 2002 2:05 AM To: [EMAIL PROTECTED] Subject: Re: Exploring the FOP API design space The MIME types for renderer selection is not a new idea. But I don't know anymore when it came up for the first time. The idea is to eliminate the hardcoded references to the renderers. That way it's easier to include new ones or special-purpose renderers subclassed from existing ones. Instead of wiring the renderers to FOP using Java code we will do it using XML, or more concrete: The component setup XML which will be used to build the Avalon-style ComponentManagers/ServiceManagers. The MIME types could then be used as role names used to lookup the renderer component (See Avalon docs for roles, component lookup etc). As for subclassing (I'm not sure what exactly you're referring to), we won't need to change the current class hierarchy as far as renderers are concerned. Only some cleaning up and a little bit of refactoring will be required. The only big thing we change is the way we get the renderer. > I'd actually like to hear more about this. I like the idea at first > glance...it seems like it might result in a cleaner codebase...but I > really would like to hear more on how MIME-types could be used to > replace the subclassing technique. Jeremias, are you suggesting a > monolithic class for handling all outputs that switches its logic based > on a MIME-type argument specifying output format? > > -Original Message- > From: J.Pietschmann [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 03, 2002 3:05 PM > To: [EMAIL PROTECTED] > Subject: Re: Exploring the FOP API design space > > Jeremias Maerki wrote: > > > - I'd like to work more with MIME-types for specifying the output format > > instead of subclassing a class for each output format. This may help > > to reduce dependencies. > Interesting. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
Hi Keiron Oh, that's right. And there's AWT that might some kind of a speciality. I mean, some will simply want to start the preview dialog, that's simple. Others will want to paint on a custom panel. Ok, that means we probably get another interface (TargetFormat?). That's what is looked up using the MIME type. We will have two or three implementations of this interface (one for StructureHandler and one for Renderer or StreamRenderer/AWTRenderer). Over this new interface FOP finds out whether this is a structure renderer or a layouted renderer. Now, if I'm going the right track, is TargetFormat a factory or just a pointer for another lookup operation on the actual renderer or structure handler? I don't know, yet. As I can see StructureHandler is a class right now. Wouldn't it be better if this was just an interface? Anyway, looks like I have to look into the new code in the main branch first. I totally forgot there's the StructureHandler now. > That sounds reasonable. > The actual interface may not be the render interface since we also need > to include the rtf, mif handlers. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
Hi Jeremias,
That sounds reasonable.
The actual interface may not be the render interface since we also need
to include the rtf, mif handlers.
On Tue, 2002-06-04 at 11:32, Jeremias Maerki wrote:
> I'd compose the role name using the Renderer interfaces role name
> ("org.apache.fop.render.Renderer") plus a purpose (in our case the MIME
> type, ex. "application/pdf"). An example:
> "org.apache.fop.render.Renderer/application/pdf"
>
> If someone has got his own replacement for some renderer he can change
> the component setup XML so the MIME type "application/pdf" references
> the custom PDF renderer. Or maybe he/she can use additional attributes
> on the mime types such as a non-standard "application/pdf;
> type=mycustomtype". Just ideas. It should work, since we don't even have
> to parse the mime types. And the blanks in the role name shouldn't be a
> problem.
>
> Here's an excerpt from Berin Loritsch's Developing with Avalon
> concerning role names (from
> http://jakarta.apache.org/avalon/developing/framework.html):
> If we have multiple Components that implement the same work interface,
> but are used for different purposes, we have separate roles. A Role is
> the Component's purpose in the system. Each role name will start with
> the original role name, but the purpose name of the role will be
> appended with a /${purpose}. By example we could have the following
> purposes for our DocumentRepository: PurchaseOrder and Bill. Our two
> roles would be expressed as DocumentRepository.ROLE + "/PurchaseOrder"
> and DocuementRepository.ROLE + "/Bill", respectively.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
Hi Keiron
> I agree that mime types would be appropriate to select the output
> format.
> How would you use a mime type to select a special type or an alternative
> renderer or do you think it is unlikely that there would be two
> renderers for the same mime type.
> Some people do have a sub-class of the awt renderer that does extra
> stuff, maybe this could be handled in a better way.
I'd compose the role name using the Renderer interfaces role name
("org.apache.fop.render.Renderer") plus a purpose (in our case the MIME
type, ex. "application/pdf"). An example:
"org.apache.fop.render.Renderer/application/pdf"
If someone has got his own replacement for some renderer he can change
the component setup XML so the MIME type "application/pdf" references
the custom PDF renderer. Or maybe he/she can use additional attributes
on the mime types such as a non-standard "application/pdf;
type=mycustomtype". Just ideas. It should work, since we don't even have
to parse the mime types. And the blanks in the role name shouldn't be a
problem.
Here's an excerpt from Berin Loritsch's Developing with Avalon
concerning role names (from
http://jakarta.apache.org/avalon/developing/framework.html):
If we have multiple Components that implement the same work interface,
but are used for different purposes, we have separate roles. A Role is
the Component's purpose in the system. Each role name will start with
the original role name, but the purpose name of the role will be
appended with a /${purpose}. By example we could have the following
purposes for our DocumentRepository: PurchaseOrder and Bill. Our two
roles would be expressed as DocumentRepository.ROLE + "/PurchaseOrder"
and DocuementRepository.ROLE + "/Bill", respectively.
> On Tue, 2002-06-04 at 08:05, Jeremias Maerki wrote:
> > The MIME types for renderer selection is not a new idea. But I don't
> > know anymore when it came up for the first time.
> >
> > The idea is to eliminate the hardcoded references to the renderers. That
> > way it's easier to include new ones or special-purpose renderers
> > subclassed from existing ones. Instead of wiring the renderers to FOP
> > using Java code we will do it using XML, or more concrete: The component
> > setup XML which will be used to build the Avalon-style
> > ComponentManagers/ServiceManagers. The MIME types could then be used as
> > role names used to lookup the renderer component (See Avalon docs for
> > roles, component lookup etc). As for subclassing (I'm not sure what
> > exactly you're referring to), we won't need to change the current class
> > hierarchy as far as renderers are concerned. Only some cleaning up and a
> > little bit of refactoring will be required. The only big thing we change
> > is the way we get the renderer.
>
> I should hope there is no refactoring required, unless you are talking
> about the maintanence branch.
Well, I'm not up-to-date with the main branch, but I'm not talking about
major refactoring. I meant changing to the LogEnabled, Configurable and
maybe (if necessary) Composable/Servicable interfaces. No big deal!
Cheers,
Jeremias Märki
mailto:[EMAIL PROTECTED]
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
I agree that mime types would be appropriate to select the output format. How would you use a mime type to select a special type or an alternative renderer or do you think it is unlikely that there would be two renderers for the same mime type. Some people do have a sub-class of the awt renderer that does extra stuff, maybe this could be handled in a better way. On Tue, 2002-06-04 at 08:05, Jeremias Maerki wrote: > The MIME types for renderer selection is not a new idea. But I don't > know anymore when it came up for the first time. > > The idea is to eliminate the hardcoded references to the renderers. That > way it's easier to include new ones or special-purpose renderers > subclassed from existing ones. Instead of wiring the renderers to FOP > using Java code we will do it using XML, or more concrete: The component > setup XML which will be used to build the Avalon-style > ComponentManagers/ServiceManagers. The MIME types could then be used as > role names used to lookup the renderer component (See Avalon docs for > roles, component lookup etc). As for subclassing (I'm not sure what > exactly you're referring to), we won't need to change the current class > hierarchy as far as renderers are concerned. Only some cleaning up and a > little bit of refactoring will be required. The only big thing we change > is the way we get the renderer. I should hope there is no refactoring required, unless you are talking about the maintanence branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
The MIME types for renderer selection is not a new idea. But I don't know anymore when it came up for the first time. The idea is to eliminate the hardcoded references to the renderers. That way it's easier to include new ones or special-purpose renderers subclassed from existing ones. Instead of wiring the renderers to FOP using Java code we will do it using XML, or more concrete: The component setup XML which will be used to build the Avalon-style ComponentManagers/ServiceManagers. The MIME types could then be used as role names used to lookup the renderer component (See Avalon docs for roles, component lookup etc). As for subclassing (I'm not sure what exactly you're referring to), we won't need to change the current class hierarchy as far as renderers are concerned. Only some cleaning up and a little bit of refactoring will be required. The only big thing we change is the way we get the renderer. > I'd actually like to hear more about this. I like the idea at first > glance...it seems like it might result in a cleaner codebase...but I > really would like to hear more on how MIME-types could be used to > replace the subclassing technique. Jeremias, are you suggesting a > monolithic class for handling all outputs that switches its logic based > on a MIME-type argument specifying output format? > > -Original Message- > From: J.Pietschmann [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 03, 2002 3:05 PM > To: [EMAIL PROTECTED] > Subject: Re: Exploring the FOP API design space > > Jeremias Maerki wrote: > > > - I'd like to work more with MIME-types for specifying the output format > > instead of subclassing a class for each output format. This may help > > to reduce dependencies. > Interesting. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Exploring the FOP API design space
I'd actually like to hear more about this. I like the idea at first glance...it seems like it might result in a cleaner codebase...but I really would like to hear more on how MIME-types could be used to replace the subclassing technique. Jeremias, are you suggesting a monolithic class for handling all outputs that switches its logic based on a MIME-type argument specifying output format? -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 3:05 PM To: [EMAIL PROTECTED] Subject: Re: Exploring the FOP API design space Jeremias Maerki wrote: > - I'd like to work more with MIME-types for specifying the output format > instead of subclassing a class for each output format. This may help > to reduce dependencies. Interesting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
Some remarks: Jeremias Maerki wrote: > - I'm not sure if we should change the API in the maintenance branch. > Breaking backwards-compatibility produces and deprecating old > interfaces and classes is not so popular, usually. Of course, that's why I thought of keeping the old interface for quite a while, but marking it deprecated after the new interface becomes stable. > - Avalon scares some people. Not necessarily. It depends how visible avalon features are and how much knowledge of, say, JAXP is immediately useful for newcomers to FOP. As for the avalon jar(s), this can be dealt with by providing a big fop-all.jar. > It should be relatively easy to hide the Avalon > stuff. Ooops. That's what I meant. > - I'd like to work more with MIME-types for specifying the output format > instead of subclassing a class for each output format. This may help > to reduce dependencies. Interesting. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
I'd like to make some research this evening (CET) to provide some more thought-through comments. In the meantime I'd like to point out a few things: - Thanks, Jörg, for starting this. I'm in favor of redesigning the API. - I don't believe we will be able to finalize the API this week. There's too much to think about. - I'm not sure if we should change the API in the maintenance branch. Breaking backwards-compatibility produces and deprecating old interfaces and classes is not so popular, usually. - Avalon scares some people. JAXP is a good example of a pretty good API that is easy to use. I'm strongly for providing a simple API for easy use that is as similar as possible with JAXP and has as little dependencies on Avalon as possible (only exception: logging, I think). On the other side, I'm strongly for using Avalon (what a surprise), which means that the simple API IMO should be a wrapper around the Avalon-based API. It should be relatively easy to hide the Avalon stuff. - The simple API will (probably) not have all the possibilities of the Avalon-based API, to keep things as simple as possible. - We should gather some more requirements for the API and hold them in a design paper. - We should provide easy integration into Cocoon preferably using some of their components (resolver, parser factories etc.). Some of them have been moved to Avalon Excalibur, so we don't have dependecies into Cocoon, only Avalon. We probably have to work closely with the Cocoon and Avalon people. This also reduces the common codebase and maintenance effort and improves stability. - If we go the two-API-way we have to decide what to provide in the simple interface. - I'd like to work more with MIME-types for specifying the output format instead of subclassing a class for each output format. This may help to reduce dependencies. Ok, got to get back to work. More to come... Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Exploring the FOP API design space
cruft ?
--
David B. Bitton
[EMAIL PROTECTED]
www.codenoevil.com
Code Made Fresh DailyT
- Original Message -
From: "J.Pietschmann" <[EMAIL PROTECTED]>
To: "fop dev" <[EMAIL PROTECTED]>
Sent: Friday, May 31, 2002 5:34 PM
Subject: Exploring the FOP API design space
> Hi foppers,
> I know I should provide code instead of talking, but then...
>
> The current FOP API suffers from a variety of deficiencies
> - unexpected statefulness (most horribly embodied in
>XSLTInputHandler)
> - weak abstraction of input and output channels
> - incomplete separation of abstraction levels.
> - cruft :-)
>
> Some points I think should be followed on design of a
> new and hopefully better API:
> - Atomic initialisation. After creating a processor,
> it should be ready to run. Mandatory parametrisation
> data should be passed either to the constructor or the
> method(s) running the formatting process, everything
> else should be initialised from sensible defaults.
> - No file names, anywhere. Strings representing ressources
> are always URLs, on the command line, in the config file
> everywhere. In the API, use java.io.File if files are
> deemed necessary.
> - No baseDir. Define a baseURL concept. Pass all URL
> through a resolver.
> - Better abstraction of input and output channels.
>
> Whether only an avalon component API is exposed or whether there is an
> avalon-free API and a separate avalon component is a matter of
> taste. In either case, I'd like to have the possiblity to run a FOP
> core without access to external config *files*, this means I can
> create a new Driver() and can pass all config data by java properties,
> service definitions and by using a user written Configuration class
> passed to the Driver.configure() method for everything too complex to
> be passed as properties and services (i.e. user font config). A FOP
> default Configuration class could read a system and a user config
> file. From what I've gathered from Avalon this is already implemented
> this way there. However, I'm not sure, and I'm not dogmatic about
> this.
>
> The problem I have is the design space for abstracting input
> and output channels.
>
> = Input =
> For input, we have the javax.xml.transform.Source stuff which
> provides a nice unified encapsulation of SAX, DOM and serialised
> XML streams as well as SAX and DOM itself.
>
> The nice part about the j.x.t.Source stuff is that it shields
> the user from as much of the lower level XML stuff as possible,
> in particular from setting up a parser in the common case of
> having serialised XML as input.
>
> Design choice 1:
> Use j.x.t.Source as FOP input. Implement a
> o.a.f.stream.XSLTStreamSource as a j.x.t.s.StreamSource subclass
> for providing XSLT power. (see end of message for an interface
> proposal)
>
> Choice 2:
> Provide SAX and DOM as input (getContentHandler() and render(DOM))
>
> Choice 3:
> Provide (more precise: expose) both. Redundant, but, well...
>
> = Output =
> Next problem: output. We have two rather radically different
> output types: byte streams and GUI panels.
> A really stumbling block is that the object the output is
> written to is volatile, it is likely to change with every
> rendering run, while the kind of renderer as well as the
> renderer specific configuration is more stable. This has
> profund implications for the API design.
>
> Choice 1:
> The interface is at the final output level. This means
> render()/run() methods for each of the classes:
>render(OutputStream) // for PDF, MIF, PS, ...
>run(UserAgent) // for AWT...
> We could add a print() method if necessary.
> Rationale for choosing the method names: render() means
> the input FO is rendered to a byte stream. Run() means,
> the UserAgent is started and the user can interact with it.
> The run() method will return if the user somehow ends the
> interaction process and shuts down the UserAgent. Do I
> interpret the current state correctly?
> This choice implies the renderer and any configuration
> data specific to the renderer has to be passed to the
> Driver (processor) through the Driver configuration
> methods. Because some renderers can be assumed to have
> a lot of renderer specific config data which warrants
> a structure imposed on it, I'm not very fond of the whole
> idea.
>
> Choice 2:
> The interface is the renderer. This means the renderer
> object has to be created by the user explicitely. The
> advantage is that the renderer configuration can be
> designed to fit the renderer rather than to be passed
> through a more generic interface at the Driver. Also,
> renderer configuration and the renderer independent
> processor configuration are better separated, which
> might be a good idea, in particular for people who want
> to render the same FO to several different output formats.
> In this case, a typical code snipped would look like
>
>Processor p=new Processor(
> new ProcessorConfiguration(new File("myconfig.xml")));
