You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/10/19 18:33:56 UTC
Refactored (again) XSLT error handling
Hi all,
I refactored the error handling in TraxTransformer (again) and
XSLTProcessor.
* A usable <xsl:message terminate="yes">
We were used to have "Stylesheet directed termination" on screen,
indicating we had to dig in the logs. We now have the message displayed,
with location information.
* XSLT compilation warnings reported as errors.
Xalan is very forgiving and reports many incorrect syntaxes (unknown
attributes, text in forbidden places, etc) as warnings, which was
leading incorrect stylesheets to be silently accepted. This means that
some of your stylesheets may have to be fixed :-)
Activating this second feature requires to change the XSLTProcessor
implementation to o.a.c.c.xslt.XSLTProcessorImpl to connect the
TransformerFactory to Cocoon's implementation of ErrorListener. This has
been done in our code base, but existing applications will have to
update their cocoon.xconf.
Enjoy,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Refactored (again) XSLT error handling
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
> Ralph Goers wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>> <snip/>
>>>
>>>> Activating this second feature requires to change the XSLTProcessor
>>>> implementation to o.a.c.c.xslt.XSLTProcessorImpl
>>>
>>>
>>> Damn! While porting to the 2.1 branch, I realized that this conflict
>>> with the same class that exists in the "deprecated" block.
>>>
>>> What do you think: is it better to remove the old XSLTProcessorImpl,
>>> or rename the new class? I like simple and straightforward names for
>>> default implementations...
>>>
>> Follow the versioning contract. Assuming you can find it.
>
>
> Uh? Versioning contract?
>
> Sylvain
>
Yes. Some time ago we voted on how long things had to be deprecated
before they could be removed. For example, if the "old'
XSLTProcessorImpl was deprecated in 2.1.6 then it can be removed in
2.1.8 (or something like that - I don't remember off the top of my
head). If so, the deprecated version can be removed and you can add
your new one.
I thought that what was voted on was put on the web site somewhere but I
can't find it.
Ralph
Re: Refactored (again) XSLT error handling
Posted by Sylvain Wallez <sy...@apache.org>.
Ralph Goers wrote:
> Sylvain Wallez wrote:
>
>> Sylvain Wallez wrote:
>>
>> <snip/>
>>
>>> Activating this second feature requires to change the XSLTProcessor
>>> implementation to o.a.c.c.xslt.XSLTProcessorImpl
>>
>> Damn! While porting to the 2.1 branch, I realized that this conflict
>> with the same class that exists in the "deprecated" block.
>>
>> What do you think: is it better to remove the old XSLTProcessorImpl,
>> or rename the new class? I like simple and straightforward names for
>> default implementations...
>>
> Follow the versioning contract. Assuming you can find it.
Uh? Versioning contract?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Refactored (again) XSLT error handling
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
> Sylvain Wallez wrote:
>
> <snip/>
>
>> Activating this second feature requires to change the XSLTProcessor
>> implementation to o.a.c.c.xslt.XSLTProcessorImpl
>
>
> Damn! While porting to the 2.1 branch, I realized that this conflict
> with the same class that exists in the "deprecated" block.
>
> What do you think: is it better to remove the old XSLTProcessorImpl,
> or rename the new class? I like simple and straightforward names for
> default implementations...
>
> Sylvain
>
Follow the versioning contract. Assuming you can find it.
Ralph
Re: Refactored (again) XSLT error handling
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Sylvain Wallez wrote:
>
> <snip/>
>> Activating this second feature requires to change the XSLTProcessor
>> implementation to o.a.c.c.xslt.XSLTProcessorImpl
>
> Damn! While porting to the 2.1 branch, I realized that this conflict
> with the same class that exists in the "deprecated" block.
I renamed it to o.a.c.c.xslt.TraxProcessor, so no more name clash with
the deprecated class.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Refactored (again) XSLT error handling
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
<snip/>
> Activating this second feature requires to change the XSLTProcessor
> implementation to o.a.c.c.xslt.XSLTProcessorImpl
Damn! While porting to the 2.1 branch, I realized that this conflict
with the same class that exists in the "deprecated" block.
What do you think: is it better to remove the old XSLTProcessorImpl, or
rename the new class? I like simple and straightforward names for
default implementations...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director