Need input on new CastorTransformer (marshal/unmarshal)

[Michael Homeijer <M....@devote.nl>]

Hi,

I rewrote the current CastorTransformer to support both marshalling and
unmarshalling of XML/Java. I am looking for someone to take a serious look
at the code before the transformer is donated back to cocoon.

The following has changed:
- Removed deprecated code, used Castor through a ContentHandler
- Tag castor:marshal now replaces the castor:InsertBean tag.
- Tag castor:unmarshal unmarshalls XML to Java.
- Added the option to execute pre and post commands. This enables you to
influence castor (add listeners and stuff) or request a bean from a database
or store the bean somewhere after unmarshalling.
- Removed the default mapping. It makes as much sense as having a default
xsl style-sheet in your xslt transformer. Mappings are cached anyway.

Now that castor is used through a ContentHandler, the system property
org.xml.sax.parser has to be set. I use a piece of static code that checks
the availability of several parsers and sets the property if one is found.
Is there a cleaner alternative to this?

I need some input on the error handling. What errors should be thrown and
what should only be logged?

There's a small namespace problem in the unmarshal proces. If the xml to be
unmarshalled contains namespaces (eg. xsi:) the unmarshalling will fail
because the startprefixmapping is probably called before castor is setup?

TIA,
Michael

Re: Need input on new CastorTransformer (marshal/unmarshal)

[Vadim Gritsenko <va...@verizon.net>]

Michael Homeijer wrote:

>Hi,
>

Michael,


>I rewrote the current CastorTransformer to support both marshalling and
>unmarshalling of XML/Java. I am looking for someone to take a serious look
>at the code before the transformer is donated back to cocoon.
>
>The following has changed:
>- Removed deprecated code, used Castor through a ContentHandler
>- Tag castor:marshal now replaces the castor:InsertBean tag.
>- Tag castor:unmarshal unmarshalls XML to Java.
>- Added the option to execute pre and post commands. This enables you to
>influence castor (add listeners and stuff) or request a bean from a database
>or store the bean somewhere after unmarshalling.
>- Removed the default mapping. It makes as much sense as having a default
>xsl style-sheet in your xslt transformer. Mappings are cached anyway.
>
>Now that castor is used through a ContentHandler, the system property
>org.xml.sax.parser has to be set. I use a piece of static code that checks
>the availability of several parsers and sets the property if one is found.
>Is there a cleaner alternative to this?
>

Better would be to use Cocoon's Parser, if it is possible...


>I need some input on the error handling. What errors should be thrown and
>what should only be logged?
>
>There's a small namespace problem in the unmarshal proces. If the xml to be
>unmarshalled contains namespaces (eg. xsi:) the unmarshalling will fail
>because the startprefixmapping is probably called before castor is setup?
>

You need to cache all prefix mappings which are occuring before your 
first <castor: /> tag. See SourceWritingTransformer, or any similar.

Vadim



>TIA,
>Michael
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org