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 Jeremias Maerki <de...@greenmail.ch> on 2003/11/08 16:28:11 UTC
Setup code in Driver
As you may have seen in the CVS messages I have moved most of the setup
code that was in the render() method to the getContentHandler() method.
This is necessary because not everyone uses the render() methods,
sometimes you simply need to have a ContentHandler to send SAX events to.
Some of our examples (and some of our basic test cases) use that
approach.
What is left to do is to enable the FOTreeListener for Document that is
currently added only if the render() method is called. Providing the
same functionality with getContentHandler() only means you're not in the
Driver class anymore when endDocument() is called on the ContentHandler
which makes it difficult to remove the FOTreeListener on the
FOTreeHandler when processing is complete.
If noone objects, if noone has a better idea and if noone fixes that
ahead of me, I'm going to write a ProxyingDefaultHandler as a utility
class that does nothing other than pass through all method calls to
another DefaultHandler (in other words: the FOTreeBuilder). I'll then
add an anonymous inner class derived from that ProxyingDefaultHandler in
getContentHandler that listens to the endDocument() event and calls
removeFOTreeListener on FOTreeHandler. Instead of the FOTreeBuilder that
anonymous inner class will be returned by getContentHandler().
Jeremias Maerki
RE: Setup code in Driver
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> You have as yet only Glen's opinion about your pioneer LS proposal. It
> might be worthwhile to wait for others to express theirs.
I don't remember the technical rule for the mathematics of accepting
proposals, but with the size of our group, a -1 from anyone pretty much
kills it IMO. Right now, I see only 4 developers that might express an
opinion: Peter (West), Joerg, Jeremias, and Glen. AFAIR, Joerg has never
officially voted, but expressed only coolness to the LS idea in general, and
even less enthusiasm for the Pioneer LS. I interpreted Glen to vote -1. I do
not expect a +1 from you, because Pioneer LS is predicated on LS, and LS
would have to either be ditched or rendered useless to accommodate the
scheme that you insist upon. So the only unknown is Jeremias -- even if he
voted +1, that wouldn't be enough to carry the issue.
I'm not in love with the Pioneer LS either, but viewed it as a bridge
between the maintenance and trunk lines of development that would allow us
to restore the "release early and release often" principle. Ideally, instead
of splitting the lines of development, we would have factored the layout
logic out in a manner similar to what I have done on the trunk, then started
a new LayoutStrategy while leaving the existing one intact. Changes to
fonts, graphics, config, Avalonization, etc. would then be added in parallel
with changes to the new layout system, still allowing improvements to be
released, tested, fixed, used. The Pioneer LS (RIP) was an attempt to
retrofit us into that state again.
No, I can see that the idea, once coolly tolerated, has now been rejected.
> > It makes me realize again that maybe I was the one pulling
> against the flow.
> ...
>
> Having always pulled against the flow, I feel qualified to comment on
> this. The Apache projects and subprojects like to describe themselves
> as communities. I don't see that as meaning a gang, where everyone
> wears the same "colours" and effectively surrenders identity to the
> collective. At the other end would be a collection of developers
> amongst whom no agreement on direction could be reached, and who each
> pursued a separate line of development. This would render any
> productive collaboration impossible. I think Apache communities
> necessarily fall somewhere in between these extremes.
>
> Obviously, I believe there is room for serious individual differences in
> approach within FOP, and by extension, within other Apache communities,
> although this will vary with the maturity of both the codebase and the
> Recommendation(s) of which it is an implementation. A mature, widely
> used and comprehensive implementation of a stable Recommendation seems
> to offer little room for alternative approaches.
>
> FOP is not a mature, stable and comprehensive implementation of XSL 1.0,
> and XSL 1.1 is out in Working Draft, albeit without radical changes. I
> don't think it is surprising that there are serious differences of
> approach. I have explained my own motivations on a number of occasions.
> The bottom line, though, is that I believe in the approach I am
> taking, and I believe that I, or rather, the design itself, will
> eventually persuade others.
The *technical* issue in play here is whether FOP will be monolithic or
modularized. (There is an even bigger issue about how the Open Source
development model should work, but I have already said 'nuff on that
subject). For the record, I have little doubt that your monolithic approach
can be made to work. The question is, supposing that a modular approach can
be made to work, why not gain the benefits that come with modularization?
And why not, until all are persuaded to the same view, accommodate both?
Your layout scheme can be accommodated within the sphere of LS. However,
AFAICT, no patient LS scheme can be accommodated within your scheme for
layout. So, my objection to your proposal is not that mine is better than
yours, but that you insist that the trial never be had, that we cut off
options for no apparent good reason.
> This last part is easier said than done, for very simple reasons. I may
> have mentioned before that only I, for most of the time, and Jeremias
> for part of the time, have been able to work full-time on FOP. Everyone
> else has a job around which he or she has to work. Given the severe
> time limits, and the difficulty of coming to terms with 1) the
> Recommendation, 2) the maintenance branch, and 3) HEAD, it is not
> surprising that faced with a major change of design direction, most
> people just don't have the time or energy to try to come to terms with it.
>
> That doesn't make alternative approaches worthless. Alt.design's
> property handling is now bearing some fruit in HEAD, of which I am very
> glad. That it took so long for this to happen is unfortunate but
> understandable.
>
> The bottom line, it seems to me, is that if you believe in what you are
> doing, go ahead and do it. The main reason I got to be a committer is
> that Nicola Ken Barozzi asked why my code was being kept on my ISP. He
> said that anyone had a right to fork the code, or words to that effect,
> IIRC. It's a lonely path until you do manage to persuade others, but if
> you believe in it, back your judgement.
Well, I don't mean to give the impression that I don't believe in what I am
doing, but merely that I have been unsuccessful in my efforts to persuade
others. There is a PhD on fop-user who has more than once suggested that FOP
needs to be rewritten in Ada. Maybe he is right, but I don't think anyone
seriously thinks that we should make him a committer so that he can start
into that project, either on the trunk or a branch. The Java language, at
least for now, is a settled issue. The issue of monolithic vs. modularized,
while orthogonal to the language issue, is of no less magnitude. I thought
that the idea of accommodating patient processing through modularization was
a settled issue as well. I see now that it ain't and probably never will be.
So, I believe in what I am doing, but don't see a cost-effective way, and
probably no way at all, to get it done within the FOP project. I don't see
any need to drag those along who don't want to come. As I said in a previous
posting, if we're going to go in different directions, the "next best thing"
is to part in peace and work separately instead of against each other.
Whether that means forking the code, starting from scratch, throwing in with
some other project, etc. I don't know. That decision is immaterial to you.
But since you seemed to issue a challenge on the matter, I wanted you to
know that I do indeed believe in what I am doing.
Victor Mote
Re: Setup code in Driver
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor Mote wrote:
> Glen Mazza wrote:
>
>
>>--- Victor Mote <vi...@outfitr.com> wrote:
...
>>
>>
>>You've mentioned before, I believe, there was some
>>things you wished to do to improve the fonts. That
>>may be good--because most of us have not researched
>>them.
>
>
> The font work has to get thrown away. It is useless without configuration,
> and there is no way I'm going to try to figure out what the team wants on
> that issue. And actually it is pretty useless without a working layout
> system. Jeremias knows at least as much about fonts as I do, and can
> probably make faster progress with me inactive.
>
>
>>>If LayoutStrategy
>>>survives reasonably intact, I am much inclined to
>>>try to complete the port
>>>of the pioneer LS.
>>
>>I'd rather you not. I don't want to have to maintain
>>the 0.20.x layout strategy in addition to the 1.0
>>strategy in 1.0. The committers and contributors
>>(Simon and Chris, in particular) are happy working on
>>the improving 1.0 layout and wish to remain with it.
>>
>>Recent patches (hyphenation, borders) to 1.0 LS have
>>made 0.20.x even more behind. Also, the 1.0 Area Tree
>>and Renderers are incompatible with 0.20.x LS, I don't
>>want their architectures changed in order to
>>accomodate it.
>>
>>Those who wish to use the 0.20.x layout strategy can
>>continue to run 0.20.x.
>>
>>Let the decision to bring in that LS be with the ones
>>who will have to maintain it. As for me, getting one
>>LS right is more than enough work.
>
>
> For the sake of brevity and peace, I will ignore the factual and analytical
> errors here, and simply say "Thanks! That certainly makes my life easier."
You have as yet only Glen's opinion about your pioneer LS proposal. It
might be worthwhile to wait for others to express theirs.
> It makes me realize again that maybe I was the one pulling against the flow.
...
Having always pulled against the flow, I feel qualified to comment on
this. The Apache projects and subprojects like to describe themselves
as communities. I don't see that as meaning a gang, where everyone
wears the same "colours" and effectively surrenders identity to the
collective. At the other end would be a collection of developers
amongst whom no agreement on direction could be reached, and who each
pursued a separate line of development. This would render any
productive collaboration impossible. I think Apache communities
necessarily fall somewhere in between these extremes.
Obviously, I believe there is room for serious individual differences in
approach within FOP, and by extension, within other Apache communities,
although this will vary with the maturity of both the codebase and the
Recommendation(s) of which it is an implementation. A mature, widely
used and comprehensive implementation of a stable Recommendation seems
to offer little room for alternative approaches.
FOP is not a mature, stable and comprehensive implementation of XSL 1.0,
and XSL 1.1 is out in Working Draft, albeit without radical changes. I
don't think it is surprising that there are serious differences of
approach. I have explained my own motivations on a number of occasions.
The bottom line, though, is that I believe in the approach I am
taking, and I believe that I, or rather, the design itself, will
eventually persuade others.
This last part is easier said than done, for very simple reasons. I may
have mentioned before that only I, for most of the time, and Jeremias
for part of the time, have been able to work full-time on FOP. Everyone
else has a job around which he or she has to work. Given the severe
time limits, and the difficulty of coming to terms with 1) the
Recommendation, 2) the maintenance branch, and 3) HEAD, it is not
surprising that faced with a major change of design direction, most
people just don't have the time or energy to try to come to terms with it.
That doesn't make alternative approaches worthless. Alt.design's
property handling is now bearing some fruit in HEAD, of which I am very
glad. That it took so long for this to happen is unfortunate but
understandable.
The bottom line, it seems to me, is that if you believe in what you are
doing, go ahead and do it. The main reason I got to be a committer is
that Nicola Ken Barozzi asked why my code was being kept on my ISP. He
said that anyone had a right to fork the code, or words to that effect,
IIRC. It's a lonely path until you do manage to persuade others, but if
you believe in it, back your judgement.
>
> Perhaps, in light of this, it may be worthwhile to abandon LayoutStrategy
> entirely. That would solve Jeremias's problem that started this thread.
...
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
RE: Setup code in Driver
Posted by Victor Mote <vi...@outfitr.com>.
Glen Mazza wrote:
> --- Victor Mote <vi...@outfitr.com> wrote:
> > Also, if possible, please let me know what you
> > decide. I am evaluating
> > in-progress projects right now to determine which
> > ones I should finish and
> > which ones I should abandon as I exit the project.
>
> You've mentioned before, I believe, there was some
> things you wished to do to improve the fonts. That
> may be good--because most of us have not researched
> them.
The font work has to get thrown away. It is useless without configuration,
and there is no way I'm going to try to figure out what the team wants on
that issue. And actually it is pretty useless without a working layout
system. Jeremias knows at least as much about fonts as I do, and can
probably make faster progress with me inactive.
> > If LayoutStrategy
> > survives reasonably intact, I am much inclined to
> > try to complete the port
> > of the pioneer LS.
>
> I'd rather you not. I don't want to have to maintain
> the 0.20.x layout strategy in addition to the 1.0
> strategy in 1.0. The committers and contributors
> (Simon and Chris, in particular) are happy working on
> the improving 1.0 layout and wish to remain with it.
>
> Recent patches (hyphenation, borders) to 1.0 LS have
> made 0.20.x even more behind. Also, the 1.0 Area Tree
> and Renderers are incompatible with 0.20.x LS, I don't
> want their architectures changed in order to
> accomodate it.
>
> Those who wish to use the 0.20.x layout strategy can
> continue to run 0.20.x.
>
> Let the decision to bring in that LS be with the ones
> who will have to maintain it. As for me, getting one
> LS right is more than enough work.
For the sake of brevity and peace, I will ignore the factual and analytical
errors here, and simply say "Thanks! That certainly makes my life easier."
It makes me realize again that maybe I was the one pulling against the flow.
My apologies to all, especially Peter.
Perhaps, in light of this, it may be worthwhile to abandon LayoutStrategy
entirely. That would solve Jeremias's problem that started this thread.
That actually leaves only one piece of unfinished business on my part -- the
static field lastFOTextProcessed in fo.FOText. This is used for
text-transform. It has been my intention to make that an instance variable
in PageSequence. However, there are some design-related issues that need to
be resolved before that should be done, and I intend to stay out of that. So
I mention it only to make sure that you know that I know that it shouldn't
be as it is, but that I don't see a ready solution. If multi-threading is
more important than text-transform, and you can't get the field converted to
an instance variable, just comment out the text-transform code.
Best wishes to all.
Victor Mote
RE: Setup code in Driver
Posted by Glen Mazza <gr...@yahoo.com>.
--- Victor Mote <vi...@outfitr.com> wrote:
> Also, if possible, please let me know what you
> decide. I am evaluating
> in-progress projects right now to determine which
> ones I should finish and
> which ones I should abandon as I exit the project.
You've mentioned before, I believe, there was some
things you wished to do to improve the fonts. That
may be good--because most of us have not researched
them.
> If LayoutStrategy
> survives reasonably intact, I am much inclined to
> try to complete the port
> of the pioneer LS.
I'd rather you not. I don't want to have to maintain
the 0.20.x layout strategy in addition to the 1.0
strategy in 1.0. The committers and contributors
(Simon and Chris, in particular) are happy working on
the improving 1.0 layout and wish to remain with it.
Recent patches (hyphenation, borders) to 1.0 LS have
made 0.20.x even more behind. Also, the 1.0 Area Tree
and Renderers are incompatible with 0.20.x LS, I don't
want their architectures changed in order to
accomodate it.
Those who wish to use the 0.20.x layout strategy can
continue to run 0.20.x.
Let the decision to bring in that LS be with the ones
who will have to maintain it. As for me, getting one
LS right is more than enough work.
Glen
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
RE: Setup code in Driver
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> > The answer to your question probably lies in understanding how and why
> > getContentHandler() is used without also using render(). The
> FOTreeListener
> > is only needed if the input document is parsed, and in fact is
> only needed
> > if you want to break out of parsing to go do something at a higher level
> > before returning (the normal SAX events are not affected at all). So:
> > 1) if the process running getContentHandler() doesn't ever parse, don't
> > bother registering the FOTreeListener
>
> Does that ever happen? I would assume that anyone who calls
> getContentHandler() will want to send SAX events. I don't think I
> understand what you're trying to explain. Sorry.
I don't know whether it happens or not. I can't think of a reason for this
to be done. Since I don't understand how this is getting used, I was just
trying to cover all possibilities.
> > 2) if the process running getContentHandler() doesn't care about being
> > notified about the end of a PageSequence (which is the only
> FOTreeListener
> > event that is *unique*), don't bother registering the FOTreeListener
>
> Ok, I guess that is something that was introduced by your LayoutStrategy.
> Would you explain to me what you mean by "process" in this context?
It is only loosely related to LayoutStrategy. It had more to do with trying
to separate the parsing and layout (somewhat foundational to LayoutStrategy,
but useful even apart from that). fo.FOTreeEvent and fo.FOTreeListener kind
of mimic what the SAX events do, but are fired from within FOP as the FOTree
is being built. This allows FOTree to do its thing without needing to know
how it is being used.
By "process" I just mean whatever embedded application is calling
getContentHandler().
> > 3) otherwise, have it wrap its parsing code inside of the
> following (which
> > is what is wrapped around parser.parse in render() now):
> > <before>
> > if (foInputHandler instanceof FOTreeHandler) {
> > FOTreeHandler foTreeHandler =
> (FOTreeHandler)foInputHandler;
> > foTreeHandler.addFOTreeListener(currentDocument);
> > }
> > </before>
> >
> > <after>
> > if (foInputHandler instanceof FOTreeHandler) {
> > FOTreeHandler foTreeHandler =
> (FOTreeHandler)foInputHandler;
> > foTreeHandler.removeFOTreeListener(currentDocument);
> > }
> > </after>
> >
> > Better yet, refactor both of the above code snippets into
> methods that can
> > be called more simply, since this code would now be used more than once.
>
> As methods of Document?
Since the code is in Driver now, I was thinking Driver. However, it will
work from Document also. You'll just need to use getDriver() to get to the
foInputHandler.
> > Just looking at what is left in render(), I don't quite follow
> why it would
> > ever *not* be used if parsing will take place. The only thing
> left in there
> > is parser.parse(), the above code that it is wrapped in, and the code to
> > *not* parse based on the LayoutStrategy's wishes. Since the
> parser itself
> > can be passed as a parameter, it seems like anybody parsing
> could/would use
> > it. If you will describe the use case(s) a bit, I'll try to be
> of more help.
>
> Use cases that are not using render? Most prominent use case is Cocoon
> which build a SAX pipeline where FOP can be the end of that pipeline. So
> Cocoon needs a ContentHandler. Cocoon will not be able to call the
> render() method. Personally, I have never used FOP's render() method as
> a FOP user. I've always worked with getContentHandler(). I guess the
> Cocoon use-case should be enough to convince you that the
> getContentHandler() is necessary.
The only thing going on in render right now is parser.parse(). Based on your
above answer to #1, Cocoon must be doing something like that internally???
And based on your answer immediately above, it absolutely cannot use
render() to do that. Although I don't grasp why this should be true, taking
it at face value, and assuming that we want FOP to layout this document,
here are the options:
1. The equivalent of parser.parse() that exists in the embedded app (Cocoon)
will need to be wrapped in the code that activates the FOTreeListener. The
code in render() that checks to see whether the LayoutStrategy wants to
build an FOTree or not probably needs to be included as well, and again, it
should probably be extracted into a method, or included in the <before>
method. (This was the code I recently added to accommodate alt-design so
that it could create its own data structure instead of using FOTree).
2. The FOTreeListener concept can be abandoned. Simply restore to the
original scheme, which had the FOTree start the layout process for the
PageSequence as parsing was completed for it. I don't remember exactly where
that is, but it is wherever the FOTreeEvent is being fired. Here are the
costs that I can think of to this approach:
a. Either LayoutStrategy needs to be abandoned, or the LayoutStrategy
implementation needs to be made available to the method mentioned above that
handles the end of a PageSequence. FONode.getFOTreeControl() can be used for
the latter option. (FOTreeControl is the interface from FOTree to Document).
b. FOTree independence needs to be abandoned. It was never totally
achieved anyway, and AFAICT I am the only one that thought it was very
important. Alternatively, an additional FOTree interface could be created to
which LayoutStrategy should conform.
> > Part of what is making this a bit ugly is that render() really
> belongs in
> > the Document class, but I don't think that can be done until FOP's API
> > issues are resolved.
>
> Another top-priority todo item on my list that I haven't had time for,
> yet. *sigh*
Sorry, that was not meant as a dig at you.
I have deliberately avoided recommending anything above, as 1) I don't have
an interest in the outcome, and 2) I don't want to start any more fights.
However, please let me know if I can help resolve this. And I'm sorry to be
so dense on Cocoon -- I am familiar with its model at a user level, but must
have a false model in my head about how it does its work.
Also, if possible, please let me know what you decide. I am evaluating
in-progress projects right now to determine which ones I should finish and
which ones I should abandon as I exit the project. If LayoutStrategy
survives reasonably intact, I am much inclined to try to complete the port
of the pioneer LS. If not, then it would be unusable.
Victor Mote
Re: Setup code in Driver
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 20.12.2003 15:17:52 Victor Mote wrote:
> First, my apologies for being so slow to respond. I am trying to clean up
> some of this old stuff that I had flagged for followup. I also looked in the
> CVS history & source, and it looks like you have not finished this yet.
Right. I still got 622 unread mails in my fop-dev folder. :-) So I guess
I simply forgot. Available time also influenced this.
> The answer to your question probably lies in understanding how and why
> getContentHandler() is used without also using render(). The FOTreeListener
> is only needed if the input document is parsed, and in fact is only needed
> if you want to break out of parsing to go do something at a higher level
> before returning (the normal SAX events are not affected at all). So:
> 1) if the process running getContentHandler() doesn't ever parse, don't
> bother registering the FOTreeListener
Does that ever happen? I would assume that anyone who calls
getContentHandler() will want to send SAX events. I don't think I
understand what you're trying to explain. Sorry.
> 2) if the process running getContentHandler() doesn't care about being
> notified about the end of a PageSequence (which is the only FOTreeListener
> event that is *unique*), don't bother registering the FOTreeListener
Ok, I guess that is something that was introduced by your LayoutStrategy.
Would you explain to me what you mean by "process" in this context?
> 3) otherwise, have it wrap its parsing code inside of the following (which
> is what is wrapped around parser.parse in render() now):
> <before>
> if (foInputHandler instanceof FOTreeHandler) {
> FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
> foTreeHandler.addFOTreeListener(currentDocument);
> }
> </before>
>
> <after>
> if (foInputHandler instanceof FOTreeHandler) {
> FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
> foTreeHandler.removeFOTreeListener(currentDocument);
> }
> </after>
>
> Better yet, refactor both of the above code snippets into methods that can
> be called more simply, since this code would now be used more than once.
As methods of Document?
> Just looking at what is left in render(), I don't quite follow why it would
> ever *not* be used if parsing will take place. The only thing left in there
> is parser.parse(), the above code that it is wrapped in, and the code to
> *not* parse based on the LayoutStrategy's wishes. Since the parser itself
> can be passed as a parameter, it seems like anybody parsing could/would use
> it. If you will describe the use case(s) a bit, I'll try to be of more help.
Use cases that are not using render? Most prominent use case is Cocoon
which build a SAX pipeline where FOP can be the end of that pipeline. So
Cocoon needs a ContentHandler. Cocoon will not be able to call the
render() method. Personally, I have never used FOP's render() method as
a FOP user. I've always worked with getContentHandler(). I guess the
Cocoon use-case should be enough to convince you that the
getContentHandler() is necessary.
> Part of what is making this a bit ugly is that render() really belongs in
> the Document class, but I don't think that can be done until FOP's API
> issues are resolved.
Another top-priority todo item on my list that I haven't had time for,
yet. *sigh*
Jeremias Maerki
Re: Setup code in Driver
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 13.11.2003 19:27:24 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > Anyway, I've added some basic functionality or API tests some time ago.
> > These are called during build IF JUnit is installed in your Ant
> > installation. Just copying junit.jar into Ant's lib directory should do
> > it. The build will then check if the high-level APIs for Driver and the
> > Transcoders work. They don't check what is generated, only if something
> > is generated and without exceptions. I'd appreciate if all committers
> > made the basic JUnit tests work in their environments.
>
> OK. I'll work on that. Sorry I missed it earlier. Also, I just added some
> doc for this.
Thanks.
> > > WRT API dependencies, we need to either document them or delegate the
> > > management of them to someone who knows them.
> >
> > Sorry but I don't exactly get what you're targeting here.
>
> I was talking about the Cocoon dependency that you mentioned in your
> original posting. If we have contractual commitments to third parties that
> need to be honored, we need to write them down and make them public.
Good thinking.
<snip/>
> FWIW, most of the things that I needed have now been done through the
> addition of the Document class. (In other words, I think I can exit out of
> the API debate -- I think you have probably seen comments that I left in the
> code about API issues, specifically about addressing Document and
> LayoutStrategy). A bunch of that code (Driver and Document) seems really
> ugly and overly complicated, but I did it that way to try to keep from
> breaking the current API. Also, there are things in Driver that belong in
> Document and vice versa.
I've seen some of them. I don't have any problems with that at this
stage. Let's simply clean up and improve as people have time to work on
it. I'll try to help, too.
> If the JUnit tests that you mentioned are a
> comprehensive way of assuring that the API is not broken, then I can take a
> much more aggressive view of the whole thing, and perhaps get some things
> cleaned up without feeling like I need to walk on eggshells. I'll make this
> a priority.
Uhm, I hope the tests are comprehensive though I don't dare say they are
already. As with the rest of FOP this is work in progress. But this is
all stuff that can help us avoid problems.
Jeremias Maerki
RE: Setup code in Driver
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> Anyway, I've added some basic functionality or API tests some time ago.
> These are called during build IF JUnit is installed in your Ant
> installation. Just copying junit.jar into Ant's lib directory should do
> it. The build will then check if the high-level APIs for Driver and the
> Transcoders work. They don't check what is generated, only if something
> is generated and without exceptions. I'd appreciate if all committers
> made the basic JUnit tests work in their environments.
OK. I'll work on that. Sorry I missed it earlier. Also, I just added some
doc for this.
> > WRT API dependencies, we need to either document them or delegate the
> > management of them to someone who knows them.
>
> Sorry but I don't exactly get what you're targeting here.
I was talking about the Cocoon dependency that you mentioned in your
original posting. If we have contractual commitments to third parties that
need to be honored, we need to write them down and make them public.
> > Please let me know if I need to fix something here. I seem to
> be hopelessly
> > lost WRT where we are going with API issues, but as long as they don't
> > prevent us from cleaning up FOP's underlying design, I'll be
> glad to help
> > any way I can.
>
> I'm a bit lost, too. We had lots of discussion but I think there was no
> real consensus. I still want to put my API proposal to action one day,
> but probably outside FOP at the beginning. I simply have too little time
> and too many ideas and tasks on my personal todo list. I think we simply
> need to make sure not to produce unnecessary obstacles for potential
> patch-makers. That's why I advocate a stable API and API deprecation
> instead of API modification and it's why I wrote those basic JUnit tests.
FWIW, most of the things that I needed have now been done through the
addition of the Document class. (In other words, I think I can exit out of
the API debate -- I think you have probably seen comments that I left in the
code about API issues, specifically about addressing Document and
LayoutStrategy). A bunch of that code (Driver and Document) seems really
ugly and overly complicated, but I did it that way to try to keep from
breaking the current API. Also, there are things in Driver that belong in
Document and vice versa. If the JUnit tests that you mentioned are a
comprehensive way of assuring that the API is not broken, then I can take a
much more aggressive view of the whole thing, and perhaps get some things
cleaned up without feeling like I need to walk on eggshells. I'll make this
a priority.
Victor Mote
Re: Setup code in Driver
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 12.11.2003 19:11:26 Victor Mote wrote:
> If we have test cases that need to be run, then we need to document that
> process. The last comments I remember (from Keiron, IIRC) were that testing
> was hopelessly broken and not yet worth fixing. I know Joerg has a testing
> scheme in place, but I think it is not what you are talking about. See:
> http://xml.apache.org/fop/dev/testing.html
Well, there are different levels of testing. It may well be that
compliance testing (which I think Keiron referred to) is broken. We need
a better approach anyway. That's on my long term task list BTW. Joerg
and I both have ideas in this area, not the same but hopefully
complementary ones.
Anyway, I've added some basic functionality or API tests some time ago.
These are called during build IF JUnit is installed in your Ant
installation. Just copying junit.jar into Ant's lib directory should do
it. The build will then check if the high-level APIs for Driver and the
Transcoders work. They don't check what is generated, only if something
is generated and without exceptions. I'd appreciate if all committers
made the basic JUnit tests work in their environments.
> WRT API dependencies, we need to either document them or delegate the
> management of them to someone who knows them.
Sorry but I don't exactly get what you're targeting here.
> Please let me know if I need to fix something here. I seem to be hopelessly
> lost WRT where we are going with API issues, but as long as they don't
> prevent us from cleaning up FOP's underlying design, I'll be glad to help
> any way I can.
I'm a bit lost, too. We had lots of discussion but I think there was no
real consensus. I still want to put my API proposal to action one day,
but probably outside FOP at the beginning. I simply have too little time
and too many ideas and tasks on my personal todo list. I think we simply
need to make sure not to produce unnecessary obstacles for potential
patch-makers. That's why I advocate a stable API and API deprecation
instead of API modification and it's why I wrote those basic JUnit tests.
Jeremias Maerki
RE: Setup code in Driver
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> I'm not in a fighter mood today so please change getContentHandler()
> to something other than public, make sure you check the test cases
> regularly, adjust the example code to the new API and keep in mind that
> Cocooners will want to migrate their FOPSerializer some day (They use
> getContentHandler() at the moment).
I am not sure whether this is all a problem I caused or not. The changes I
made were *supposed* to be in-place (which made them awkward) and not cause
API problems, but sometimes that works differently in theory than in
practice. AFAIK, we *must* rely on timely user testing to find these
problems.
If we have test cases that need to be run, then we need to document that
process. The last comments I remember (from Keiron, IIRC) were that testing
was hopelessly broken and not yet worth fixing. I know Joerg has a testing
scheme in place, but I think it is not what you are talking about. See:
http://xml.apache.org/fop/dev/testing.html
WRT API dependencies, we need to either document them or delegate the
management of them to someone who knows them.
Please let me know if I need to fix something here. I seem to be hopelessly
lost WRT where we are going with API issues, but as long as they don't
prevent us from cleaning up FOP's underlying design, I'll be glad to help
any way I can.
Victor Mote
Re: Setup code in Driver
Posted by Jeremias Maerki <de...@greenmail.ch>.
I'm not in a fighter mood today so please change getContentHandler()
to something other than public, make sure you check the test cases
regularly, adjust the example code to the new API and keep in mind that
Cocooners will want to migrate their FOPSerializer some day (They use
getContentHandler() at the moment).
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java?rev=1.5&content-type=text/vnd.viewcvs-markup
On 08.11.2003 21:48:52 Glen Mazza wrote:
> --- Jeremias Maerki <de...@greenmail.ch> wrote:
> > As you may have seen in the CVS messages I have
> > moved most of the setup
> > code that was in the render() method to the
> > getContentHandler() method.
> > This is necessary because not everyone uses the
> > render() methods,
>
> Well, what is wrong with everyone using the render()
> method for 1.0? It is precisely between major
> releases, as opposed to within minor patches--that
> APIs may change. That's the direction we've been
> going for 1.0--and we've had zero complaints on the
> user list about it.
>
> > sometimes you simply need to have a ContentHandler
> > to send SAX events to.
>
> But evidently not, given the code functionality
> unrelated to getting the content handler that you
> needed to move out of the render() functions, and into
> getContentHandler() to get this to work.
>
> Why are you providing multiple access paths to doing
> the same thing in FOP? What is wrong with calling the
> render() function--how does calling
> getContentHandler() help performance over just having
> a render() functions?
>
> > Some of our examples (and some of our basic test
> > cases) use that
> > approach.
> >
>
> They can be rewritten. What I need to hear is how
> performance suffers (or the coding becomes
> inordinately burdensome) as a result of just having
> the render() functions exposed. Juggling multiple
> API's doesn't help anyone.
Jeremias Maerki
Re: Setup code in Driver
Posted by Glen Mazza <gr...@yahoo.com>.
--- "J.Pietschmann" <j3...@yahoo.de> wrote:
> Glen Mazza wrote:
> > Well, what is wrong with everyone using the
> render()
> > method for 1.0?
>
> Because we sell the FOP processor as a SAX endpoint,
> so
> that the famous
> transformer.transform(source, new SAXResult(
> fop.getContentHandler()));
> can be used. Driving processing through SAX events
> is a major use case.
>
Yes, my error, forgot about that completely...I see
from the examples, if I were coding embedded it is
likely I would be using this method as well.
Thanks, Joerg, for the enlightenment, and apologies to
Jeremias for not looking at the examples on our
Embedded page before commenting.
Glen
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
Re: Setup code in Driver
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Glen Mazza wrote:
> Well, what is wrong with everyone using the render()
> method for 1.0?
Because we sell the FOP processor as a SAX endpoint, so
that the famous
transformer.transform(source, new SAXResult(
fop.getContentHandler()));
can be used. Driving processing through SAX events
is a major use case.
> and we've had zero complaints on the
> user list about it.
We don't have much users using 1.0.
J.Pietschmann
Re: Setup code in Driver
Posted by Glen Mazza <gr...@yahoo.com>.
--- Jeremias Maerki <de...@greenmail.ch> wrote:
> As you may have seen in the CVS messages I have
> moved most of the setup
> code that was in the render() method to the
> getContentHandler() method.
> This is necessary because not everyone uses the
> render() methods,
Well, what is wrong with everyone using the render()
method for 1.0? It is precisely between major
releases, as opposed to within minor patches--that
APIs may change. That's the direction we've been
going for 1.0--and we've had zero complaints on the
user list about it.
> sometimes you simply need to have a ContentHandler
> to send SAX events to.
But evidently not, given the code functionality
unrelated to getting the content handler that you
needed to move out of the render() functions, and into
getContentHandler() to get this to work.
Why are you providing multiple access paths to doing
the same thing in FOP? What is wrong with calling the
render() function--how does calling
getContentHandler() help performance over just having
a render() functions?
> Some of our examples (and some of our basic test
> cases) use that
> approach.
>
They can be rewritten. What I need to hear is how
performance suffers (or the coding becomes
inordinately burdensome) as a result of just having
the render() functions exposed. Juggling multiple
API's doesn't help anyone.
Glen
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
RE: Setup code in Driver
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote (Sent: Saturday, November 08, 2003 8:28 AM)
> As you may have seen in the CVS messages I have moved most of the setup
> code that was in the render() method to the getContentHandler() method.
> This is necessary because not everyone uses the render() methods,
> sometimes you simply need to have a ContentHandler to send SAX events to.
> Some of our examples (and some of our basic test cases) use that
> approach.
>
> What is left to do is to enable the FOTreeListener for Document that is
> currently added only if the render() method is called. Providing the
> same functionality with getContentHandler() only means you're not in the
> Driver class anymore when endDocument() is called on the ContentHandler
> which makes it difficult to remove the FOTreeListener on the
> FOTreeHandler when processing is complete.
>
> If noone objects, if noone has a better idea and if noone fixes that
> ahead of me, I'm going to write a ProxyingDefaultHandler as a utility
> class that does nothing other than pass through all method calls to
> another DefaultHandler (in other words: the FOTreeBuilder). I'll then
> add an anonymous inner class derived from that ProxyingDefaultHandler in
> getContentHandler that listens to the endDocument() event and calls
> removeFOTreeListener on FOTreeHandler. Instead of the FOTreeBuilder that
> anonymous inner class will be returned by getContentHandler().
First, my apologies for being so slow to respond. I am trying to clean up
some of this old stuff that I had flagged for followup. I also looked in the
CVS history & source, and it looks like you have not finished this yet.
The answer to your question probably lies in understanding how and why
getContentHandler() is used without also using render(). The FOTreeListener
is only needed if the input document is parsed, and in fact is only needed
if you want to break out of parsing to go do something at a higher level
before returning (the normal SAX events are not affected at all). So:
1) if the process running getContentHandler() doesn't ever parse, don't
bother registering the FOTreeListener
2) if the process running getContentHandler() doesn't care about being
notified about the end of a PageSequence (which is the only FOTreeListener
event that is *unique*), don't bother registering the FOTreeListener
3) otherwise, have it wrap its parsing code inside of the following (which
is what is wrapped around parser.parse in render() now):
<before>
if (foInputHandler instanceof FOTreeHandler) {
FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
foTreeHandler.addFOTreeListener(currentDocument);
}
</before>
<after>
if (foInputHandler instanceof FOTreeHandler) {
FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
foTreeHandler.removeFOTreeListener(currentDocument);
}
</after>
Better yet, refactor both of the above code snippets into methods that can
be called more simply, since this code would now be used more than once.
Just looking at what is left in render(), I don't quite follow why it would
ever *not* be used if parsing will take place. The only thing left in there
is parser.parse(), the above code that it is wrapped in, and the code to
*not* parse based on the LayoutStrategy's wishes. Since the parser itself
can be passed as a parameter, it seems like anybody parsing could/would use
it. If you will describe the use case(s) a bit, I'll try to be of more help.
Part of what is making this a bit ugly is that render() really belongs in
the Document class, but I don't think that can be done until FOP's API
issues are resolved.
Victor Mote