[Betwixt] ID-IDREF solution to cyclic reference problem

[robert burrell donkin <ro...@mac.com>]

i've just committed code that stamps IDs on elements and then uses IDREFs 
to solve the cyclic reference problem. it's been delayed since it took me 
a while to find a good way to implement it.

i should probably say something about the changes to 
org.apache.commons.betwixt.io.BeanWriter since they are quite extensive. i'
ve tried to separate the actual writing from the logic concerning 
processing the descriptors . the writing code should now live in small 
expressXXX methods and some duplication has been reduced.

it's hard to write good unit test code for betwixt and so i may have 
introduced new bugs. any bug reports will be gratefully received.

- robert


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

Re: [Betwixt] ID-IDREF solution to cyclic reference problem

[robert burrell donkin <ro...@mac.com>]

hi james

On Tuesday, February 26, 2002, at 05:33 AM, James Strachan wrote:

> From: "robert burrell donkin" <ro...@mac.com>

<snip>

>> i should probably say something about the changes to
>> org.apache.commons.betwixt.io.BeanWriter since they are quite extensive.
> i'
>> ve tried to separate the actual writing from the logic concerning
>> processing the descriptors . the writing code should now live in small
>> expressXXX methods and some duplication has been reduced.
>
> Cool.
>
> I've been musing over possible ways to make it easy for users of betwixt 
> to
> 'walk' the XML tree for a certain bean. Maybe once there's a few different
> ways of outputting a bean, text, SAX & DOM (*) then we could maybe 
> refactor
> the code to make it easier & share code. Just thinking aloud here...

this is pretty much what i was (am) thinking too :)

the logic's too complex to get right in different places without sharing. 
i'd like to pull out all the logic into an abstract superclass which will 
call expressXXX type methods. this should make it easier to implement 
other ways of output since it should be clear which methods are required. 
i agree that the signatures will be probably change a lot once we start 
looking at different implementation but hopefully they'd give us some sort 
of basis to start with.

- robert


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

Re: [Betwixt] ID-IDREF solution to cyclic reference problem

[James Strachan <ja...@yahoo.co.uk>]

From: "robert burrell donkin" <ro...@mac.com>
> i've just committed code that stamps IDs on elements and then uses IDREFs
> to solve the cyclic reference problem. it's been delayed since it took me
> a while to find a good way to implement it.

Thanks robert - it looks great.

> i should probably say something about the changes to
> org.apache.commons.betwixt.io.BeanWriter since they are quite extensive.
i'
> ve tried to separate the actual writing from the logic concerning
> processing the descriptors . the writing code should now live in small
> expressXXX methods and some duplication has been reduced.

Cool.

I've been musing over possible ways to make it easy for users of betwixt to
'walk' the XML tree for a certain bean. Maybe once there's a few different
ways of outputting a bean, text, SAX & DOM (*) then we could maybe refactor
the code to make it easier & share code. Just thinking aloud here...

(*) if we had a DOM implementation based on betwixt then we could do XSLT on
beans which would be kinda cool. The domify project at SF does pretty much
the same thing though it doesn't support customizable mappings of beans to
XML. Also its easy to pipe DOM (or SAX) to other models like dom4j and JDOM.

> it's hard to write good unit test code for betwixt

Agreed - it might be worth trying out xmlunit or something for testing...

> and so i may have
> introduced new bugs. any bug reports will be gratefully received.

Things look OK so far :)

James



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