> Keiron Liddle wrote: > > Then the question seems to be: is the default setup good enough for those who > > don't want to use avalon for configuration. Then how else should they present the > > information when avalon is precisely designed for the purpose. > > If it is just setting some simple values, okay, but for example embedding fonts is > > more complex and there is no good reason to create our own data structures just > > for this. > I don't know what to do. Do you?
No. > Note that an XSLT transformer's output method configuration can also > be fairly elaborate. > > > On other issue I forgot to mention is the caching, ie saving pages or other data > > during processing. For example the org.apache.excalibur.store.Store > > with the TRANSIENT_STORE using in cocoon. > I don't think this kind of internals is exposed to the user. It is part of the avalon service though that needs to come through the API. > >>[resolver] > > But then why do you need the base URL passed to the image resolver. > > Isn't The base a property of the source resolver or image resolver not of the > > current image. > The base is in general a property of the document which references > the image. It shouldn't change within a rendering run (which is > different for XSLT processors where document() can change it). > Still, the external-graphics src may be a relative URL, and > somehow the base has to be passed down. I'm not fond of static > data for this purpose. Definitely no statics. Are the resolvers being used for multiple renderings then. So the base cannot be part of it. In which case I agree. Still where will the base URL come from. It is likely to be supplied from an external place/context anyway. > > Why not just have createStructureHandler, where this could be a LayoutHandler > > with the given Renderer or a StructureRenderer. Not sure about the AWT issue > > though as that has different top level handling. > I can't follow you. Would you please put your suggestion on the > wiki page? okay. > >>>[common method that can be used as a source] > > They all aventually go into a set of SAX events that are called onto the FOTree. > > But that is a driving process rather than a getting. > Im not sure what you are saying. > I exposed two processing models > 1. A model driven by the render() method of the processor. In a naive > implementation, the input source is cast successively into various > supported classes, a SAX source is used almost directly, a DOM source > is traversed and a stream source is parsed. Should work similar to > transformer.transform(). > 2. Use getContentHandler() to pipe the FO processor to something else > and drive it from over there, as in the half a zillion answers to > "how do I use a <non-file input> with XSLT with FOP?". This is more > similar to the TrAX TransformerHandler. > Now that I think of it, we could also split this, instead of one > class exposing both render() and getContentHandler(), we also could > use a FOProcessor and a FOProcessorHandler. That's how I understood it, just with "1." it is abstracting to a generic Source and then immediately casting to an implementation. It just seems a bit unecessary. Sure it is not a big deal. I suppose the alternative is to have a different method for each source type which isn't that much better. > J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
