Hi Dimuthu,
Actually, the enumeration is defined as follows:
<simpleType name="DayOfWeek" >
<restriction base="xsd:string">
<enumeration value="Monday"/>
<enumeration value="Tuesday"/>
<enumeration value="Wednesday"/>
<enumeration value="Thursday"/>
<enumeration value="Friday"/>
<enumeration value="Saturday"/>
<enumeration value="Sunday"/>
</restriction>
</simpleType>
Note the string base for the restriction. I guess it's what makes
sense and it is indeed consistent with what I've seen in other places,
since if you're defining string values, you'd expect the restriction
to be for them to be strings.
This generates the following intermediate XML, however:
<?xml version="1.0" encoding="UTF-8"?>
<class caps-name="DAYOFWEEK" name="DayOfWeek" nsprefix="ns1"
nsuri="https://adwords.google.com/api/adwords/v11";
originalName="DayOfWeek" simple="yes" unwrapped="yes">
<property caps-cname="DAYOFWEEK" caps-type="AXIS2_CHAR_T*"
cname="DayOfWeek" minOccurs="1" name="DayOfWeek" notattribute="yes"
nsuri="https://adwords.google.com/api/adwords/v11";
originalName="DayOfWeek" prefix="" restrictionBaseType="yes"
shorttypename="string" simple="yes" type="axis2_char_t*">
<enumFacet id="Monday" value="Monday"/>
<enumFacet id="Tuesday" value="Tuesday"/>
<enumFacet id="Wednesday" value="Wednesday"/>
<enumFacet id="Thursday" value="Thursday"/>
<enumFacet id="Friday" value="Friday"/>
<enumFacet id="Saturday" value="Saturday"/>
<enumFacet id="Sunday" value="Sunday"/>
</property>
</class>
As you see, all the types are string-oriented here, which will affect
the code for the whole class, causing it to store the property as a
string:
struct adb_DayOfWeek
{
axutil_qname_t* qname;
axis2_char_t* property_DayOfWeek;
axis2_bool_t is_valid_DayOfWeek;
};
So in order to make enumerations store their properties as ints, I
guess I'd have to somehow smartly detect enumerations and handle them
as a special case in the intermediate XML generation code, or
otherwise fill the entire stylesheet with checks. The only other
option is to store the property as a string and do the string <-> int
conversion I had mentioned in my previous post (either via specialized
extra getters/setters for enums, or by recognizing an enum and
changing the code for its default setters/getters).
I'm leaning towards the latter option (with modified default
getters/setters), but would be willing to do the former if you think
it makes more sense.
Cheers,
Sérgio
---
On Thu, Apr 24, 2008 at 3:17 AM, Dimuthu Gamage <[EMAIL PROTECTED]> wrote:
> Hi Sérgio,
>
> See my inline comments.
>
>
> On Wed, Apr 23, 2008 at 7:23 PM, Sérgio Gomes <[EMAIL PROTECTED]> wrote:
> > Hi Dimuthu,
> >
> > I'm developing the patch right now (I'm now able to generate the enum
> > declaration) and I found that I have two options to proceed:
> >
> > 1 - Add specialized getters/setters for enumerations, while keeping
> > the base type as a string. They would be named something like
> > adb_<property>_get_<property>_enum and
> > adb_<property>_set_<property>_enum. I'd have to do the conversion
> > between the C enum struct and the stored string within the function
> > (basically with a big if/else chain). This solution would preserve
> > backwards compatibility and wouldn't require any changes to the java
> > code, just XSL changes.
> >
> > 2 - Completely change support for enumerations, by storing them as int
> > and changing the setters/getters to use the C enum structure instead.
> > This would break backwards compatibility and require java writer
> > changes (not exactly sure which files), but would be much more elegant
> > in terms of generated C code.
>
> I think I prefer this approach. Although this break the backward
> compatibility, this is the most elegant way to do it in C.
> And in fact this too doesn't require to change any of the java code,
> you will be able to handle it in xslt itself. That is the java writer
> will give us an intermediate xml which is something like this for that
> adb object corresponding to the a type like this.
>
> <xs:simpleType name="derivedType">
> <xs:restriction base="xs:int">
> <xs:enumeration value="test1"/>
> <xs:enumeration value="test2"/>
> </xs:restriction>
> </xs:simpleType>
>
> <class caps-name="DERIVEDTYPE" name="derivedType" nsprefix="ns1"
> nsuri="http://wso2.org/dyn/codegen/demo"; originalName="derivedType"
> simple="yes" unwrapped="yes">
> <property caps-cname="DERIVEDTYPE" caps-type="INT"
> cname="derivedType" minOccurs="1" name="derivedType"
> notattribute="yes" nsuri="http://wso2.org/dyn/codegen/demo";
> originalName="derivedType" prefix="" p
> rimitive="yes" restrictionBaseType="yes" shorttypename="int"
> simple="yes" type="int">
> <enumFacet id="test1" value="test1"/><enumFacet id="test2"
> value="test2"/>
> </property>
> </class>
>
> There you can check whether the enumFacet element exists and if so
> change the method signature and the logic of the getters/setters
> itself from the xslt itself.
>
>
> Thanks
> Dimuthu
>
>
>
>
>
>
> >
> > Have you got any thoughts on this?
> >
> > Cheers,
> > Sérgio
> >
> > PS - I switched to my work email, that will make things easier for me.
> >
> > ---
> > On Sun, Apr 13, 2008 at 1:05 PM, Sérgio Gomes <[EMAIL PROTECTED]> wrote:
> > > Hi Dimuthu,
> > >
> > > Thanks for getting back to me. I'll give that patch a try next week,
> > > I'll let you know.
> > >
> > > Cheers,
> > > Sérgio
> > >
> > > ---
> > >
> > >
> > > On Fri, Apr 11, 2008 at 9:21 PM, Dimuthu Gamage <[EMAIL PROTECTED]>
> wrote:
> > > > Hi Sérgio,
> > > >
> > > > Yea, you are correct on this. We should be able to declare them in
> an
> > > > enum to provide interger constants in the API. It should be trivial.
> > > > Why not you try that and propose a patch?
> > > >
> > > > If you like to try you have to checkout the axis2/java source code
> > > > from https://svn.apache.org/repos/asf/webservices/axis2/trunk/java
> > > >
> > > > and you may need to edit following files
> > > > c adb templates from
> > > > modules/adb-codegen/src/org/apache/axis2/schema/template/ in the
> > > > source tree
> > > > c adb writer class from
> > > >
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CStructWriter.java
> > > > in the source tree
> > > >
> > > > Thanks
> > > > Dimuthu
> > > >
> > > >
> > > >
> > > > On Wed, Apr 9, 2008 at 8:23 PM, Sérgio Gomes <[EMAIL PROTECTED]>
> wrote:
> > > > > Hi there,
> > > > >
> > > > > Yet another possible code generator issue. There's an
> enumeration in
> > > > > the WSDL I'm using:
> > > > >
> > > > > <simpleType name="DayOfWeek" >
> > > > > <restriction base="xsd:string">
> > > > > <enumeration value="Monday"/>
> > > > > <enumeration value="Tuesday"/>
> > > > > <enumeration value="Wednesday"/>
> > > > > <enumeration value="Thursday"/>
> > > > > <enumeration value="Friday"/>
> > > > > <enumeration value="Saturday"/>
> > > > > <enumeration value="Sunday"/>
> > > > > </restriction>
> > > > > </simpleType>
> > > > >
> > > > > And the setter that gets generated for it is:
> > > > >
> > > > > axis2_status_t AXIS2_CALL
> > > > > adb_DayOfWeek_set_DayOfWeek(
> > > > > adb_DayOfWeek_t* _DayOfWeek,
> > > > > const axutil_env_t *env,
> > > > > const axis2_char_t* arg_DayOfWeek);
> > > > >
> > > > > The setter is referencing a structure of the same type, so how
> can I
> > > > > create, say, a "Monday" object? Shouldn't the setter be receiving
> > > > > something like an integer instead, which you could get from a C
> enum
> > > > > with the several options?
> > > > >
> > > > > Cheers,
> > > > > Sérgio
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
