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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to