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 Glen Mazza <gl...@yahoo.com> on 2003/04/28 03:45:23 UTC
Merge TRAXInputHandler into XSLTInputHandler?
I was wondering if TRAXInputHandler can be merged into
XSLTInputHandler, and the former class removed from
use. I'd like to try to submit a patch on this, but I
may be missing something about why we need both
classes.
The classes appear to have been separated in March
2001 to support users who were still working with the
non-JAXP compliant Xalan-1J transformer.
(http://marc.theaimsgroup.com/?l=fop-dev&m=98329165432269&w=2)
But Xalan-1J is no longer supported or even available
from the Xalan homepage, and both SAXON and Xalan-2J
are JAXP-compliant.
Do we plan on continuing support for Xalan-1J for FOP
1.0? If not, we may be OK with one class.
Glen
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Merge TRAXInputHandler into XSLTInputHandler?
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 08.05.2003 23:10:42 Glen Mazza wrote:
> Jeremias,
>
> Thanks for the explanation--sorry for my ignorance--I
> did not realize XSLT/TrAXInputHandler were exposed to
> the user for embedded programming. I thought these
> two classes were for internal use only, for generating
> XSL FO when XML & XSL are provided on the
> command-line. (For embedded coding, I've always used
> JAXP to get the XSL FO InputSource, and only then used
> the FOP Driver code.)
...which is a Good Thing (tm).
> I now see the concerns about quickly deprecating the
> classes. "In a perfect world", though, it would be
> nice if all users were using JAXP--this API is pretty
> elegant/succinct as-is, and it would be good for
> everyone to become skilled with it. Direct JAXP use
> is what the Xalan team, in their FAQ, appears to be
> promoting as well.
That's why I wrote the embedding examples (Example??2??.java) a few
months ago. You see, the API still comes from pre-JAXP times which
explains some of this. Maybe we should really just change the embedding
page to JAXP usage.
Does anyone disagree?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Merge TRAXInputHandler into XSLTInputHandler?
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 03.05.2003 21:18:19 Glen Mazza wrote:
>
> --- "J.Pietschmann" <j3...@yahoo.de> wrote:
> > Glen Mazza wrote:
> > > I got them combined earlier--the patch (attached)
> > to
> > > XSLTInputHandler seems to work fine in getting rid
> > of
> > > TRAXInputHandler.java.
> >
> > The problem is all the sample code and user programs
> > mentioning XSLTInputhandler and TRAXInputHandler out
> > there.
>
> Usually, they're referencing just Fop or Driver
> classes so they would be hidden from these changes.
No. Just look at http://xml.apache.org/fop/embedding.html
The Fop class should not be used from a Java program. It's only used as
a starting point for the command-line. As soon as you use driver you may
also have to use XSLT/TraxInputHandler if you don't use JAXP and
getContentHandler().
> These are internal functions--so the user can enter an
> .XML and an .XSL instead of an .FO on the command
> line. I don't believe users accessed these classes
> directly programmatically--it would be very difficult
> and cumbersome to do so, especially for
> TRAXInputHandler.
>
> Still, the nature of the code (XSLTInputHandler
> delegating to TRAXInputHandler upon finding a
> TRAX-compatible XSLT processor) should not require any
> changes to code that normally references
> XSLTInputHandler.
But once you got code out you need to support it. We've done the mistake
of ignoring backwards-compatibility too many times in the past and got
barked at. And they were right. As it looks the stuff (Driver and
friends) in the apps package will eventually get deprecated. We might
even need to revert some of the changes done to sync with the
maintenance branch. Then we can concentrate on a good API in another
package.
Even now, HEAD FOP doesn't run in Cocoon without patching the
fop-cocoon-block. We need to fix that.
> > We should deprecate one (or both) for a transition
> > period
> > before removing them. I thought I did this???
> >
>
> I'm recommending this for DR1.0--not for the
> maintenance release.
Sure. We're not talking about the maintenance branch here.
> By the time DR1.0 is ready that
> will more than constitute the transition period.
Not necessarily. That's when migration will start! We need to provide a
good migration path.
> XalanJ-1 (support for which was the original reason
> for having both classes in FOP) has already been
> transitioned off and discontinued from the Xalan web
> page--you can't even download it anymore. Both Saxon
> and XalanJ-2 are TRAX-compatible, so starting with
> DR1.0 is an excellent time to get rid of the XalanJ-1
> dinosaur.
That's true. But that doesn't mean we can just throw
XSLT/TraxInputHandler out of the window.
> I'd recommend applying the patch to
> XSLTInputHandler--it seems to work well and you can
> automatically delete the TRAXInputHandler class as a
> result. For later Avalonization of this particular
> class, it can just be applied to this one file
> instead.
I am -1 on removing TraxInputHandler for now, therefore I'm -0 on
applying your patch. Sorry. I hope you see that we're going in another
direction:
- We are discussing a totally new and intuitive API.
- We need to preserve backwards-compatibility for some time, even if it
hurts a bit.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Merge TRAXInputHandler into XSLTInputHandler?
Posted by Glen Mazza <gl...@yahoo.com>.
--- "J.Pietschmann" <j3...@yahoo.de> wrote:
> Glen Mazza wrote:
> > I got them combined earlier--the patch (attached)
> to
> > XSLTInputHandler seems to work fine in getting rid
> of
> > TRAXInputHandler.java.
>
> The problem is all the sample code and user programs
> mentioning XSLTInputhandler and TRAXInputHandler out
> there.
Usually, they're referencing just Fop or Driver
classes so they would be hidden from these changes.
These are internal functions--so the user can enter an
.XML and an .XSL instead of an .FO on the command
line. I don't believe users accessed these classes
directly programmatically--it would be very difficult
and cumbersome to do so, especially for
TRAXInputHandler.
Still, the nature of the code (XSLTInputHandler
delegating to TRAXInputHandler upon finding a
TRAX-compatible XSLT processor) should not require any
changes to code that normally references
XSLTInputHandler.
> We should deprecate one (or both) for a transition
> period
> before removing them. I thought I did this???
>
I'm recommending this for DR1.0--not for the
maintenance release. By the time DR1.0 is ready that
will more than constitute the transition period.
XalanJ-1 (support for which was the original reason
for having both classes in FOP) has already been
transitioned off and discontinued from the Xalan web
page--you can't even download it anymore. Both Saxon
and XalanJ-2 are TRAX-compatible, so starting with
DR1.0 is an excellent time to get rid of the XalanJ-1
dinosaur.
I'd recommend applying the patch to
XSLTInputHandler--it seems to work well and you can
automatically delete the TRAXInputHandler class as a
result. For later Avalonization of this particular
class, it can just be applied to this one file
instead.
Glen
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Merge TRAXInputHandler into XSLTInputHandler?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Glen Mazza wrote:
> I got them combined earlier--the patch (attached) to
> XSLTInputHandler seems to work fine in getting rid of
> TRAXInputHandler.java.
The problem is all the sample code and user programs
mentioning XSLTInputhandler and TRAXInputHandler out there.
We should deprecate one (or both) for a transition period
before removing them. I thought I did this???
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Merge TRAXInputHandler into XSLTInputHandler?
Posted by Glen Mazza <gl...@yahoo.com>.
I got them combined earlier--the patch (attached) to
XSLTInputHandler seems to work fine in getting rid of
TRAXInputHandler.java.
(Well, the projectteam.xml/.xsl ->.pdf example works,
but the glossary.xsl/.xml example has the same
InlineStackingLayoutManager infinite
loop/OutOfMemoryError on DEV1.0 that the present
two-class code has.)
Avalonized versions or not, I'm looking forward to
having the classes merged--the presence of both is
confusing, it makes it hard to follow the code.
Glen
--- Jeremias Maerki <de...@greenmail.ch> wrote:
> I'd prefer if we called it "new API", not
> "avalonized API". Because we
> may end up with two different APIs.
>
> On 28.04.2003 18:33:59 J.Pietschmann wrote:
> > In the avalonized API, both classes will be
> deprecated.
>
>
> Jeremias Maerki
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> fop-dev-unsubscribe@xml.apache.org
> For additional commands, email:
> fop-dev-help@xml.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: Merge TRAXInputHandler into XSLTInputHandler?
Posted by Jeremias Maerki <de...@greenmail.ch>.
I'd prefer if we called it "new API", not "avalonized API". Because we
may end up with two different APIs.
On 28.04.2003 18:33:59 J.Pietschmann wrote:
> In the avalonized API, both classes will be deprecated.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Merge TRAXInputHandler into XSLTInputHandler?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Glen Mazza wrote:
> I was wondering if TRAXInputHandler can be merged into
> XSLTInputHandler, and the former class removed from
> use. I'd like to try to submit a patch on this, but I
> may be missing something about why we need both
> classes.
In the avalonized API, both classes will be deprecated.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org