commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [betwixt] couple of questions
Date Wed, 19 Jan 2005 20:58:27 GMT
hi jason

On 19 Jan 2005, at 15:41, Jason Wood wrote:

> 1) is there a document describing the different attributes each 
> element in a
> configuration file an contain?

if you mean by configuration file: a dot betwixt file there's a DTD in 
CVS but doesn't seem to be anywhere on the website.

> 2) has to do with List.

collective properties have a getter and an adder. collectives without 
adders are read-only. the mapping of read-only collectives differs from 
those that can also be read. you've discovered an example of the 
difference.

> When using a configuration if the <addDefaults/> element is not 
> present then
> all properties must be explicitly listed.  For a List property to show 
> up in
> the XML output, it as all the rest must be explicitly listed ... 
> <element
> name="MyAttributes" property="attributes"/>. This is fine, but 
> "MyAttribute"
> will show up for every entry in the java.util.List...

<snip>

> <MyOutterClass>
>   <MyAttributes/>
>   <MyAttributes/>
> </MyOutterClass>

this is the behaviour i would expect by default.

> I tried to remove the name="MyAttribtue" because I want betwixt to use 
> each
> entries (DerivedClassA and DerivedClassA) .betwixt file.

i'd be surprised if the above approach can be made to work. one issue 
is that betwixt needs to be told that you want to use the dynamic bind 
type (the type of the instance) rather than the introspection time type 
(the logical type derived from the type of the property).

> I thought I could use the PluralStemmer in this case, but there is not
> enough information being passed to findPluralDescriptor( String
> propertyName, Map map ) in order for the code to choose the right
> ElementDescriptor.

PluralStemmer is a little shackled by backwards compatibility but the 
intention has always been to provide support elsewhere. take a look at 
http://jakarta.apache.org/commons/betwixt/guide/derived.html but you'll 
need the latest code from CVS HEAD to take advantage.

> Is it possible that if the name attribute is not present
> to tell betwixt to use the given name in the classes .betwixt file for
> output?

that sounds like a pretty reasonable change. not sure it's on my list 
of itches just now so i'm sure when i'd get round to coding it...

> If it is possible and not already in the current CVS src ...
> can I checkout the source and add it.

i would very strongly suggest checking out the latest source from CVS 
in any case: you'll need to roll your own betwixt version to take 
advantage of the improved support for derived beans and mixed 
collectives.

i would also strongly encourage you to play around with the source. 
betwixt is open source: you're free to change the source and use it in 
whatever way you'd like (providing that you abide by the small number 
of conditions in the ASL2.0). if your changes work for you then that's 
fine.

on the other hand, betwixt development is ongoing and it's likely that 
a private betwixt fork will become difficult to maintain as the apache 
version is pushed forward. it therefore makes sense to share your 
changes by donating them to apache by contributing a patch. patches are 
more likely to be committed if they come with documentation patches and 
unit test and are compact. please attach patches to a bug report (the 
list will strip them out) but you might want to follow up on list.

if you do want to contribute a patch to the ASF to add functionality 
allowing the element name to be derived at runtime together with unit 
tests and documentation, there's a very good chance that i'll review 
it. if you run into problems with the implementation but contribute 
unit tests and documentation then that would definitely increase the 
changes of me coding a solution.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message