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/09/04 10:35:48 UTC
Re: [FOP Avalonization] Status update + recent discussion on
Avalon dev
Hi,
I will remove the old configuration stuff so you don't have to deal with
it. Committing soon...
On Tue, 2002-09-03 at 16:11, Nicola Ken Barozzi wrote:
> Following the need to make use of the resolver in Avalon, I started
> implementing it.
>
> Using the Resolver in the ImageFactory itself is easy enough, but I
> wanted to make a service out of it, to manage it properly, and came to a
> problem: how the heck is the class that needs it going to get that service?
>
> Usually, for Components it's the Container that gives the
> ServiceManager, from which the services are accessible, but here it's a
> mess to do it everywhere, like for logging.
It doesn't really belong everywhere and only certain sections need it
anyway. The problem is that the parts are in the middle of everything.
> So I was unsure on how to continue, and here is the thread that came out:
> http://nagoya.apache.org/eyebrowse/BrowseList?listName=avalon-dev@jakarta.apache.org&by=thread&from=233005
>
> Basically the point is that these objects should not request a service,
> they should be given already the resolved URL somewhat by the creator.
> The system should not be Active, so that an external builder can do it.
>
> Example:
>
> Instead of
>
> method(unresolvedparam){
> resolved = getService().resolve(unresolvedparam)
> use(resolved);
> }
>
> I should do
>
> method(resolved ){
> use(resolved);
> }
Is it possible to resolve a URL without trying to load it? What is the
proper way to handle that?
> This means that whoever calls the method should be able to resolve it,
> or in turn has to be given it already resolved.
>
> There are other ways, but this is the best IMHO.
>
> The question is, how can it integrate with FOP current and next2be design?
There is also other bit like embedded fonts
> --
> 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: [FOP Avalonization] Status update + recent discussion on Avalon
dev
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeremias Maerki wrote:
> The wiki is nice. Should we continue to discuss on this list (or on
> commons-dev if appropriate) or in the wiki or both? I don't like
> redundancy.
I tend to use a Wiki for conclusions we get to and important parts of
the discussion.
As for the discussion, since it's about FOP, I suggest a crosspost with
commons and FOP.
And make the important things go in the Wiki too.
> Does the wiki have email-notification when changes are made? I've seen
> no such thing. That way we could discuss in the wiki.
I can set it up, but where should it notify?
The Wiki is not only for Morphos, there are other projects that use it.
> By the way, I've added the API requirements document to the wiki for
> reference.
:-)
--
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: [FOP Avalonization] Status update + recent discussion on Avalon dev
Posted by Jeremias Maerki <de...@greenmail.ch>.
The wiki is nice. Should we continue to discuss on this list (or on
commons-dev if appropriate) or in the wiki or both? I don't like
redundancy.
Does the wiki have email-notification when changes are made? I've seen
no such thing. That way we could discuss in the wiki.
By the way, I've added the API requirements document to the wiki for
reference.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [FOP Avalonization] Status update + recent discussion on Avalon
dev
Posted by Nicola Ken Barozzi <ni...@apache.org>.
I've set up a wiki for this discussion and others on Morhos here:
http://metamorphosis.krysalis.org/cgi-bin/mmorphosiswiki.pl?MorPhos
The page about Fop:
http://metamorphosis.krysalis.org/cgi-bin/mmorphosiswiki.pl?FopMorpher
Jeremias Maerki wrote:
> On 05.09.2002 10:20:07 Nicola Ken Barozzi wrote:
>
>>Jeremias Maerki wrote:
>>
>>>On 04.09.2002 14:26:14 Nicola Ken Barozzi wrote:
...
>>See that discussion I had on the Avalon list about this:
>>http://nagoya.apache.org/eyebrowse/BrowseList?listName=avalon-dev@jakarta.apache.org&by=thread&from=233005
>
> I've read it. At a high level I knew some of it even before that thread.
> The separation of data holder classes (FO tree, PDF objects) from
> builder (FOTreeBuilder) or writer (a future PDFSerializer) classes, for
> example. My problem is the "how to do it in reality". I'm not a good
> conceptual thinker. I usually code and then refactor until I am happy.
> That's why I sometimes have problems following the very interesting
> discussions on Avalon-Dev.
Then it means we are a balanced duo... I have your opposite problem ;-)
>>>>Let's start with touching the .apps.* package, it's the one that imposes
>>>>bad constraint to the rest of the structure.
>>>
>>>
>>>That's ok with me.
>>
>>I have set up UML graphs of current CVS (without codegen) here:
>>http://cvs.apache.org/~nicolaken/fopUML/overview.html
>
> <snip/>
>
...
> With
> "adding a few things" I thought these might be FOP specific additions. I
> don't think that our additional requirements can or should be included
> in Morphos. IMO Morphos should stay as simple as possible but should be
> extensible.
We'll see point per point if-where it makes sense.
>>>Have you had any ideas in this direction or do I already run in the
>>>wrong direction again?
>>>
>>>I thought once about having two basic APIs:
>>>1. An expert interface in Avalon style that covers all technical requirements.
>>>2. A simple interface for novice users that wraps the complex interface.
>>>
>>>Maybe this is not even necessary.
>>
>>Hmmm...
>>
>>I think that a revamped Morphos API can be both simple and powerful,
>>since properties should be set via bean-style methods.
>
>
> At least for FOP I don't think I would want to set all configurable
> stuff by using bean-style methods. That might get overwhelming. There
> are so many things that can be configurable. I'd rather stay with an XML
> config file especially since FOP config is rather static over time and
> within an installation (my experience). It's rather unlike XSLT where
> the parameters change for each transformation.
fop.setConfig(Configuration conf);
bean-style ;-)
> <snip/>
>
>>>Let me know how I can help. At the moment I don't see how I can be of
>>>assistance. In the meantime I'll set up checkstyle as I promised and
>>>see if I can start to put together a code convention document.
>>
>>Hmmm...
>>I propose this:
>>http://jakarta.apache.org/poi/resolutions/res001.html
>
>
> I've seen that one. It's a good idea but I'd like just a tick more. I
> don't want tabs hanging around, for example. Just a few little things
> that make life easier.
Ok.
Tabs are part of it, yes, just don't everspecify the details 8-)
> A little brain-dump (don't know if it's useful):
> Would it make sense to implement a FOPMorpherFactory that's actually the
> top-level container for FOP? The Morpher built by the factory would also
> be a container but with the factory as parent. That may also help solve
> the problem cache problem: We need caches that live forever and caches
> that live during a FOP run. The Factory would be configured with the
> xml config. The Morpher might then still be parameterized if necessary.
Added this to the wiki. Please add discussion snippets to the wiki, so
we have a nice discussion history
http://metamorphosis.krysalis.org/cgi-bin/mmorphosiswiki.pl?FopMorpher
My reply:
''Nicola Ken Barozzi'' Well, containers expose services, and and
MorpherFactory exposes services, the Morphers. But it exposes it based
on a key or on the ObjectFlavors of input and output.
It does not act further on the instance it created, because it's meant
to be used as an indipendent service.
Once you have a Morpher, you can confugure it and run it multiple times.
The point though that you need two Morpher config systems, one per
Morpher service instance, and one per Run.
Currently we do not support config per run explicitly.
The fact is that we can have the Morpher in a pipeline; how can-should
the pipeline give the Morpher its '''per run config
'''?
--
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: [FOP Avalonization] Status update + recent discussion on Avalon dev
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 05.09.2002 10:20:07 Nicola Ken Barozzi wrote:
>
> Jeremias Maerki wrote:
> > On 04.09.2002 14:26:14 Nicola Ken Barozzi wrote:
> >
> >>Jeremias Maerki wrote:
> >>
> >>>On 04.09.2002 13:42:50 Nicola Ken Barozzi wrote:
> >>>
> >>>
> >>>>Jeremias Maerki wrote:
> >>>
> >>...
> >>
> >>>>>What do you have in mind to use as container? I've started using
> >>>>>Fortress yesterday for a little private project and I liked it very much.
> >>>>>Much better than the ECM.
> >>>>
> >>>>I would not use a container at all ATM.
> >>>
> >>>That means you just concentrate on the top-level component? FOP insides
> >>>at a later time?
> >>
> >>Yes.
> >>Well, if we *ever* will want to apply Avalon to the insides.
> >
> > But one of your goals is the use of Excalibur's SourceResolver which
> > means you automatically start using Avalon in the insides.
>
> Aha! :-D
>
> Here is the point. We must use the resolver at the most high level
> possible, and make the resolving happen not inside the data objects, but
> inside the builder that assembles them, so that they are already resolved.
>
> Or we can supply a special context to the calls that encapsulate the
> functionality Fop exposes to its data objects; this hides the underlying
> avalon in teh data model.
>
> See that discussion I had on the Avalon list about this:
> http://nagoya.apache.org/eyebrowse/BrowseList?listName=avalon-dev@jakarta.apache.org&by=thread&from=233005
I've read it. At a high level I knew some of it even before that thread.
The separation of data holder classes (FO tree, PDF objects) from
builder (FOTreeBuilder) or writer (a future PDFSerializer) classes, for
example. My problem is the "how to do it in reality". I'm not a good
conceptual thinker. I usually code and then refactor until I am happy.
That's why I sometimes have problems following the very interesting
discussions on Avalon-Dev.
> >>Let's start with touching the .apps.* package, it's the one that imposes
> >>bad constraint to the rest of the structure.
> >
> >
> > That's ok with me.
>
> I have set up UML graphs of current CVS (without codegen) here:
> http://cvs.apache.org/~nicolaken/fopUML/overview.html
Cool, thanks.
<snip/>
> > That
> > means we can build up from Morphos. The only problem I see is the
> > additional API requirements that are primarily used in more complex
> > environments. The Morphos interfaces are not enough there.
>
> Morphos is in Jakarta Commons scratchpad for all to see and use.
>
> Morphos is still in the definition stage, so suggestions and RFE are not
> only welcome, but *needed* :-)
>
> > We would need
> > to add a few things. And that's where I don't know yet how to do this.
>
> There was a vote some months back about giving access also to Xml.Apache
> devs, and it went well, but they have not yet acted on it.
> If anyone needs access, I'll see you get it.
Don't know yet if I need access, but it's good to have this option. With
"adding a few things" I thought these might be FOP specific additions. I
don't think that our additional requirements can or should be included
in Morphos. IMO Morphos should stay as simple as possible but should be
extensible.
> > Have you had any ideas in this direction or do I already run in the
> > wrong direction again?
> >
> > I thought once about having two basic APIs:
> > 1. An expert interface in Avalon style that covers all technical requirements.
> > 2. A simple interface for novice users that wraps the complex interface.
> >
> > Maybe this is not even necessary.
>
> Hmmm...
>
> I think that a revamped Morphos API can be both simple and powerful,
> since properties should be set via bean-style methods.
At least for FOP I don't think I would want to set all configurable
stuff by using bean-style methods. That might get overwhelming. There
are so many things that can be configurable. I'd rather stay with an XML
config file especially since FOP config is rather static over time and
within an installation (my experience). It's rather unlike XSLT where
the parameters change for each transformation.
> I really don't know, let's just do one and see what it looks like.
That's my thinking. :-)
<snip/>
> > Let me know how I can help. At the moment I don't see how I can be of
> > assistance. In the meantime I'll set up checkstyle as I promised and
> > see if I can start to put together a code convention document.
>
> Hmmm...
> I propose this:
> http://jakarta.apache.org/poi/resolutions/res001.html
I've seen that one. It's a good idea but I'd like just a tick more. I
don't want tabs hanging around, for example. Just a few little things
that make life easier.
A little brain-dump (don't know if it's useful):
Would it make sense to implement a FOPMorpherFactory that's actually the
top-level container for FOP? The Morpher built by the factory would also
be a container but with the factory as parent. That may also help solve
the problem cache problem: We need caches that live forever and caches
that live during a FOP run. The Factory would be configured with the
xml config. The Morpher might then still be parameterized if necessary.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [FOP Avalonization] Status update + recent discussion on Avalon
dev
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeremias Maerki wrote:
> On 04.09.2002 14:26:14 Nicola Ken Barozzi wrote:
>
>>Jeremias Maerki wrote:
>>
>>>On 04.09.2002 13:42:50 Nicola Ken Barozzi wrote:
>>>
>>>
>>>>Jeremias Maerki wrote:
>>>
>>...
>>
>>>>>What do you have in mind to use as container? I've started using
>>>>>Fortress yesterday for a little private project and I liked it very much.
>>>>>Much better than the ECM.
>>>>
>>>>I would not use a container at all ATM.
>>>
>>>That means you just concentrate on the top-level component? FOP insides
>>>at a later time?
>>
>>Yes.
>>Well, if we *ever* will want to apply Avalon to the insides.
>
> But one of your goals is the use of Excalibur's SourceResolver which
> means you automatically start using Avalon in the insides.
Aha! :-D
Here is the point. We must use the resolver at the most high level
possible, and make the resolving happen not inside the data objects, but
inside the builder that assembles them, so that they are already resolved.
Or we can supply a special context to the calls that encapsulate the
functionality Fop exposes to its data objects; this hides the underlying
avalon in teh data model.
See that discussion I had on the Avalon list about this:
http://nagoya.apache.org/eyebrowse/BrowseList?listName=avalon-dev@jakarta.apache.org&by=thread&from=233005
>>Let's start with touching the .apps.* package, it's the one that imposes
>>bad constraint to the rest of the structure.
>
>
> That's ok with me.
I have set up UML graphs of current CVS (without codegen) here:
http://cvs.apache.org/~nicolaken/fopUML/overview.html
>>>>Fop is not an app, but rather a Component itself.
>>>>It needs other services, but doesn't need necessarily a container.
>>>>
>>>>Fop *is* the container, and the Renderers are the Components.
>>>>
>>>>So I would like to see Driver become a Container that can manage the
>>>>Renderers like Components.
>>>>Not much different from what is now, but with a cleaner separation of
>>>>concerns.
>>>>
>>>>In this way the Avalonization is limited to the main services used in
>>>>Fop, and the finer specific logic, which is the *real* core of Fop and
>>>>that all are working on remains exactly as-is.
>>>>
>>>>This gives the maximum advantage with the least problems.
>>>
>>>Actually, that's sort of what I had in mind. We could use Fortress as
>>>base for the container, right?
>>
>>I would not use fortress at all.
>>Look at http://jakarta.apache.org/avalon/excalibur/tweety/ .
>>
>>I would just rup off the code from there and create a minimalistic
>>container that does it all programmatically.
>>
>>We can expand later, let's keep it simple.
>
>
> I get your point and agree. That will also make it easier for the others
> to get up to speed with this container stuff.
*Exactly* :-D
>>>>I'm looking into the Driver class and studying it; there are some
>>>>strange relationships between all the .apps.*, I'm finding the cleanest
>>>>solution.
>>>>
>>>>Probably most of that package will be rewritten, but the rest should
>>>>mainly remain untouched.
>>>
>>>
>>>FOP has to have a very simple API to the outside world and should work
>>>as a blackbox. Something similar to JAXP or your Morphos.
>>
>>Yes.
>>In fact the interface from the outside world is the same of Morphos...
>
>
> While writing the API requirements document yesterday evening I realized
> that the Morpher interface is exactly representing what FOP does.
:-D
> That
> means we can build up from Morphos. The only problem I see is the
> additional API requirements that are primarily used in more complex
> environments. The Morphos interfaces are not enough there.
Morphos is in Jakarta Commons scratchpad for all to see and use.
Morphos is still in the definition stage, so suggestions and RFE are not
only welcome, but *needed* :-)
> We would need
> to add a few things. And that's where I don't know yet how to do this.
There was a vote some months back about giving access also to Xml.Apache
devs, and it went well, but they have not yet acted on it.
If anyone needs access, I'll see you get it.
> Have you had any ideas in this direction or do I already run in the
> wrong direction again?
>
> I thought once about having two basic APIs:
> 1. An expert interface in Avalon style that covers all technical requirements.
> 2. A simple interface for novice users that wraps the complex interface.
>
> Maybe this is not even necessary.
Hmmm...
I think that a revamped Morphos API can be both simple and powerful,
since properties should be set via bean-style methods.
I really don't know, let's just do one and see what it looks like.
>>>Maybe you want to have a look at the API discussion we had a couple of
>>>months ago. I've got a pretty good idea how the API should look like but I
>>>failed to present my own proposal which basically builds on this
>>>discussion.
>>>http://marc.theaimsgroup.com/?t=102288093500008&r=1&w=2
>>
>>Yes, I remember it.
>>
>>But let's fly down still, and concentrate on the Driver.
>>When that's reasonably done, we will see where it makes sense to drive
>>up the hierarchy.
>>
>>
>>
>>>I'm going to work that up during the next few hours. Maybe this helps.
>>
>>Good, let us know :-)
>>
>>In the meantime, I'll set up a UML diagram for current CVS FOP.
>
>
> Let me know how I can help. At the moment I don't see how I can be of
> assistance. In the meantime I'll set up checkstyle as I promised and
> see if I can start to put together a code convention document.
Hmmm...
I propose this:
http://jakarta.apache.org/poi/resolutions/res001.html
--
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: [FOP Avalonization] Status update + recent discussion on Avalon dev
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 04.09.2002 14:26:14 Nicola Ken Barozzi wrote:
>
> Jeremias Maerki wrote:
> > On 04.09.2002 13:42:50 Nicola Ken Barozzi wrote:
> >
> >>Jeremias Maerki wrote:
> ...
> >>>What do you have in mind to use as container? I've started using
> >>>Fortress yesterday for a little private project and I liked it very much.
> >>>Much better than the ECM.
> >>
> >>I would not use a container at all ATM.
> >
> > That means you just concentrate on the top-level component? FOP insides
> > at a later time?
>
> Yes.
> Well, if we *ever* will want to apply Avalon to the insides.
But one of your goals is the use of Excalibur's SourceResolver which
means you automatically start using Avalon in the insides.
> Let's start with touching the .apps.* package, it's the one that imposes
> bad constraint to the rest of the structure.
That's ok with me.
> >>Fop is not an app, but rather a Component itself.
> >>It needs other services, but doesn't need necessarily a container.
> >>
> >>Fop *is* the container, and the Renderers are the Components.
> >>
> >>So I would like to see Driver become a Container that can manage the
> >>Renderers like Components.
> >>Not much different from what is now, but with a cleaner separation of
> >>concerns.
> >>
> >>In this way the Avalonization is limited to the main services used in
> >>Fop, and the finer specific logic, which is the *real* core of Fop and
> >>that all are working on remains exactly as-is.
> >>
> >>This gives the maximum advantage with the least problems.
> >
> > Actually, that's sort of what I had in mind. We could use Fortress as
> > base for the container, right?
>
> I would not use fortress at all.
> Look at http://jakarta.apache.org/avalon/excalibur/tweety/ .
>
> I would just rup off the code from there and create a minimalistic
> container that does it all programmatically.
>
> We can expand later, let's keep it simple.
I get your point and agree. That will also make it easier for the others
to get up to speed with this container stuff.
> >>I'm looking into the Driver class and studying it; there are some
> >>strange relationships between all the .apps.*, I'm finding the cleanest
> >>solution.
> >>
> >>Probably most of that package will be rewritten, but the rest should
> >>mainly remain untouched.
> >
> >
> > FOP has to have a very simple API to the outside world and should work
> > as a blackbox. Something similar to JAXP or your Morphos.
>
> Yes.
> In fact the interface from the outside world is the same of Morphos...
While writing the API requirements document yesterday evening I realized
that the Morpher interface is exactly representing what FOP does. That
means we can build up from Morphos. The only problem I see is the
additional API requirements that are primarily used in more complex
environments. The Morphos interfaces are not enough there. We would need
to add a few things. And that's where I don't know yet how to do this.
Have you had any ideas in this direction or do I already run in the
wrong direction again?
I thought once about having two basic APIs:
1. An expert interface in Avalon style that covers all technical requirements.
2. A simple interface for novice users that wraps the complex interface.
Maybe this is not even necessary.
> > Maybe you want to have a look at the API discussion we had a couple of
> > months ago. I've got a pretty good idea how the API should look like but I
> > failed to present my own proposal which basically builds on this
> > discussion.
> > http://marc.theaimsgroup.com/?t=102288093500008&r=1&w=2
>
> Yes, I remember it.
>
> But let's fly down still, and concentrate on the Driver.
> When that's reasonably done, we will see where it makes sense to drive
> up the hierarchy.
>
>
> > I'm going to work that up during the next few hours. Maybe this helps.
>
> Good, let us know :-)
>
> In the meantime, I'll set up a UML diagram for current CVS FOP.
Let me know how I can help. At the moment I don't see how I can be of
assistance. In the meantime I'll set up checkstyle as I promised and
see if I can start to put together a code convention document.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [FOP Avalonization] Status update + recent discussion on Avalon
dev
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeremias Maerki wrote:
> On 04.09.2002 13:42:50 Nicola Ken Barozzi wrote:
>
>>Jeremias Maerki wrote:
...
>>>What do you have in mind to use as container? I've started using
>>>Fortress yesterday for a little private project and I liked it very much.
>>>Much better than the ECM.
>>
>>I would not use a container at all ATM.
>
> That means you just concentrate on the top-level component? FOP insides
> at a later time?
Yes.
Well, if we *ever* will want to apply Avalon to the insides.
Let's start with touching the .apps.* package, it's the one that imposes
bad constraint to the rest of the structure.
>>Fop is not an app, but rather a Component itself.
>>It needs other services, but doesn't need necessarily a container.
>>
>>Fop *is* the container, and the Renderers are the Components.
>>
>>So I would like to see Driver become a Container that can manage the
>>Renderers like Components.
>>Not much different from what is now, but with a cleaner separation of
>>concerns.
>>
>>In this way the Avalonization is limited to the main services used in
>>Fop, and the finer specific logic, which is the *real* core of Fop and
>>that all are working on remains exactly as-is.
>>
>>This gives the maximum advantage with the least problems.
>
> Actually, that's sort of what I had in mind. We could use Fortress as
> base for the container, right?
I would not use fortress at all.
Look at http://jakarta.apache.org/avalon/excalibur/tweety/ .
I would just rup off the code from there and create a minimalistic
container that does it all programmatically.
We can expand later, let's keep it simple.
>>I'm looking into the Driver class and studying it; there are some
>>strange relationships between all the .apps.*, I'm finding the cleanest
>>solution.
>>
>>Probably most of that package will be rewritten, but the rest should
>>mainly remain untouched.
>
>
> FOP has to have a very simple API to the outside world and should work
> as a blackbox. Something similar to JAXP or your Morphos.
Yes.
In fact the interface from the outside world is the same of Morphos...
> Maybe you want to have a look at the API discussion we had a couple of
> months ago. I've got a pretty good idea how the API should look like but I
> failed to present my own proposal which basically builds on this
> discussion.
> http://marc.theaimsgroup.com/?t=102288093500008&r=1&w=2
Yes, I remember it.
But let's fly down still, and concentrate on the Driver.
When that's reasonably done, we will see where it makes sense to drive
up the hierarchy.
> I'm going to work that up during the next few hours. Maybe this helps.
Good, let us know :-)
In the meantime, I'll set up a UML diagram for current CVS FOP.
> Jeremias Maerki
> (who's still tied up in reading up his 2660 mails accumulated over his
> two-week absence)
I get 3 Mb daily ;-)
--
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: [FOP Avalonization] Status update + recent discussion on Avalon
dev
Posted by Nicola Ken Barozzi <ni...@apache.org>.
J.Pietschmann wrote:
> Jeremias Maerki wrote:
>
>> Maybe you want to have a look at the API discussion we had a couple of
>> months ago.
>
>
> Some additional thoughts:
> - No filenames, only URLs
+1 we just got to the same conclusion on the Morphos thread hehehe ;-)
> - No Files (except when an URL resolves to a file), only streams
> in interfaces (or InputSource or whatever the abstraction is)
+1 again what we want too :-)
> - Some sort special interfaces to get XML across for SVG
> and, well, lets say font metric files.
> I'm not sure whether passing ContentHandlers (i.e. using
> SAX only) or using javax.xml.transform.Stream is the way
> to go. Some people seem to *like* DOM trees.
Dunno about this.
--
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: [FOP Avalonization] Status update + recent discussion on Avalon
dev
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Maybe you want to have a look at the API discussion we had a couple of
> months ago.
Some additional thoughts:
- No filenames, only URLs
- No Files (except when an URL resolves to a file), only streams
in interfaces (or InputSource or whatever the abstraction is)
- Some sort special interfaces to get XML across for SVG
and, well, lets say font metric files.
I'm not sure whether passing ContentHandlers (i.e. using
SAX only) or using javax.xml.transform.Stream is the way
to go. Some people seem to *like* DOM trees.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [FOP Avalonization] Status update + recent discussion on Avalon dev
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 04.09.2002 13:42:50 Nicola Ken Barozzi wrote:
>
> Jeremias Maerki wrote:
> > Hey Nicola
> >
> > Cool to see you here!
>
> :-D
>
> > I've still got holidays until the end of next
> > week so I got some time to work on FOP.
>
> I try to give a hand,
I need it.
> but with the gazillion projects I'm in, I will
> appreciate your return ;-)
I still wonder how some people can be so active in so many places at
once. :-)
> > I was somewhat hesitant to do
> > avalonization because this means tearing up a lot of wholes that need to
> > be closed in time. Considering my limited time available I've just spent
> > some time preparing the migration (especially logging stuff). Next is
> > configuration I guess. I'm ready to team up with you for a concentrated
> > effort on avalonization if it makes sense.
>
> Good.
>
> > What do you have in mind to use as container? I've started using
> > Fortress yesterday for a little private project and I liked it very much.
> > Much better than the ECM.
>
> I would not use a container at all ATM.
That means you just concentrate on the top-level component? FOP insides
at a later time?
> Fop is not an app, but rather a Component itself.
> It needs other services, but doesn't need necessarily a container.
>
> Fop *is* the container, and the Renderers are the Components.
>
> So I would like to see Driver become a Container that can manage the
> Renderers like Components.
> Not much different from what is now, but with a cleaner separation of
> concerns.
>
> In this way the Avalonization is limited to the main services used in
> Fop, and the finer specific logic, which is the *real* core of Fop and
> that all are working on remains exactly as-is.
>
> This gives the maximum advantage with the least problems.
Actually, that's sort of what I had in mind. We could use Fortress as
base for the container, right?
> I'm looking into the Driver class and studying it; there are some
> strange relationships between all the .apps.*, I'm finding the cleanest
> solution.
>
> Probably most of that package will be rewritten, but the rest should
> mainly remain untouched.
FOP has to have a very simple API to the outside world and should work
as a blackbox. Something similar to JAXP or your Morphos.
Maybe you want to have a look at the API discussion we had a couple of
months ago. I've got a pretty good idea how the API should look like but I
failed to present my own proposal which basically builds on this
discussion.
http://marc.theaimsgroup.com/?t=102288093500008&r=1&w=2
I'm going to work that up during the next few hours. Maybe this helps.
Jeremias Maerki
(who's still tied up in reading up his 2660 mails accumulated over his
two-week absence)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [FOP Avalonization] Status update + recent discussion on Avalon
dev
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeremias Maerki wrote:
> Hey Nicola
>
> Cool to see you here!
:-D
> I've still got holidays until the end of next
> week so I got some time to work on FOP.
I try to give a hand, but with the gazillion projects I'm in, I will
appreciate your return ;-)
> I was somewhat hesitant to do
> avalonization because this means tearing up a lot of wholes that need to
> be closed in time. Considering my limited time available I've just spent
> some time preparing the migration (especially logging stuff). Next is
> configuration I guess. I'm ready to team up with you for a concentrated
> effort on avalonization if it makes sense.
Good.
> What do you have in mind to use as container? I've started using
> Fortress yesterday for a little private project and I liked it very much.
> Much better than the ECM.
I would not use a container at all ATM.
Fop is not an app, but rather a Component itself.
It needs other services, but doesn't need necessarily a container.
Fop *is* the container, and the Renderers are the Components.
So I would like to see Driver become a Container that can manage the
Renderers like Components.
Not much different from what is now, but with a cleaner separation of
concerns.
In this way the Avalonization is limited to the main services used in
Fop, and the finer specific logic, which is the *real* core of Fop and
that all are working on remains exactly as-is.
This gives the maximum advantage with the least problems.
I'm looking into the Driver class and studying it; there are some
strange relationships between all the .apps.*, I'm finding the cleanest
solution.
Probably most of that package will be rewritten, but the rest should
mainly remain untouched.
--
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: [FOP Avalonization] Status update + recent discussion on Avalon dev
Posted by Jeremias Maerki <de...@greenmail.ch>.
Hey Nicola
Cool to see you here! I've still got holidays until the end of next
week so I got some time to work on FOP. I was somewhat hesitant to do
avalonization because this means tearing up a lot of wholes that need to
be closed in time. Considering my limited time available I've just spent
some time preparing the migration (especially logging stuff). Next is
configuration I guess. I'm ready to team up with you for a concentrated
effort on avalonization if it makes sense.
What do you have in mind to use as container? I've started using
Fortress yesterday for a little private project and I liked it very much.
Much better than the ECM.
On 04.09.2002 10:54:24 Nicola Ken Barozzi wrote:
> Keiron Liddle wrote:
> > Hi,
> >
> > I will remove the old configuration stuff so you don't have to deal with
> > it. Committing soon...
>
> You did it now, thanks :-)
>
> In fact, it was somewhat confusing :-S
> I might be changing some stuff in the /apps dir, well, quite a lot, so
> that FOP can become a real Avalon Component.
>
> Thanks again :-)
>
> > On Tue, 2002-09-03 at 16:11, Nicola Ken Barozzi wrote:
> >
> >>Following the need to make use of the resolver in Avalon, I started
> >>implementing it.
> >>
> >>Using the Resolver in the ImageFactory itself is easy enough, but I
> >>wanted to make a service out of it, to manage it properly, and came to a
> >>problem: how the heck is the class that needs it going to get that service?
> >>
> >>Usually, for Components it's the Container that gives the
> >>ServiceManager, from which the services are accessible, but here it's a
> >>mess to do it everywhere, like for logging.
> >
> >
> > It doesn't really belong everywhere and only certain sections need it
> > anyway. The problem is that the parts are in the middle of everything.
> >
> >
> >>So I was unsure on how to continue, and here is the thread that came out:
> >>http://nagoya.apache.org/eyebrowse/BrowseList?listName=avalon-dev@jakarta.apache.org&by=thread&from=233005
> >>
> >>Basically the point is that these objects should not request a service,
> >>they should be given already the resolved URL somewhat by the creator.
> >>The system should not be Active, so that an external builder can do it.
> >>
> >>Example:
> >>
> >>Instead of
> >>
> >> method(unresolvedparam){
> >> resolved = getService().resolve(unresolvedparam)
> >> use(resolved);
> >> }
> >>
> >>I should do
> >>
> >> method(resolved ){
> >> use(resolved);
> >> }
> >
> >
> > Is it possible to resolve a URL without trying to load it? What is the
> > proper way to handle that?
> >
> >
> >
> >>This means that whoever calls the method should be able to resolve it,
> >>or in turn has to be given it already resolved.
> >>
> >>There are other ways, but this is the best IMHO.
> >>
> >>The question is, how can it integrate with FOP current and next2be design?
> >
> >
> > There is also other bit like embedded fonts
> >
>
> --
> 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
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [FOP Avalonization] Status update + recent discussion on Avalon
dev
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Keiron Liddle wrote:
> Hi,
>
> I will remove the old configuration stuff so you don't have to deal with
> it. Committing soon...
You did it now, thanks :-)
In fact, it was somewhat confusing :-S
I might be changing some stuff in the /apps dir, well, quite a lot, so
that FOP can become a real Avalon Component.
Thanks again :-)
> On Tue, 2002-09-03 at 16:11, Nicola Ken Barozzi wrote:
>
>>Following the need to make use of the resolver in Avalon, I started
>>implementing it.
>>
>>Using the Resolver in the ImageFactory itself is easy enough, but I
>>wanted to make a service out of it, to manage it properly, and came to a
>>problem: how the heck is the class that needs it going to get that service?
>>
>>Usually, for Components it's the Container that gives the
>>ServiceManager, from which the services are accessible, but here it's a
>>mess to do it everywhere, like for logging.
>
>
> It doesn't really belong everywhere and only certain sections need it
> anyway. The problem is that the parts are in the middle of everything.
>
>
>>So I was unsure on how to continue, and here is the thread that came out:
>>http://nagoya.apache.org/eyebrowse/BrowseList?listName=avalon-dev@jakarta.apache.org&by=thread&from=233005
>>
>>Basically the point is that these objects should not request a service,
>>they should be given already the resolved URL somewhat by the creator.
>>The system should not be Active, so that an external builder can do it.
>>
>>Example:
>>
>>Instead of
>>
>> method(unresolvedparam){
>> resolved = getService().resolve(unresolvedparam)
>> use(resolved);
>> }
>>
>>I should do
>>
>> method(resolved ){
>> use(resolved);
>> }
>
>
> Is it possible to resolve a URL without trying to load it? What is the
> proper way to handle that?
>
>
>
>>This means that whoever calls the method should be able to resolve it,
>>or in turn has to be given it already resolved.
>>
>>There are other ways, but this is the best IMHO.
>>
>>The question is, how can it integrate with FOP current and next2be design?
>
>
> There is also other bit like embedded fonts
>
--
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