New ContentHandler attribute in Style build-in task wanted

[Christian Mallwitz <c....@intershop.de>]

Hi,

I would like to extend the build-in Style task with a contenthandler
attribute. So far if I have to use a content handler (of type
org.xml.sax.ContentHandler) I don't use the Style but the Java task with
Xalan e.g.

<java classname="org.apache.xalan.xslt.Process" output="foo.txt">
     <arg line="-IN foo.xml -XSL foo.xslt -CONTENTHANDLER
com.foo.myContentHandler"/>
</java>

I would have to extend the XSLTProcessor class, the XSLTLiason interface and
the optional classes implementing it.

Would I have to get commit access to the CVS for that or can I post diff's
to the original developers? What if XslpLiason (depricated anyway) doesnt't
support the new attribute but ignores it quitely?

Any objections?

Thanks
Christian
-- 
Christian Mallwitz INTERSHOP Communications Germany
Senior Technical Consultant phone: +49 3641 50 3453

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: New ContentHandler attribute in Style build-in task wanted

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Christian Mallwitz" <c....@intershop.de>
To: <an...@jakarta.apache.org>
Sent: Tuesday, April 02, 2002 8:11 AM
Subject: New ContentHandler attribute in Style build-in task wanted


> Hi,
>
> I would like to extend the build-in Style task with a contenthandler
> attribute. So far if I have to use a content handler (of type
> org.xml.sax.ContentHandler) I don't use the Style but the Java task with
> Xalan e.g.
>
> <java classname="org.apache.xalan.xslt.Process" output="foo.txt">
>      <arg line="-IN foo.xml -XSL foo.xslt -CONTENTHANDLER
> com.foo.myContentHandler"/>
> </java>
>
> I would have to extend the XSLTProcessor class, the XSLTLiason interface
and
> the optional classes implementing it.
>
> Would I have to get commit access to the CVS for that or can I post diff's
> to the original developers?

read access is all you need; add the CVS diff -u diffs of files (including
documentation and tests) to a bug report, harass people on the list till it
gets committed. Tests are important, you save a lot of time if you can do
some junit tests to validate it all working.

>What if XslpLiason (depricated anyway) doesnt't
> support the new attribute but ignores it quitely?

add a warning message to that liason, perhaps


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: New ContentHandler attribute in Style build-in task wanted

[Stefan Bodewig <bo...@apache.org>]

On Tue, 2 Apr 2002, Christian Mallwitz <c....@intershop.de>
wrote:

> I would have to extend the XSLTProcessor class, the XSLTLiason
> interface and the optional classes implementing it.

Is there any way we can achieve this without changing XSLTLiaison?  If
not, let's extend this interface in a way that we don't have to alter
it again later.

We keep on changing this interface with every release of Ant and at
the same time allow people to provide their own implementation to the
style task.  If people really do so, they have a problem, see 
<http://virtuals.intalio.com/cgi-bin/cvsweb.cgi/adaptx/src/main/org/exolab/adaptx/util/JakartaAntAdapter.java?cvsroot=adaptx>
this is a valid liaison in Ant 1.4.1 but won't work in 1.5.

To be clear, this is not against your changes, but more of a general
observation.

> What if XslpLiason (depricated anyway) doesnt't support the new
> attribute but ignores it quitely?

I'd go beyond Steve's suggestion.  Don't make it silently ignore it,
but throw a BuildException.  If I've specified a content handler, I've
done so for a reason.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>