commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [Betwixt] Some ideas
Date Sat, 15 Jun 2002 13:07:07 GMT
From: "robert burrell donkin" <>
> On Friday, June 14, 2002, at 05:08 AM, James Strachan wrote:
> > From: "Stephen Colebourne" <>
> >> 2) ID's as Strings - Betwixt uses ints for it's ID/IDREF values (to
> >> handle
> >> recursion). I needed Strings, to allow for more complex generated ids
> >> including IP ref etc. This would be a faily easy change to make, but
> >> after
> > a
> >> release it would break backwards compatability?
> >
> > This sounds cool I think. The use of ID/IDREF is optional anyways so it
> > shouldn't break anything.
> this is an improvement and it should be quick and easy. i'll take a look
> at this.

I would ideally like to see the id generator separated from Betwixt. Not
sure where it fits, lang maybe, but thats still in the sandbox and is very
quiet. Basically, I don't see id generation as something specific to

> >> 3) ID's controlled on a per object basis - I created an Identifiable
> >> interface with getIdentifier and setIdentifier methods. Those beans
> >> implemented it outputted an ID/IDREF. Those which didn't implement it
> >> were
> >> output directly, with the potential for (the exception case) recursion.
> >
> > Not totallyl sure how this would work but it sounds very reasonable.
> > registering some kind of Resolver to lookup beans for some kind of ID;
> > though you can use straight Digester code for that too.
> at the moment, you have a choice between having all elements with ID
> attributes or none. you'd like the ability to control which elements have
> IDs and which don't so that you can have some elements with IDs and some
> without. if a cycle occurred with a bean with an ID then an IDREF would be
> written. otherwise an exception would be thrown.

Consider when object A holds reference to two instances of object B, A is
Identifiable, there are three cases:
1) Object B is not Identifiable.
In this case, no IDs or IDREFs are output. If B holds a reference to A an
exception is thrown.

2) Object B is Identifiable and you want 'normal' compact output..
In this case an ID is output for the first B, and an IDREF for the second.

3) Object B is Identifiable and you want 'expanded' output.
In this case, both instances of B output an ID and their full structure. If
B holds a reference to A an IDREF is used. Thus in this case, the structure
is expanded as much as possible, with IDREF only being used as a last

I use case 3 is for Xpath traversal where the xpath doesn't recognise the
ID/IDREF, thus the expanded structure is needed.

> (i need to check this but) i think that you can already custom betwixt so
> that you can set the ID from a property of the bean. so this is really
> adding another way to achieve something that can be done already (but
> s not necessarily a bad thing). using interfaces is a bit against the
> betwixt philosophy but since i can see that some users will probably
> prefer them i have no great objections. (i don't know if other people
> would take different views on this.)
> beans with this interface could be automatically marked as supporting IDs
> but the converse would not be the case. this shouldn't take a lot of work
> but would rely on the first bit.

Part of the interface is that the ID must be set back again when the object
is read in.

I also support the alphabetic ordering of output proposal elsewhere.

> > 5) End of  line handling - I have read in the JDOM source code that the
> > of line in XML documents must be \n on all systems. So should betwixt
> > the setEndOfLine() method on BeanWriter?

> Agreed. Yes "\n" is the default for XML (its like that in dom4j too ;-).

I was also a little unclear if James' comments on setEndOfLine() meant that
the method was going to be removed.

Thanks for considering these. I should, in all fairness however, point out
that even with all these changes I won't be able to use Betwixt out of the
box. The key issue for me will in the end be the dependence on BeanUtils
default Introspection lookup. I hope to start a thread on this soon. But I
don't expect that to be fixed for a 1.0 release.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message