You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@eurobell.co.uk> on 2002/06/13 23:16:09 UTC
[Betwixt] Some ideas
Hi,
A while back I looked at using Betwixt for my Bean to XML generation (Joda).
In the end I rolled my own (time pressure was a factor), but I would still
like to refactor Joda to use betwixt if possible in the longer term.
As you are talking about a 1.0 release, I thought I'd jot down some of the
ideas which I implemented in my Bean to XML code that aren't (yet) in
betwixt. Maybe some might make it to the todo list?
1) SAX outputter - I believe this is on the todo list already ;-)
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?
3) ID's controlled on a per object basis - I created an Identifiable
interface with getIdentifier and setIdentifier methods. Those beans which
implemented it outputted an ID/IDREF. Those which didn't implement it were
output directly, with the potential for (the exception case) recursion.
4) Subclass handling - When I last looked, I could find no automatic
handling of class hierarchies. For example, the automatic generation of a
type attribute if the class being output is a subclass of that expected.
5) End of line handling - I have read in the JDOM source code that the end
of line in XML documents must be \n on all systems. So should betwixt have
the setEndOfLine() method on BeanWriter?
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] line endings (WAS : Re: [Betwixt] Some ideas)
Posted by Martin van den Bemt <ml...@mvdb.net>.
Fixed.. I have chosen to show a warning instead of an Exception.
I also added a testCase for it ;)
Mvgr,
Martin
On Sat, 2002-06-15 at 23:01, Stephen Colebourne wrote:
> ----- Original Message -----
> From: "Martin van den Bemt" <ml...@mvdb.net>
> > Hmm.. mindspin coming up.. Since you can currently set any character you
> > like, we could just allow valid characters, which doesn't "choke"
> > parsers..
>
> I support that
> Stephen
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] line endings (WAS : Re: [Betwixt] Some ideas)
Posted by Stephen Colebourne <sc...@btopenworld.com>.
----- Original Message -----
From: "Martin van den Bemt" <ml...@mvdb.net>
> Hmm.. mindspin coming up.. Since you can currently set any character you
> like, we could just allow valid characters, which doesn't "choke"
> parsers..
I support that
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Betwixt] line endings (WAS : Re: [Betwixt] Some ideas)
Posted by Martin van den Bemt <ml...@mvdb.net>.
Hmm afaik a parser should just parse, and not care how line endings or
formatting is done, when reading the file, so there is no risk in
different line endings (you can use tabs, spaces, lf, cr or no line
endings).
If a parsers chockes on those, replace it one that works..
Hmm.. mindspin coming up.. Since you can currently set any character you
like, we could just allow valid characters, which doesn't "choke"
parsers..
Mvgr,
martin
On Sat, 2002-06-15 at 22:32, Stephen Colebourne wrote:
> I guess so long as \n is the default having the method doesn't overly harm.
> Use at your own risk!
>
> Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I guess so long as \n is the default having the method doesn't overly harm.
Use at your own risk!
Stephen
----- Original Message -----
From: "Martin van den Bemt" <ml...@mvdb.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, June 15, 2002 9:16 PM
Subject: Re: [Betwixt] Some ideas
> <snippet from the xml spec>
> 2.11 End-of-Line Handling
>
> To be exactXML parsed entities are often stored in computer files which,
> for editing convenience, are organized into lines. These lines are
> typically separated by some combination of the characters
> carriage-return (#xD) and line-feed (#xA).
>
> To simplify the tasks of applications, the characters passed to an
> application by the XML processor must be as if the XML processor
> normalized all line breaks in external parsed entities (including the
> document entity) on input, before parsing, by translating both the
> two-character sequence #xD #xA and any #xD that is not followed by #xA
> to a single #xA character.
> <end snippet of the xml spec>
>
> So we expect the \n from the parser, we don't have to write it that way
> ;)
> (hmm really troubled here.. I searched on the word line before and it
> didn't turn up anything, am I getting crazy here??..)
>
>
> Mvgr,
> Martin
>
>
> On Sat, 2002-06-15 at 22:03, Stephen Colebourne wrote:
> > If you've checked the spec, then I withdraw the request ;-)
> > Stephen
> > ----- Original Message -----
> > From: "Martin van den Bemt" <ml...@mvdb.net>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> > Sent: Saturday, June 15, 2002 8:46 PM
> > Subject: Re: [Betwixt] Some ideas
> >
> >
> > > Hi Stephen,
> > >
> > > >
> > > > > 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.
> > >
> > > It defaults now to the default used in some packages and I like the
> > > fact that I can set it to something different. Also I couldn't find
any
> > > reference in the XML specification 1.0 that line endings should be \n.
> > >
> > > Mvgr,
> > > Martin
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by Martin van den Bemt <ml...@mvdb.net>.
<snippet from the xml spec>
2.11 End-of-Line Handling
To be exactXML parsed entities are often stored in computer files which,
for editing convenience, are organized into lines. These lines are
typically separated by some combination of the characters
carriage-return (#xD) and line-feed (#xA).
To simplify the tasks of applications, the characters passed to an
application by the XML processor must be as if the XML processor
normalized all line breaks in external parsed entities (including the
document entity) on input, before parsing, by translating both the
two-character sequence #xD #xA and any #xD that is not followed by #xA
to a single #xA character.
<end snippet of the xml spec>
So we expect the \n from the parser, we don't have to write it that way
;)
(hmm really troubled here.. I searched on the word line before and it
didn't turn up anything, am I getting crazy here??..)
Mvgr,
Martin
On Sat, 2002-06-15 at 22:03, Stephen Colebourne wrote:
> If you've checked the spec, then I withdraw the request ;-)
> Stephen
> ----- Original Message -----
> From: "Martin van den Bemt" <ml...@mvdb.net>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Saturday, June 15, 2002 8:46 PM
> Subject: Re: [Betwixt] Some ideas
>
>
> > Hi Stephen,
> >
> > >
> > > > 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.
> >
> > It defaults now to the default used in some packages and I like the
> > fact that I can set it to something different. Also I couldn't find any
> > reference in the XML specification 1.0 that line endings should be \n.
> >
> > Mvgr,
> > Martin
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by Stephen Colebourne <sc...@btopenworld.com>.
If you've checked the spec, then I withdraw the request ;-)
Stephen
----- Original Message -----
From: "Martin van den Bemt" <ml...@mvdb.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, June 15, 2002 8:46 PM
Subject: Re: [Betwixt] Some ideas
> Hi Stephen,
>
> >
> > > 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.
>
> It defaults now to the default used in some packages and I like the
> fact that I can set it to something different. Also I couldn't find any
> reference in the XML specification 1.0 that line endings should be \n.
>
> Mvgr,
> Martin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by Martin van den Bemt <ml...@mvdb.net>.
Hi Stephen,
>
> > 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.
It defaults now to the default used in some packages and I like the
fact that I can set it to something different. Also I couldn't find any
reference in the XML specification 1.0 that line endings should be \n.
Mvgr,
Martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by Martin van den Bemt <ml...@mvdb.net>.
On Tue, 2002-06-18 at 13:41, James Strachan wrote:
> From: "Stephen Colebourne" <sc...@btopenworld.com>
> > I was also a little unclear if James' comments on setEndOfLine() meant
> that
> > the method was going to be removed.
>
> No not at all. From memory, I think that the default line ending should be
> "\n" though I can't remember where that memory comes from ;-). I think its
> in the XML spec somewhere...
According to the spec the xml parser should give \n line endings to the
application, it doesn't say it only has to be written that way.. So
betwixt needs to get \n line endings from the xmlparser ;)
(there is a message somewhere whith a paste of this, in this thread..)
Mvgr,
Martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Stephen Colebourne" <sc...@btopenworld.com>
> I was also a little unclear if James' comments on setEndOfLine() meant
that
> the method was going to be removed.
No not at all. From memory, I think that the default line ending should be
"\n" though I can't remember where that memory comes from ;-). I think its
in the XML spec somewhere...
> 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.
OK. Though I hope we can overcome this problem ;-)
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by robert burrell donkin <ro...@mac.com>.
On Saturday, June 15, 2002, at 02:07 PM, Stephen Colebourne wrote:
> From: "robert burrell donkin" <ro...@mac.com>
>> On Friday, June 14, 2002, at 05:08 AM, James Strachan wrote:
>>> From: "Stephen Colebourne" <sc...@eurobell.co.uk>
>>
>>>> 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
> betwixt/XML.
i agree that it isn't specifically betwixt related but it's something that
can easily be factored out later.
i think that maybe one of the differences between excalibur and the
commons is that avalon is more concerned with designing the optimal
solution whereas in the commons the growth is more organic. i'd rather add
the feature to betwixt now and then move to a common solution later when
it emerges than wait.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <ro...@mac.com>
> On Friday, June 14, 2002, at 05:08 AM, James Strachan wrote:
> > From: "Stephen Colebourne" <sc...@eurobell.co.uk>
>
> >> 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
betwixt/XML.
> >> 3) ID's controlled on a per object basis - I created an Identifiable
> >> interface with getIdentifier and setIdentifier methods. Those beans
which
> >> 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.
Maybe
> > 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
resort.
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
that'
> 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
end
> > of line in XML documents must be \n on all systems. So should betwixt
have
> > 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.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by robert burrell donkin <ro...@mac.com>.
hi Stephen
i've been having a think and i don't really see why we shouldn't get
something along these lines in for the release. see in line for more...
On Friday, June 14, 2002, at 05:08 AM, James Strachan wrote:
> From: "Stephen Colebourne" <sc...@eurobell.co.uk>
>> 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.
>> 3) ID's controlled on a per object basis - I created an Identifiable
>> interface with getIdentifier and setIdentifier methods. Those beans which
>> 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. Maybe
> registering some kind of Resolver to lookup beans for some kind of ID;
> though you can use straight Digester code for that too.
i think i understand what it is you need but i'm not 100% sure. hopefully
you'll correct me when if i've got it wrong...
as i see it, from a betwixt point of view there are two different bits
first bit is per bean ID control...
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.
from a betwixt perspective, this information belongs in the XMLBeanInfo.
the XMLIntospector could use a property to determine the default. giving
the same functionality as at present.
in order to implement, we'd need to go through and alter the cyclic
reference code. this isn't a massive change but needs to be done carefully.
if necessary, this feature could be left until a 1,1 release.
the other bit is the interfaces...
(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 that'
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.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Stephen
From: "Stephen Colebourne" <sc...@eurobell.co.uk>
> Hi,
> A while back I looked at using Betwixt for my Bean to XML generation
(Joda).
> In the end I rolled my own (time pressure was a factor), but I would still
> like to refactor Joda to use betwixt if possible in the longer term.
>
> As you are talking about a 1.0 release, I thought I'd jot down some of the
> ideas which I implemented in my Bean to XML code that aren't (yet) in
> betwixt. Maybe some might make it to the todo list?
>
> 1) SAX outputter - I believe this is on the todo list already ;-)
:-)
> 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.
> 3) ID's controlled on a per object basis - I created an Identifiable
> interface with getIdentifier and setIdentifier methods. Those beans which
> 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. Maybe
registering some kind of Resolver to lookup beans for some kind of ID;
though you can use straight Digester code for that too.
> 4) Subclass handling - When I last looked, I could find no automatic
> handling of class hierarchies. For example, the automatic generation of a
> type attribute if the class being output is a subclass of that expected.
Agreed - this would be nice.
> 5) End of line handling - I have read in the JDOM source code that the
end
> of line in XML documents must be \n on all systems. So should betwixt have
> the setEndOfLine() method on BeanWriter?
Agreed. Yes "\n" is the default for XML (its like that in dom4j too ;-).
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by robert burrell donkin <ro...@mac.com>.
On Friday, June 14, 2002, at 06:36 PM, Martin van den Bemt wrote:
> Hi Robert,
hi martin
> What are you currently working on ? I don't want to duplicate the effort
> and waste your or mine time on that..
i really want to find some solution for the scarab problem.
i don't have very much coding time at the moment so don't let me stop you.
as long as i know what you're working on, we shouldn't be wasting our
time. i think that it's often useful (in any case) to post up what you
intend to look at next (i certainly try to do it myself) since you can get
feedback and tips from other people before you start.
> I don't have anything spefically in mind right now for myself (besides
> the todo list ofcourse)..
most of Stephen's wants list are to do with the ID stuff so it should be
easier and quicker for me to code them but don't let that stop you :)
> Hmm a bugdatabase would be really nice so you can assign this to
> yourself..
we should be able to get betwixt listed on bugzilla but i don't know how
to get this done.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by Martin van den Bemt <ml...@mvdb.net>.
Hi Robert,
What are you currently working on ? I don't want to duplicate the effort
and waste your or mine time on that..
I don't have anything spefically in mind right now for myself (besides
the todo list ofcourse)..
Hmm a bugdatabase would be really nice so you can assign this to
yourself..
I hope to get started in about 2 hours, if the 4 tomcat servers I am
upgrading now are cooperating..
Mvgr,
Martin
On Fri, 2002-06-14 at 18:52, robert burrell donkin wrote:
> hi stephen
>
> i think that we're hoping to make the 1.0 release a quick one so that
> scarab and maven can use it. i've had a quick look and you've got some
> interesting ideas but i need to concentrate on making betwixt work with
> those components (they are waiting on betwixt for their release).
>
> i don't think that your improvements will break backwards compatibility
> too badly - and if it turned out that they do, there's no reason we couldn'
> t go for an early 2.0 release.
>
> - robert
>
> On Thursday, June 13, 2002, at 10:16 PM, Stephen Colebourne wrote:
>
> > Hi,
> > A while back I looked at using Betwixt for my Bean to XML generation
> > (Joda).
> > In the end I rolled my own (time pressure was a factor), but I would still
> > like to refactor Joda to use betwixt if possible in the longer term.
> >
> > As you are talking about a 1.0 release, I thought I'd jot down some of the
> > ideas which I implemented in my Bean to XML code that aren't (yet) in
> > betwixt. Maybe some might make it to the todo list?
> >
> > 1) SAX outputter - I believe this is on the todo list already ;-)
> >
> > 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?
> >
> > 3) ID's controlled on a per object basis - I created an Identifiable
> > interface with getIdentifier and setIdentifier methods. Those beans which
> > implemented it outputted an ID/IDREF. Those which didn't implement it were
> > output directly, with the potential for (the exception case) recursion.
> >
> > 4) Subclass handling - When I last looked, I could find no automatic
> > handling of class hierarchies. For example, the automatic generation of a
> > type attribute if the class being output is a subclass of that expected.
> >
> > 5) End of line handling - I have read in the JDOM source code that the
> > end
> > of line in XML documents must be \n on all systems. So should betwixt have
> > the setEndOfLine() method on BeanWriter?
> >
> > Stephen
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.
> > org>
> > For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
> > org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] Some ideas
Posted by robert burrell donkin <ro...@mac.com>.
hi stephen
i think that we're hoping to make the 1.0 release a quick one so that
scarab and maven can use it. i've had a quick look and you've got some
interesting ideas but i need to concentrate on making betwixt work with
those components (they are waiting on betwixt for their release).
i don't think that your improvements will break backwards compatibility
too badly - and if it turned out that they do, there's no reason we couldn'
t go for an early 2.0 release.
- robert
On Thursday, June 13, 2002, at 10:16 PM, Stephen Colebourne wrote:
> Hi,
> A while back I looked at using Betwixt for my Bean to XML generation
> (Joda).
> In the end I rolled my own (time pressure was a factor), but I would still
> like to refactor Joda to use betwixt if possible in the longer term.
>
> As you are talking about a 1.0 release, I thought I'd jot down some of the
> ideas which I implemented in my Bean to XML code that aren't (yet) in
> betwixt. Maybe some might make it to the todo list?
>
> 1) SAX outputter - I believe this is on the todo list already ;-)
>
> 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?
>
> 3) ID's controlled on a per object basis - I created an Identifiable
> interface with getIdentifier and setIdentifier methods. Those beans which
> implemented it outputted an ID/IDREF. Those which didn't implement it were
> output directly, with the potential for (the exception case) recursion.
>
> 4) Subclass handling - When I last looked, I could find no automatic
> handling of class hierarchies. For example, the automatic generation of a
> type attribute if the class being output is a subclass of that expected.
>
> 5) End of line handling - I have read in the JDOM source code that the
> end
> of line in XML documents must be \n on all systems. So should betwixt have
> the setEndOfLine() method on BeanWriter?
>
> Stephen
>
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.
> org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
> org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>