(betwixt) work for a volunteer [was Re: digester data to XML]

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

On Tuesday, January 29, 2002, at 09:40 PM, Slawek Zachcial wrote:

> Hi,
>
> Can you list some betwixt points to be done? Maybe I
> could help? ;-)

hi

betwixt is really james's baby so i'll probably need to have a think about 
coming up with nice independent task(s) for you to look at. i'll get back 
to you a bit later with a details. that is unless james happens to be 
hanging around at the moment...

i've been concentrating on improving the java doc comments (so that i can 
really understand how it works). a good start would be to start looking at 
the doc comments. see if they make sense to you and see if you can improve 
them. if you've got any question please ask - i find i learn a lot by 
finding the answers to questions.

also take a look at the jakarta guidelines for submissions so you know how 
to submit patches properly.

hopefully i'll have a bit more time once logging is sorted out (one way or 
another) and we can really get cracking. (improved logging is my other 
initial betwixt priority.)

- robert


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

Re: (betwixt) work for a volunteer [was Re: digester data to XML]

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

From: "robert burrell donkin" <ro...@mac.com>
> > Sounds the right approach to me. Maybe just a Set of all beans traversed
> > would do, then as the bean tree is walked duplicates can be ignored.
>
> i've been thinking about this. maybe the right way to handle this would be
> by using IDs and IDREF's. betwixt could easily assign an ID to each
> element. when it came to a cyclic reference, it could then set the IDREF
> to point to the original.
>
> what do you think?

Great idea!

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) work for a volunteer [was Re: digester data to XML]

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

On Thursday, January 31, 2002, at 07:56 PM, James Strachan wrote:

> Hi Robert

hi james

> ----- Original Message -----
> From: "robert burrell donkin" <ro...@mac.com>
>> i still want to find a fix for that problem of circular references. i'd
>> really like to see what you think about the solution i've started on.
> (don'
>> t worry i haven't really done much work on it so it'll be no problem to
>> back it out again.)
>>
>> i think that fundamentally any solution comes around to being able to 
>> find
>> out which beans have been evaluated earlier (in the recursion) and not
>> evaluating any bean which has been evaluated earlier in the recursion. it
>> seems to me that the context is a good place to add new functionality
>> since it can be shared between different output implementations (i'm 
>> still
>> keen on that bean navigator you were talking about). so, the idea is that
>> to store an (optional) parent context in context. when you're evaluating
>> the next level in a recursion, rather than starting with a new context,
>> you start with a child context of the current level - and you check that
>> the bean you're about to recursively evaluate isn't already an ancester 
>> of
>> the current context.
>
> Sounds the right approach to me. Maybe just a Set of all beans traversed
> would do, then as the bean tree is walked duplicates can be ignored.

i've been thinking about this. maybe the right way to handle this would be 
by using IDs and IDREF's. betwixt could easily assign an ID to each 
element. when it came to a cyclic reference, it could then set the IDREF 
to point to the original.

what do you think?

- robert


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

Re: (betwixt) work for a volunteer [was Re: digester data to XML]

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

On Thursday, January 31, 2002, at 07:56 PM, James Strachan wrote:

> Hi Robert
>
> ----- Original Message -----
> From: "robert burrell donkin" <ro...@mac.com>
>> i still want to find a fix for that problem of circular references. i'd
>> really like to see what you think about the solution i've started on.
> (don'
>> t worry i haven't really done much work on it so it'll be no problem to
>> back it out again.)
>>
>> i think that fundamentally any solution comes around to being able to 
>> find
>> out which beans have been evaluated earlier (in the recursion) and not
>> evaluating any bean which has been evaluated earlier in the recursion. it
>> seems to me that the context is a good place to add new functionality
>> since it can be shared between different output implementations (i'm 
>> still
>> keen on that bean navigator you were talking about). so, the idea is that
>> to store an (optional) parent context in context. when you're evaluating
>> the next level in a recursion, rather than starting with a new context,
>> you start with a child context of the current level - and you check that
>> the bean you're about to recursively evaluate isn't already an ancester 
>> of
>> the current context.
>
> Sounds the right approach to me. Maybe just a Set of all beans traversed
> would do, then as the bean tree is walked duplicates can be ignored.
>
>
>> what do you think and should i hold off while you're looking at 
>> generating
>> digester rulesets?
>
> Go for it - after the work I've done today (which didn't change things 
> that
> much) we shouldn't tread on each others toes.
>
> Just as I was doing a commit I noticed my copy of the code was out of 
> date,
> so we've maybe merged codebases already ;-)

our emails keep crossing in the middle - but all's well that ends well! as 
luck would have it, i think that our codebases have merged without too 
many problems :)

i'll hold off working on that cyclic bug for a while (maybe i'll have a 
think about (c) on your list since we've got a willing victim whose 
promised to do (b)) until i know that you're not making changes to the 
core.

- robert


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

Re: (betwixt) work for a volunteer [was Re: digester data to XML]

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

Hi Robert

----- Original Message -----
From: "robert burrell donkin" <ro...@mac.com>
> i still want to find a fix for that problem of circular references. i'd
> really like to see what you think about the solution i've started on.
(don'
> t worry i haven't really done much work on it so it'll be no problem to
> back it out again.)
>
> i think that fundamentally any solution comes around to being able to find
> out which beans have been evaluated earlier (in the recursion) and not
> evaluating any bean which has been evaluated earlier in the recursion. it
> seems to me that the context is a good place to add new functionality
> since it can be shared between different output implementations (i'm still
> keen on that bean navigator you were talking about). so, the idea is that
> to store an (optional) parent context in context. when you're evaluating
> the next level in a recursion, rather than starting with a new context,
> you start with a child context of the current level - and you check that
> the bean you're about to recursively evaluate isn't already an ancester of
> the current context.

Sounds the right approach to me. Maybe just a Set of all beans traversed
would do, then as the bean tree is walked duplicates can be ignored.


> what do you think and should i hold off while you're looking at generating
> digester rulesets?

Go for it - after the work I've done today (which didn't change things that
much) we shouldn't tread on each others toes.

Just as I was doing a commit I noticed my copy of the code was out of date,
so we've maybe merged codebases already ;-)

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) work for a volunteer [was Re: digester data to XML]

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

On Wednesday, January 30, 2002, at 07:44 PM, James Strachan wrote:

> Hey Robert

hi james

>
> ----- Original Message -----
> From: "robert burrell donkin" <ro...@mac.com>
>>
>> On Tuesday, January 29, 2002, at 09:40 PM, Slawek Zachcial wrote:
>>
>>> Hi,
>>>
>>> Can you list some betwixt points to be done? Maybe I
>>> could help? ;-)
>>
>> hi
>>
>> betwixt is really james's baby so i'll probably need to have a think 
>> about
>> coming up with nice independent task(s) for you to look at. i'll get back
>> to you a bit later with a details. that is unless james happens to be
>> hanging around at the moment...
>
> I'm still around - funnily enough betwixt is next on my list of things to
> do...

cool :)

i'm finished with logging now so i've begun looking at betwixt.
(i've read the rest but i think it (might) make more sense to reply here)

i still want to find a fix for that problem of circular references. i'd 
really like to see what you think about the solution i've started on. (don'
t worry i haven't really done much work on it so it'll be no problem to 
back it out again.)

i think that fundamentally any solution comes around to being able to find 
out which beans have been evaluated earlier (in the recursion) and not 
evaluating any bean which has been evaluated earlier in the recursion. it 
seems to me that the context is a good place to add new functionality 
since it can be shared between different output implementations (i'm still 
keen on that bean navigator you were talking about). so, the idea is that 
to store an (optional) parent context in context. when you're evaluating 
the next level in a recursion, rather than starting with a new context, 
you start with a child context of the current level - and you check that 
the bean you're about to recursively evaluate isn't already an ancester of 
the current context.

what do you think and should i hold off while you're looking at generating 
digester rulesets?

>
> A couple of things I was going to try attempt in the next few days.
>
> (a) use betwixt to generate a Digester for a given bean. e.g. given a
> PurchaseOrder bean class it should hopefully be possible to either 
> generate
> a SAX parser or a Digester from the bean <-> XML metadata. Then it'd be
> possible to autogenerate Digester's (or SAX parsers) from bean classes to
> read beans from XML.
>
> (b) introduce a way of coding XMLBeanInfo classes for JavaBeans in a 
> similar
> way to writing BeanInfo classes for beans can customize the default XML
> introspection.
>
> (c) devise an XML document as an alternative to the XMLBeanInfo class
> mechanism to allow easy customization of the XML format of several beans.
> e.g. if there is a package of beans it might be nice to have a simple XML
> document where the 'look and feel' of the beans in XML can be customized 
> -
> e.g. names of properties changed in the XML format, things turned from
> elements to attributes etc.
>
>
> I was going to try tackle (a) first as it may mean that the expression
> package might be enhanced to make it easier to go from XML -> bean rather
> than the other way. If anyone fancies diving into (b) or (c) you're more
> than welcome.
>
>
>> i've been concentrating on improving the java doc comments (so that i can
>> really understand how it works). a good start would be to start looking 
>> at
>> the doc comments. see if they make sense to you and see if you can 
>> improve
>> them. if you've got any question please ask - i find i learn a lot by
>> finding the answers to questions.
>>
>> also take a look at the jakarta guidelines for submissions so you know 
>> how
>> to submit patches properly.
>>
>> hopefully i'll have a bit more time once logging is sorted out (one way 
>> or
>> another) and we can really get cracking. (improved logging is my other
>> initial betwixt priority.)
>
> Sounds great. BTW thanks for all your help Robert.
>
> James
>
>>
>> - robert
>>
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> 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>

Re: (betwixt) work for a volunteer [was Re: digester data to XML]

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

Hey Robert

----- Original Message -----
From: "robert burrell donkin" <ro...@mac.com>
>
> On Tuesday, January 29, 2002, at 09:40 PM, Slawek Zachcial wrote:
>
> > Hi,
> >
> > Can you list some betwixt points to be done? Maybe I
> > could help? ;-)
>
> hi
>
> betwixt is really james's baby so i'll probably need to have a think about
> coming up with nice independent task(s) for you to look at. i'll get back
> to you a bit later with a details. that is unless james happens to be
> hanging around at the moment...

I'm still around - funnily enough betwixt is next on my list of things to
do...

A couple of things I was going to try attempt in the next few days.

(a) use betwixt to generate a Digester for a given bean. e.g. given a
PurchaseOrder bean class it should hopefully be possible to either generate
a SAX parser or a Digester from the bean <-> XML metadata. Then it'd be
possible to autogenerate Digester's (or SAX parsers) from bean classes to
read beans from XML.

(b) introduce a way of coding XMLBeanInfo classes for JavaBeans in a similar
way to writing BeanInfo classes for beans can customize the default XML
introspection.

(c) devise an XML document as an alternative to the XMLBeanInfo class
mechanism to allow easy customization of the XML format of several beans.
e.g. if there is a package of beans it might be nice to have a simple XML
document where the 'look and feel' of the beans in XML can be customized -
e.g. names of properties changed in the XML format, things turned from
elements to attributes etc.


I was going to try tackle (a) first as it may mean that the expression
package might be enhanced to make it easier to go from XML -> bean rather
than the other way. If anyone fancies diving into (b) or (c) you're more
than welcome.


> i've been concentrating on improving the java doc comments (so that i can
> really understand how it works). a good start would be to start looking at
> the doc comments. see if they make sense to you and see if you can improve
> them. if you've got any question please ask - i find i learn a lot by
> finding the answers to questions.
>
> also take a look at the jakarta guidelines for submissions so you know how
> to submit patches properly.
>
> hopefully i'll have a bit more time once logging is sorted out (one way or
> another) and we can really get cracking. (improved logging is my other
> initial betwixt priority.)

Sounds great. BTW thanks for all your help Robert.

James

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


_________________________________________________________
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>