Hi Bill,
Interesting, so they create an enumeration with the possible
element names? I'm assuming it's element names because if it was actual
types that wouldn't help out in the case where two elements with
different names but the same type.
As far as adding all the getters/setters. I actually like them since
this eliminates the need for casting, though I do realize they can be
cumbersome at times without the getValue() method, which I definately
think we need to add.
--Keith
Bill Keese wrote:
> Hello Keith,
>
> I wanted to add my opinion on enhancing <choice> code generation.
>
>
>>...you need to have an if-then-else statement to check which value of
>>the choice has been set:
>>
>>Castor could/should provide a more simple way of retrieving the value,
>>such as public Object getChoiceValue(); or something like that.
>
>
>
> I agree. I expected that the java class for a choice type would ONLY
> have a getValue() function, and maybe a getValueType() function. By the
> way, the latter function is only necessary when the choice contains
> multiple elements of the same type AND
> org.exolab.castor.builder.javaclassmapping=type (in
> castorbuilder.properties).
>
> .NET essentially creates a getValue() and getValueType() function.
> Here's the output for a list of nouns, where a thing is a person, place,
> or thing
>
> Public Class NounList
> Public Items() As Object
> Public ItemsElementName() As ItemsChoiceType
> End Class
>
> Public Enum ItemsChoiceType
> person,
> place,
> thing
> End Enum
>
>
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-user
>
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-user
