You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jason van Zyl <jv...@zenplex.com> on 2002/03/10 04:13:02 UTC
[betwixt] Default Behaviour
Hi James,
I'm just looking over the maven project descriptor in the tests and I
was thinking again about a 'standard' format for XML files and was
wondering if you had any opinions?
Using all lower case:
<project>
...
</project>
Where the root element matches to a Project class.
And something like:
<short-description>Project Management Tool</short-description>
and having that map to the setShortDescription(String) property.
Or having the XML elements have Java variable looking names like:
<Project>
...
</Project>
and
<shortDescription>...</shortDescription>
I honestly prefer the lower case with hypens but I'm not all that fussy.
I will use the default behavior of betwixt to map everything that I've
used my little mapper for so that all things Turbine will eventually use
the a common format so that mapping will be consistent, error free and
easy.
Also how are nested objects created? Are they expected to be in the same
package as the parent class?
So if I have:
<project>
<mailing-lists>
<mailing-list>
<name/>
<description/>
<subscribe/>
<unsubscribe/>
<archive/>
</mailing-list>
</mailing-lists>
</project>
Is the MailingList class expected to be in the same package as Project
class?
Also would you mind if something like the following was added as default
behaviour:
<pipeline>
<valve className="o.a.t.valve.Valve1"/>
<valve className="o.a.t.valve.Valve2"/>
</pipeline>
Where the className attribute would be used to instantiate the desired
object?
In the little mapper I made I used attributes as mapping information and
the elements as bean data. Maybe you are doing the same but I'm just
getting familiar with betwixt but I love it so far it's exactly what
I've been wanting I just didn't know it :-)
--
jvz.
Jason van Zyl
jvanzyl@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [betwixt] Default Behaviour
Posted by Jason van Zyl <jv...@zenplex.com>.
On Sat, 2002-03-09 at 22:13, Jason van Zyl wrote:
>
> <pipeline>
> <valve className="o.a.t.valve.Valve1"/>
> <valve className="o.a.t.valve.Valve2"/>
> </pipeline>
>
Correction:
<pipeline>
<valve-list>
<valve className="o.a.t.valve.Valve1"/>
<valve className="o.a.t.valve.Valve2"/>
<valve-list>
</pipeline>
>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@apache.org
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [betwixt] Default Behaviour
Posted by robert burrell donkin <ro...@mac.com>.
On Monday, March 11, 2002, at 01:39 AM, James Strachan wrote:
> James
> ----- Original Message -----
> From: "Jason van Zyl" <jv...@zenplex.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Sunday, March 10, 2002 3:13 AM
> Subject: [betwixt] Default Behaviour
<snip>
>> In the little mapper I made I used attributes as mapping information and
>> the elements as bean data. Maybe you are doing the same but I'm just
>> getting familiar with betwixt but I love it so far it's exactly what
>> I've been wanting I just didn't know it :-)
>
> :-) thats great to hear!
>
> I'd hope betwixt could be flexible enough to do it easily. e.g. ID & IDREF
> generation is kinda mapping information. I'm sure there could/should be
> others - like class names to use etc. So long as this kinda stuff is
> pluggable/configurable then we should all be happy. It wouldn't do any
> harm
> to output className by default and for the BeanReader to use it if its
> there
> though with stuff like RSS some folks might want to disable it to ensure
> compliance with external DTDs or schemas etc. Ditto for ID generation etc.
you should be able to turning ID generation on and off through
get/setWriteIDs property on BeanWriter. if WriteIDs is false then
BeanWriter doesn't write IDs and should throw a CycleReferenceException
when it encounters a cyclic reference.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [betwixt] Default Behaviour
Posted by James Strachan <ja...@yahoo.co.uk>.
James
----- Original Message -----
From: "Jason van Zyl" <jv...@zenplex.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, March 10, 2002 3:13 AM
Subject: [betwixt] Default Behaviour
> Hi James,
>
> I'm just looking over the maven project descriptor in the tests and I
> was thinking again about a 'standard' format for XML files and was
> wondering if you had any opinions?
>
> Using all lower case:
>
> <project>
> ...
> </project>
>
> Where the root element matches to a Project class.
>
> And something like:
>
> <short-description>Project Management Tool</short-description>
>
> and having that map to the setShortDescription(String) property.
>
> Or having the XML elements have Java variable looking names like:
>
> <Project>
> ...
> </Project>
>
> and
>
> <shortDescription>...</shortDescription>
>
> I honestly prefer the lower case with hypens but I'm not all that fussy.
I kinda prefer the latter with mixedCase starting with lower case but thats
just me. Though I guess the Betwixt component should allow pluggable default
naming schemes using a Strategy pattern.
> I will use the default behavior of betwixt to map everything that I've
> used my little mapper for so that all things Turbine will eventually use
> the a common format so that mapping will be consistent, error free and
> easy.
>
> Also how are nested objects created? Are they expected to be in the same
> package as the parent class?
No. Betwixt uses Java Bean introspection to figure things out so it
shouldn't matter. (Though this does mean that types need to be registered
with the BeanReader for it to figure out what to parse).
> So if I have:
>
> <project>
> <mailing-lists>
> <mailing-list>
> <name/>
> <description/>
> <subscribe/>
> <unsubscribe/>
> <archive/>
> </mailing-list>
> </mailing-lists>
> </project>
>
> Is the MailingList class expected to be in the same package as Project
> class?
No it should work whatever the package.
> Also would you mind if something like the following was added as default
> behaviour:
>
> <pipeline>
> <valve className="o.a.t.valve.Valve1"/>
> <valve className="o.a.t.valve.Valve2"/>
> </pipeline>
>
> Where the className attribute would be used to instantiate the desired
> object?
I guess this is a bit like Robert's ID generation stuff. We should add it as
a feature / strategy and allow folks to turn it on or off by default or on a
class-by-class basis.
> In the little mapper I made I used attributes as mapping information and
> the elements as bean data. Maybe you are doing the same but I'm just
> getting familiar with betwixt but I love it so far it's exactly what
> I've been wanting I just didn't know it :-)
:-) thats great to hear!
I'd hope betwixt could be flexible enough to do it easily. e.g. ID & IDREF
generation is kinda mapping information. I'm sure there could/should be
others - like class names to use etc. So long as this kinda stuff is
pluggable/configurable then we should all be happy. It wouldn't do any harm
to output className by default and for the BeanReader to use it if its there
though with stuff like RSS some folks might want to disable it to ensure
compliance with external DTDs or schemas etc. Ditto for ID generation etc.
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] Strategy for dealing with addXXX() methods
Posted by Jason van Zyl <jv...@zenplex.com>.
On Sun, 2002-03-10 at 20:26, James Strachan wrote:
> Hi Jason
>
> I think that approach sounds great. I'm sure we could plug in a few
> different Strategy patterns so that folks can customize the XMLIntrospector
> to suit their needs. e.g. some folks like to use mixedCaseNames for bean
> properties and <mixed-case-names> style XML elements.
>
> So go for it. BTW yes you're right, there's some duplicate code I introduced
> when implementing the loading of .betwixt files. I'm sure we can refactor
> that a bit cleaner to promote code reuse.
Ok, I will give this a first go tomorrow. I would like to dump my mapper
and I think we'll be using betwixt heavily in Tambora so I'll get on it.
Just wanted to double check the approach: I will attempt to make the
behaviour pluggable.
> James
> ----- Original Message -----
> From: "Jason van Zyl" <jv...@zenplex.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Sunday, March 10, 2002 5:17 PM
> Subject: [betwixt] Strategy for dealing with addXXX() methods
>
>
> > Hi James,
> >
> > I was just looking at a way for trying to deal with addXXX() methods in
> > a configurable way. I think I might have come up with a way to handle
> > it.
> >
> > While passing through the bean information in
> > XMLIntrospector.introspect() when discovering a loop type could we take
> > the name, say Hobbies, and apply a strategy to determine its singular
> > form? Then store that singular form for later use.
> >
> > So I could use a plural stemmer strategy that would turn Hobbies into
> > Hobby and then in the XMLIntrospectorHelper.defaultAddMethods() the
> > addHobby(Hobby hobby) would be matched up with Hobbies.
> >
> > We could maintain the current behaviour and possibly make these
> > strategies stackable so that different attempts can be made. This would
> > also allow things like i18n plural stemmers.
> >
> > I'm still trying to sort out some of the, it looks like there is some
> > duplicated code in the XMLIntrospector* classes but I'm not exactly sure
> > yet.
> >
> > But I think this method would work, I'll take any pointers. I think in a
> > few more hours I'll be able to give it a whirl if the approach is
> > acceptable.
> >
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > jvanzyl@apache.org
> >
> > http://tambora.zenplex.org
> >
> >
> > --
> > 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>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [betwixt] Strategy for dealing with addXXX() methods
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Jason
I think that approach sounds great. I'm sure we could plug in a few
different Strategy patterns so that folks can customize the XMLIntrospector
to suit their needs. e.g. some folks like to use mixedCaseNames for bean
properties and <mixed-case-names> style XML elements.
So go for it. BTW yes you're right, there's some duplicate code I introduced
when implementing the loading of .betwixt files. I'm sure we can refactor
that a bit cleaner to promote code reuse.
James
----- Original Message -----
From: "Jason van Zyl" <jv...@zenplex.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, March 10, 2002 5:17 PM
Subject: [betwixt] Strategy for dealing with addXXX() methods
> Hi James,
>
> I was just looking at a way for trying to deal with addXXX() methods in
> a configurable way. I think I might have come up with a way to handle
> it.
>
> While passing through the bean information in
> XMLIntrospector.introspect() when discovering a loop type could we take
> the name, say Hobbies, and apply a strategy to determine its singular
> form? Then store that singular form for later use.
>
> So I could use a plural stemmer strategy that would turn Hobbies into
> Hobby and then in the XMLIntrospectorHelper.defaultAddMethods() the
> addHobby(Hobby hobby) would be matched up with Hobbies.
>
> We could maintain the current behaviour and possibly make these
> strategies stackable so that different attempts can be made. This would
> also allow things like i18n plural stemmers.
>
> I'm still trying to sort out some of the, it looks like there is some
> duplicated code in the XMLIntrospector* classes but I'm not exactly sure
> yet.
>
> But I think this method would work, I'll take any pointers. I think in a
> few more hours I'll be able to give it a whirl if the approach is
> acceptable.
>
>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@apache.org
>
> http://tambora.zenplex.org
>
>
> --
> 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>
[betwixt] Strategy for dealing with addXXX() methods
Posted by Jason van Zyl <jv...@zenplex.com>.
Hi James,
I was just looking at a way for trying to deal with addXXX() methods in
a configurable way. I think I might have come up with a way to handle
it.
While passing through the bean information in
XMLIntrospector.introspect() when discovering a loop type could we take
the name, say Hobbies, and apply a strategy to determine its singular
form? Then store that singular form for later use.
So I could use a plural stemmer strategy that would turn Hobbies into
Hobby and then in the XMLIntrospectorHelper.defaultAddMethods() the
addHobby(Hobby hobby) would be matched up with Hobbies.
We could maintain the current behaviour and possibly make these
strategies stackable so that different attempts can be made. This would
also allow things like i18n plural stemmers.
I'm still trying to sort out some of the, it looks like there is some
duplicated code in the XMLIntrospector* classes but I'm not exactly sure
yet.
But I think this method would work, I'll take any pointers. I think in a
few more hours I'll be able to give it a whirl if the approach is
acceptable.
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>