You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Keiron Liddle <ke...@aftexsw.com> on 2002/05/29 12:04:10 UTC
[REDESIGN] configuration
Hi,
Here are some ideas about how we could do the configuration for FOP.
Comments are welcome.
Use this class and various supporting classs (already in avalon
framework jar):
org.apache.avalon.framework.configuration.Configuration
>From a brief look at how this works it should be quite easy to use. We
just need to decide on an appropriate xml structure. I have attached an
example.
This can be used either with an xml file on the command line or through
embedding, eg. cocoon could pass a fop configuration class.
If the classes are not configured then default values are used.
Configurable classes:
- Driver
Passes configuration to user agent if not already set and to renderers.
- All renderers (ie. Renderer, StructureHandler implements)
This is so that the renderer can get its own specific information.
The PDFRenderer could have font setup, stream filters etc.
- Configurable FOUserAgent (have default FOUserAgent that can be
used/extended without config)
To make it possible to setup all the various options like dpi.
----------
The logkit Logger can be configured using this but it is not
appropriate. If FOP is run from the command line then it should do what
it already does and when embedding it would setup its own logger.
The image cache and other cache are similar. These can be set with a
static method and through the driver respectively.
Keiron.
Re: [REDESIGN] configuration
Posted by Jeremias Maerki <je...@outline.ch>.
> On Wed, 2002-05-29 at 17:18, Jeremias Maerki wrote:
> > > - Configurable FOUserAgent (have default FOUserAgent that can be
> > > used/extended without config)
> > > To make it possible to setup all the various options like dpi.
> >
> > I'm still at a lack of knowledge on these new things. :-( But it sounds
> > reasonable. I think a lot of thinking when using Avalon goes into which
> > classes are components (they get a logger, configuration etc. and
> > provide some sort of service) and which are merely data-holding classes
> > like an InlineArea. Correct me if I'm wrong: UserAgents are those
> > classes that do the heavy work that was formerly distributed in many
> > different classes directly on classes that change into simple
> > data-holding classes at the moment.
>
> That is essentially it.
> The FOUserAgent holds a bunch of decision making values that people may
> want to change.
:-) Cool.
> > > The image cache and other cache are similar. These can be set with a
> > > static method and through the driver respectively.
> >
> > I'd like to avoid the static stuff, if possible. There's the concept of
> > a ComponentManager (or after an evoluntionary step the ServiceManager),
> > which allows components to look up services provided by the
> > container/parent. There are multiple implementations in Avalon:
> > ExcaliburComponentManager (ECM), Fortress, Merlin, Phoenix. Using this
> > mechanism forces us to think again about some interfaces, or helps us to
> > easily provide multiple implementations of the same interface.
>
> I see what you mean. Maybe this could do with a bit more thought.
> I was thinking that there are two scenarios, the common cache for all
> images and the context cache for instances of rendering.
> With a situation such as cocoon we could have a third based on the
> cocoon context and this may be more easily handled within the component
> manager. Everything else should remain the same I think.
Sounds good. To keep up I would really have to dive in. Too bad.
<snip/>
> Any help is much appreciated.
> I just want to get the ball rolling with the intentions.
> We should be able to tackle this in parts.
Yes, absolutely. I'm sure we can get more Avalon stuff in when the time
is right. Going with Logger/LogEnabled and Configuration/Configurable
for now is good enough. I'd just like to say that it's already half the
way if stuff gets split up into interface and implementation. This makes
one think more about exchanging implementations and helps a lot when
moving in more of Avalon.
By the way: There's also some new CascadingConfiguration class in
Excalibur that enables overloading of values. This may help with overall
configuration, too.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] configuration
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Wed, 2002-05-29 at 17:18, Jeremias Maerki wrote:
> > - Configurable FOUserAgent (have default FOUserAgent that can be
> > used/extended without config)
> > To make it possible to setup all the various options like dpi.
>
> I'm still at a lack of knowledge on these new things. :-( But it sounds
> reasonable. I think a lot of thinking when using Avalon goes into which
> classes are components (they get a logger, configuration etc. and
> provide some sort of service) and which are merely data-holding classes
> like an InlineArea. Correct me if I'm wrong: UserAgents are those
> classes that do the heavy work that was formerly distributed in many
> different classes directly on classes that change into simple
> data-holding classes at the moment.
That is essentially it.
The FOUserAgent holds a bunch of decision making values that people may
want to change.
> > The image cache and other cache are similar. These can be set with a
> > static method and through the driver respectively.
>
> I'd like to avoid the static stuff, if possible. There's the concept of
> a ComponentManager (or after an evoluntionary step the ServiceManager),
> which allows components to look up services provided by the
> container/parent. There are multiple implementations in Avalon:
> ExcaliburComponentManager (ECM), Fortress, Merlin, Phoenix. Using this
> mechanism forces us to think again about some interfaces, or helps us to
> easily provide multiple implementations of the same interface.
I see what you mean. Maybe this could do with a bit more thought.
I was thinking that there are two scenarios, the common cache for all
images and the context cache for instances of rendering.
With a situation such as cocoon we could have a third based on the
cocoon context and this may be more easily handled within the component
manager. Everything else should remain the same I think.
> I can only say this: restructuring FOP to use this concept means some
> work. We've done it for our applications and we love the result. I'm
> sure Nicola Ken Barozzi can help here. I can help, too, I want to. I
> just can't invest so much time as would be necessary at the moment. I'll
> have 5 weeks off in August from which I intend to invest at least a week
> into FOP. What I propose here is just my personal opinion and I can
> understand if you, Keiron, don't want to be braked by having to dive too
> much into Avalon. But I'm trying to help as much as possible. I'm
> drowning in work but try heavily to get out of this.
>
> There's not only cache components (for which Avalon Excalibur may
> provide some helpful stuff), but also things such as an URI/URL-Resolver
> (adopted by Excalibur from Cocoon) which may be an interesting feature
> and may improve the integration with Cocoon. Actually, using Avalon
> helps integration with Cocoon in a general sense. I'm also thinking
> about creating a font facility which can manage fonts across renderers.
> There may also be little components like a table column builder for
> which different implementations are thinkable. We've had two different
> approaches on line-breaking, right? I'm sure there are others.
>
> I think, looking at Cocoon is inspiring. How they cleanly split up the
> system into highly configurable and exchangeable parts. And it helps
> killing those multi-threading problems (I hope).
>
> There has been some discussions about configuration. There's always the
> distinction between system configuration or component setup on one side
> and calling parameters (ex. from the command line or from calling a
> method on Driver) on the other. I've seen the latter having been handled
> through Avalon's Context interface. Maybe this is not even necessary. I
> think this may have to be investigated further. We can always ask the
> Avalon guys who are eager to help when someone (especially an Apache
> project) wants to adopt their patterns. I can be contact person. I'm
> working with Avalon for about 9 months, but I'm not a specialist, yet.
> Maybe Nicola Ken Barozzi also wants help out a bit. I think he offered
> his help at one point.
>
> So much from me at the moment. I hope I contributed some constructive
> words and that you guys understand what I'm trying to tell. I know that
> I'm not a pro in this regard.
Any help is much appreciated.
I just want to get the ball rolling with the intentions.
We should be able to tackle this in parts.
Keiron.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] configuration
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Jeremias Maerki" <je...@outline.ch>
> > In a server environment especially, good role hierarchy and containment
is
> > paramount, and Avalon helps to enforce and use it.
> >
> > One thing though: Logging is a bit different than other things... it's
not
> > really a component, but an aspect.
> > This means that we would need another programming language to use it
> > correctly from a framework POV...
> >
> > In practice, I have seen that the best thing is making the big blocks
get a
> > Logger from the parent, and have the smaller classes get it from a
static
> > method that permits the usage of a "key", that in the case of important
> > classes can be set from the outside.
>
>That surprises me a little. I tend to extend from AbstractLogEnabled
> even for small classes if I need a Logger. But you're probably right
> that this reduces memory usage especially if you have a lot of small
> objects like we have in FOP.
The fact that you are surprised is a good sign, because it means that you
come from a purist view of IoC, which is always the best place to start
from.
I had your same vision till I tried implementing logging in Jakarta POI... a
nightmare!
Hundreds of classes, that were used as the object model, and it soon became
not only slow but impractical.
If I forgot to set a logger for a child class, the whole thing would crash
with a NPE.
I've come to the conclusion that smaller classes that are not really
components are better of with a static system, since they use logging only
during debugging. In this case JDK1.4 style logging is the best, since it
can be removed compile-time.
This becomes not correct with bigger Components, where Logging is part of
the usage too, like server Components that log accesses for example.
In this case Avalon Logging framework has indeed no true rivals :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] configuration
Posted by Jeremias Maerki <je...@outline.ch>.
> Sorry if I'm not replying inline, but with some mails Outlook Express seems
> to be unable to properly add >>> s . :-( (If anyone knows a workaround,
> please let me know)
You must have think nerves that you work with Outlook Express. :-)
> Anyway, your description is correct, and very well done.
Thanks. :-)
> One of the main points in avalon is the IoC (inversion of control), where
> the Container pushes things to the Components.
>
> Static accessors are bad in this regard, as they make the Component ask
> something to a class that is not even a container. This usually brings to
> the problems FOP has had with config until now.
>
> In a server environment especially, good role hierarchy and containment is
> paramount, and Avalon helps to enforce and use it.
>
> One thing though: Logging is a bit different than other things... it's not
> really a component, but an aspect.
> This means that we would need another programming language to use it
> correctly from a framework POV...
>
> In practice, I have seen that the best thing is making the big blocks get a
> Logger from the parent, and have the smaller classes get it from a static
> method that permits the usage of a "key", that in the case of important
> classes can be set from the outside.
That surprises me a little. I tend to extend from AbstractLogEnabled
even for small classes if I need a Logger. But you're probably right
that this reduces memory usage especially if you have a lot of small
objects like we have in FOP.
> As for helping, I will be happy to do so.
> Unfortunately I have not had time till now to give an active hand, but now I
> can find some time.
Great!!!
> The good news is that Forrest is running (http://xml.apache.org/forrest/)
> and that we are starting to convert the xml.apache projects to use the new
> DTD.
> Since you have showed interest, FOP will be one of the first projects to
> have the site automatically published by Forrest :-)
I'm looking forward to it.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] configuration
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sorry if I'm not replying inline, but with some mails Outlook Express seems
to be unable to properly add >>> s . :-( (If anyone knows a workaround,
please let me know)
Anyway, your description is correct, and very well done.
One of the main points in avalon is the IoC (inversion of control), where
the Container pushes things to the Components.
Static accessors are bad in this regard, as they make the Component ask
something to a class that is not even a container. This usually brings to
the problems FOP has had with config until now.
In a server environment especially, good role hierarchy and containment is
paramount, and Avalon helps to enforce and use it.
One thing though: Logging is a bit different than other things... it's not
really a component, but an aspect.
This means that we would need another programming language to use it
correctly from a framework POV...
In practice, I have seen that the best thing is making the big blocks get a
Logger from the parent, and have the smaller classes get it from a static
method that permits the usage of a "key", that in the case of important
classes can be set from the outside.
As for helping, I will be happy to do so.
Unfortunately I have not had time till now to give an active hand, but now I
can find some time.
The good news is that Forrest is running (http://xml.apache.org/forrest/)
and that we are starting to convert the xml.apache projects to use the new
DTD.
Since you have showed interest, FOP will be one of the first projects to
have the site automatically published by Forrest :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
----- Original Message -----
From: "Jeremias Maerki" <je...@outline.ch>
To: <fo...@xml.apache.org>
Sent: Wednesday, May 29, 2002 5:18 PM
Subject: Re: [REDESIGN] configuration
> Here are some ideas about how we could do the configuration for FOP.
> Comments are welcome.
>
> Use this class and various supporting classs (already in avalon
> framework jar):
> org.apache.avalon.framework.configuration.Configuration
>
> From a brief look at how this works it should be quite easy to use. We
> just need to decide on an appropriate xml structure. I have attached an
> example.
It is. I'm using this stuff every day.
> This can be used either with an xml file on the command line or through
> embedding, eg. cocoon could pass a fop configuration class.
> If the classes are not configured then default values are used.
>
> Configurable classes:
I'd like to elaborate because I'm not sure that everyone is familiar
with Avalon's concepts: These classes will implement the "Configurable"
interface from Avalon. Following the concept of IoC (those who are not
familiar with this term, please look up Avalon docs) the configuration
is set by the container (ex. Cocoon or our command-line wrapper) on the
child (Driver, Renderer etc.).
> - Driver
> Passes configuration to user agent if not already set and to renderers.
Right. Driver will probably still remain our top-level component,
serving as a black-box of the whole FOP-process.
> - All renderers (ie. Renderer, StructureHandler implements)
> This is so that the renderer can get its own specific information.
> The PDFRenderer could have font setup, stream filters etc.
Correct. That's something I'm burning to do for a long time. PSRenderer
will get very configurable eventually.
> - Configurable FOUserAgent (have default FOUserAgent that can be
> used/extended without config)
> To make it possible to setup all the various options like dpi.
I'm still at a lack of knowledge on these new things. :-( But it sounds
reasonable. I think a lot of thinking when using Avalon goes into which
classes are components (they get a logger, configuration etc. and
provide some sort of service) and which are merely data-holding classes
like an InlineArea. Correct me if I'm wrong: UserAgents are those
classes that do the heavy work that was formerly distributed in many
different classes directly on classes that change into simple
data-holding classes at the moment.
>
> ----------
>
> The logkit Logger can be configured using this but it is not
> appropriate. If FOP is run from the command line then it should do what
> it already does and when embedding it would setup its own logger.
Logging is also something that is set on the child by its container. The
command-line wrapper sets a simple ConsoleLogger on the Driver by using
the LogEnabled interface.
Other containers like Cocoon will configure their Logging somewhere else
and set the desired Logger using LogEnabled on Driver, which in turn
passes some child logger of the given one to its children.
>
> The image cache and other cache are similar. These can be set with a
> static method and through the driver respectively.
I'd like to avoid the static stuff, if possible. There's the concept of
a ComponentManager (or after an evoluntionary step the ServiceManager),
which allows components to look up services provided by the
container/parent. There are multiple implementations in Avalon:
ExcaliburComponentManager (ECM), Fortress, Merlin, Phoenix. Using this
mechanism forces us to think again about some interfaces, or helps us to
easily provide multiple implementations of the same interface.
I can only say this: restructuring FOP to use this concept means some
work. We've done it for our applications and we love the result. I'm
sure Nicola Ken Barozzi can help here. I can help, too, I want to. I
just can't invest so much time as would be necessary at the moment. I'll
have 5 weeks off in August from which I intend to invest at least a week
into FOP. What I propose here is just my personal opinion and I can
understand if you, Keiron, don't want to be braked by having to dive too
much into Avalon. But I'm trying to help as much as possible. I'm
drowning in work but try heavily to get out of this.
There's not only cache components (for which Avalon Excalibur may
provide some helpful stuff), but also things such as an URI/URL-Resolver
(adopted by Excalibur from Cocoon) which may be an interesting feature
and may improve the integration with Cocoon. Actually, using Avalon
helps integration with Cocoon in a general sense. I'm also thinking
about creating a font facility which can manage fonts across renderers.
There may also be little components like a table column builder for
which different implementations are thinkable. We've had two different
approaches on line-breaking, right? I'm sure there are others.
I think, looking at Cocoon is inspiring. How they cleanly split up the
system into highly configurable and exchangeable parts. And it helps
killing those multi-threading problems (I hope).
There has been some discussions about configuration. There's always the
distinction between system configuration or component setup on one side
and calling parameters (ex. from the command line or from calling a
method on Driver) on the other. I've seen the latter having been handled
through Avalon's Context interface. Maybe this is not even necessary. I
think this may have to be investigated further. We can always ask the
Avalon guys who are eager to help when someone (especially an Apache
project) wants to adopt their patterns. I can be contact person. I'm
working with Avalon for about 9 months, but I'm not a specialist, yet.
Maybe Nicola Ken Barozzi also wants help out a bit. I think he offered
his help at one point.
So much from me at the moment. I hope I contributed some constructive
words and that you guys understand what I'm trying to tell. I know that
I'm not a pro in this regard.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] configuration
Posted by Jeremias Maerki <je...@outline.ch>.
> Here are some ideas about how we could do the configuration for FOP.
> Comments are welcome.
>
> Use this class and various supporting classs (already in avalon
> framework jar):
> org.apache.avalon.framework.configuration.Configuration
>
> From a brief look at how this works it should be quite easy to use. We
> just need to decide on an appropriate xml structure. I have attached an
> example.
It is. I'm using this stuff every day.
> This can be used either with an xml file on the command line or through
> embedding, eg. cocoon could pass a fop configuration class.
> If the classes are not configured then default values are used.
>
> Configurable classes:
I'd like to elaborate because I'm not sure that everyone is familiar
with Avalon's concepts: These classes will implement the "Configurable"
interface from Avalon. Following the concept of IoC (those who are not
familiar with this term, please look up Avalon docs) the configuration
is set by the container (ex. Cocoon or our command-line wrapper) on the
child (Driver, Renderer etc.).
> - Driver
> Passes configuration to user agent if not already set and to renderers.
Right. Driver will probably still remain our top-level component,
serving as a black-box of the whole FOP-process.
> - All renderers (ie. Renderer, StructureHandler implements)
> This is so that the renderer can get its own specific information.
> The PDFRenderer could have font setup, stream filters etc.
Correct. That's something I'm burning to do for a long time. PSRenderer
will get very configurable eventually.
> - Configurable FOUserAgent (have default FOUserAgent that can be
> used/extended without config)
> To make it possible to setup all the various options like dpi.
I'm still at a lack of knowledge on these new things. :-( But it sounds
reasonable. I think a lot of thinking when using Avalon goes into which
classes are components (they get a logger, configuration etc. and
provide some sort of service) and which are merely data-holding classes
like an InlineArea. Correct me if I'm wrong: UserAgents are those
classes that do the heavy work that was formerly distributed in many
different classes directly on classes that change into simple
data-holding classes at the moment.
>
> ----------
>
> The logkit Logger can be configured using this but it is not
> appropriate. If FOP is run from the command line then it should do what
> it already does and when embedding it would setup its own logger.
Logging is also something that is set on the child by its container. The
command-line wrapper sets a simple ConsoleLogger on the Driver by using
the LogEnabled interface.
Other containers like Cocoon will configure their Logging somewhere else
and set the desired Logger using LogEnabled on Driver, which in turn
passes some child logger of the given one to its children.
>
> The image cache and other cache are similar. These can be set with a
> static method and through the driver respectively.
I'd like to avoid the static stuff, if possible. There's the concept of
a ComponentManager (or after an evoluntionary step the ServiceManager),
which allows components to look up services provided by the
container/parent. There are multiple implementations in Avalon:
ExcaliburComponentManager (ECM), Fortress, Merlin, Phoenix. Using this
mechanism forces us to think again about some interfaces, or helps us to
easily provide multiple implementations of the same interface.
I can only say this: restructuring FOP to use this concept means some
work. We've done it for our applications and we love the result. I'm
sure Nicola Ken Barozzi can help here. I can help, too, I want to. I
just can't invest so much time as would be necessary at the moment. I'll
have 5 weeks off in August from which I intend to invest at least a week
into FOP. What I propose here is just my personal opinion and I can
understand if you, Keiron, don't want to be braked by having to dive too
much into Avalon. But I'm trying to help as much as possible. I'm
drowning in work but try heavily to get out of this.
There's not only cache components (for which Avalon Excalibur may
provide some helpful stuff), but also things such as an URI/URL-Resolver
(adopted by Excalibur from Cocoon) which may be an interesting feature
and may improve the integration with Cocoon. Actually, using Avalon
helps integration with Cocoon in a general sense. I'm also thinking
about creating a font facility which can manage fonts across renderers.
There may also be little components like a table column builder for
which different implementations are thinkable. We've had two different
approaches on line-breaking, right? I'm sure there are others.
I think, looking at Cocoon is inspiring. How they cleanly split up the
system into highly configurable and exchangeable parts. And it helps
killing those multi-threading problems (I hope).
There has been some discussions about configuration. There's always the
distinction between system configuration or component setup on one side
and calling parameters (ex. from the command line or from calling a
method on Driver) on the other. I've seen the latter having been handled
through Avalon's Context interface. Maybe this is not even necessary. I
think this may have to be investigated further. We can always ask the
Avalon guys who are eager to help when someone (especially an Apache
project) wants to adopt their patterns. I can be contact person. I'm
working with Avalon for about 9 months, but I'm not a specialist, yet.
Maybe Nicola Ken Barozzi also wants help out a bit. I think he offered
his help at one point.
So much from me at the moment. I hope I contributed some constructive
words and that you guys understand what I'm trying to tell. I know that
I'm not a pro in this regard.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] configuration
Posted by Jeremias Maerki <je...@outline.ch>.
So do I. Maybe we have to hold the version in a separate XML file and
put that into a Java class or a manifest file using XSLT during build.
> On Wed, 2002-05-29 at 16:32, Peter B. West wrote:
> > Keiron,
> >
> > I can't comment on the details of this unless and until I look at
> > avalon. I notice, though, that version is still given as a
> > configuration parameter. Does that mean that a user can arbitrarily
> > change the FOP version? My point, of course, is that version has
> > nothing to do with configuration.
> >
> > Peter
>
> That is a bit of confusing. I never even noticed.
> That version is the version of the configuration, not the version of
> FOP.
> I don't think the FOP version has a place in this configuration.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] configuration
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Wed, 2002-05-29 at 16:32, Peter B. West wrote:
> Keiron,
>
> I can't comment on the details of this unless and until I look at
> avalon. I notice, though, that version is still given as a
> configuration parameter. Does that mean that a user can arbitrarily
> change the FOP version? My point, of course, is that version has
> nothing to do with configuration.
>
> Peter
That is a bit of confusing. I never even noticed.
That version is the version of the configuration, not the version of
FOP.
I don't think the FOP version has a place in this configuration.
Keiron.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] configuration
Posted by "Peter B. West" <pb...@powerup.com.au>.
Keiron,
I can't comment on the details of this unless and until I look at
avalon. I notice, though, that version is still given as a
configuration parameter. Does that mean that a user can arbitrarily
change the FOP version? My point, of course, is that version has
nothing to do with configuration.
Peter
Keiron Liddle wrote:
>Hi,
>
>Here are some ideas about how we could do the configuration for FOP.
>Comments are welcome.
>
>Use this class and various supporting classs (already in avalon
>framework jar):
>org.apache.avalon.framework.configuration.Configuration
>
>
....
><fop version="1.0">
>
><base url="./"/>
>
><fop>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org