Hi Rhett, Thanks for the response. My comments below.
> -----Original Message----- > From: Rhett Sutphin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 1 July 2003 10:50 PM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] SourceGenerator: handling of default values > > > Hi Dean, > > On Tuesday, July 1, 2003, at 01:49 AM, Chalker, Dean wrote: > > I'm a bit confused about how default values are > handled/implemented by > > the SourceGenerator. > > � > > Using Castor 0.9.5 with�a schema fragment like this: > > � > > <complexType name="routeSpecification"> > > ��� <sequence> > > ������� <element name="network" type="string"></element> > > ������� <element name="journeyType" type="string" > > default="closestOnly"></element> > > ������� <element name="returnToStart" type="boolean" > > default="false"></element> > > ��� </sequence> > > </complexType> > > � > > I get a code fragment like this�(less comments): > > � > > ��� private java.lang.String _network; > > ��� private java.lang.String _journeyType = "closestOnly"; > > ��� private boolean _returnToStart = false; > > ��� private boolean _has_returnToStart; > > � > > ��� public RouteSpecification() { > > ������� super(); > > ������� setJourneyType("closestOnly"); > > ��� } //-- com.intelliwhere.business.core.RouteSpecification() > > � > > _journeyType is initialised twice, while _returnToStart is > only half > > initialised since the associated "has" flag is not also > set to true. > > The double initialization of journeyType is probably a bug. I'll log this in bugzilla > (My > personal preference would be to retain the setJourneyType in the > constructor and drop the field initialization.) I'd vote for this too. > > You make a good point on the "default" attribute as it relates to > elements. Yesterday I responded to Tom Talbott about > default and 'has' > as it relates to attributes. ( > http://www.mail-archive.com/[EMAIL PROTECTED]/msg14060.ht > ml ) On > attributes, default is reasonable, since attributes aren't > automatically required. Elements are automatically required, so I'm > not sure what the semantics of 'default' on an element are > supposed to > be. Does it mean > > <journeyType/> > > is equivalent to > > <journeyType>closestOnly</journeyType> ? > > Or is it supposed to mean that you can omit the journeyType > element and > a schema-aware parser should treat it as though > <journeyType>closestOnly</journeyType> is there? I could be being naive, but I think it means that any instance of RouteSpecification I create, whether through a constructor or threw unmarshalling, should have journeyType="closestOnly" and retirnToStart=false unless the defaults are explicitly overridden. To me, this means I should be able to omit the journeyType element in my XML altogether. >From an application perspective, (I think) this makes sense. For something like SOAP where the XML is coming from somewhere external, the XML for basic usage of my interface need not provide the defaulted elements, which means the resultant XML is much smaller and easy to understand. For my example, I only need provide <routeSpecification> <network>myNetwork</network> </routeSpecification> rather than having the XML "cluttered" with lots of default values. > > What happens when you marshal a completely new instance of > RouteSpecification? As before, if I create an instance of RouteSpecification with a constructor, then I would expect the default values applied unless they are overridden with calls to the releveant setter. > > Anyway, the fact that source generator leaves 'has' properties false > even on default-initialized fields is intentional, I think. > See below. > > > Looking at the Castor code, I see an if() statement at the > start of > > FieldInfo.generateInitializerCode(), and I don't understand why > > primitives are excluded.� Seems to me you could remove the > if() from > > this method and the field.setInitString(_default) statement from > > FieldInfo.createJavaField()? > > � > > Am I missing something? > > Well, I think the no-setter-for-primitives feature is > because calling > the setter would set the 'has' property to true. Source generator > wants that only to be true if some calling code explicitly sets the > value. The idea is that this will prevent default attributes from > being marshaled so long has they stay at their default values. > I find the functional difference between primitives and non-primities non-intuitive. Defaulting journeyType="closestOnly" sets virtual "has" flag to true since the reference is non-null, yet defaulting returnToStart="false" does not set its "has" flag. If you wish to optimized the marshalled XML, then I'd suggest you need another approach. When marshalling, you need to test the value of an element against the default value to determine whether you want to explicitly marshal the field. I think the "has" flag shoul dbe used to indicate that the element has a value at all, rather than it has the default value. A direct comparison agains the default value also supports the case where the application explicitly sets the value to the same as the default. This would make the application easier to write because it would not have to worry about whether a value was the default value or not (most of the time). > Of course, this doesn't work for non-primitive types. And it's > probably inadvisable for element defaults. And it causes > troublesome > incompatibilities with JDO, as Tom Talbott discovered. Perhaps this > feature should be reconsidered. > > Rhett Well, you've got my 2c, whether you wanted it or not. :-)) Regards & thanks Dean > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > -----Original Message----- > From: Chalker, Dean > Sent: Wednesday, 2 July 2003 10:27 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [castor-dev] SourceGenerator: handling of default values > > > > Hi Rhett, > > Thanks for the response. My comments below. > > > > -----Original Message----- > > From: Rhett Sutphin [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, 1 July 2003 10:50 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [castor-dev] SourceGenerator: handling of > default values > > > > > > Hi Dean, > > > > On Tuesday, July 1, 2003, at 01:49 AM, Chalker, Dean wrote: > > > I'm a bit confused about how default values are > > handled/implemented by > > > the SourceGenerator. > > > � > > > Using Castor 0.9.5 with�a schema fragment like this: > > > � > > > <complexType name="routeSpecification"> > > > ��� <sequence> > > > ������� <element name="network" type="string"></element> > > > ������� <element name="journeyType" type="string" > > > default="closestOnly"></element> > > > ������� <element name="returnToStart" type="boolean" > > > default="false"></element> > > > ��� </sequence> > > > </complexType> > > > � > > > I get a code fragment like this�(less comments): > > > � > > > ��� private java.lang.String _network; > > > ��� private java.lang.String _journeyType = "closestOnly"; > > > ��� private boolean _returnToStart = false; > > > ��� private boolean _has_returnToStart; > > > � > > > ��� public RouteSpecification() { > > > ������� super(); > > > ������� setJourneyType("closestOnly"); > > > ��� } //-- com.intelliwhere.business.core.RouteSpecification() > > > � > > > _journeyType is initialised twice, while _returnToStart is > > only half > > > initialised since the associated "has" flag is not also > > set to true. > > > > The double initialization of journeyType is probably a bug. > > I'll log this in bugzilla > > > > (My > > personal preference would be to retain the setJourneyType in the > > constructor and drop the field initialization.) > > I'd vote for this too. > > > > > > You make a good point on the "default" attribute as it relates to > > elements. Yesterday I responded to Tom Talbott about > > default and 'has' > > as it relates to attributes. ( > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg14060.ht > > ml ) On > > attributes, default is reasonable, since attributes aren't > > automatically required. Elements are automatically > required, so I'm > > not sure what the semantics of 'default' on an element are > > supposed to > > be. Does it mean > > > > <journeyType/> > > > > is equivalent to > > > > <journeyType>closestOnly</journeyType> ? > > > > Or is it supposed to mean that you can omit the journeyType > > element and > > a schema-aware parser should treat it as though > > <journeyType>closestOnly</journeyType> is there? > > I could be being naive, but I think it means that any > instance of RouteSpecification I create, whether through a > constructor or threw unmarshalling, should have > journeyType="closestOnly" and retirnToStart=false unless the > defaults are explicitly overridden. To me, this means I > should be able to omit the journeyType element in my XML altogether. > > From an application perspective, (I think) this makes sense. > For something like SOAP where the XML is coming from > somewhere external, the XML for basic usage of my interface > need not provide the defaulted elements, which means the > resultant XML is much smaller and easy to understand. For > my example, I only need provide > > <routeSpecification> > <network>myNetwork</network> > </routeSpecification> > > rather than having the XML "cluttered" with lots of default values. > > > > > > What happens when you marshal a completely new instance of > > RouteSpecification? > > As before, if I create an instance of RouteSpecification > with a constructor, then I would expect the default values > applied unless they are overridden with calls to the > releveant setter. > > > > > Anyway, the fact that source generator leaves 'has' > properties false > > even on default-initialized fields is intentional, I think. > > See below. > > > > > Looking at the Castor code, I see an if() statement at the > > start of > > > FieldInfo.generateInitializerCode(), and I don't understand why > > > primitives are excluded.� Seems to me you could remove the > > if() from > > > this method and the field.setInitString(_default) > statement from > > > FieldInfo.createJavaField()? > > > � > > > Am I missing something? > > > > Well, I think the no-setter-for-primitives feature is > > because calling > > the setter would set the 'has' property to true. Source > generator > > wants that only to be true if some calling code > explicitly sets the > > value. The idea is that this will prevent default > attributes from > > being marshaled so long has they stay at their default values. > > > > I find the functional difference between primitives and > non-primities non-intuitive. > > Defaulting journeyType="closestOnly" sets virtual "has" flag > to true since the reference is non-null, yet defaulting > returnToStart="false" does not set its "has" flag. > > If you wish to optimized the marshalled XML, then I'd > suggest you need another approach. When marshalling, you > need to test the value of an element against the default > value to determine whether you want to explicitly marshal > the field. I think the "has" flag shoul dbe used to > indicate that the element has a value at all, rather than it > has the default value. > > A direct comparison agains the default value also supports > the case where the application explicitly sets the value to > the same as the default. This would make the application > easier to write because it would not have to worry about > whether a value was the default value or not (most of the time). > > > > > Of course, this doesn't work for non-primitive types. And it's > > probably inadvisable for element defaults. And it causes > > troublesome > > incompatibilities with JDO, as Tom Talbott discovered. > Perhaps this > > feature should be reconsidered. > > > > Rhett > > Well, you've got my 2c, whether you wanted it or not. > > > Regards & thanks > Dean > > > > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send mail to > > [EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
