Chalker, Dean wrote:
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.
Certainly this makes sense from the standard meaning of "default," and is what "default" means for attributes. Attributes and elements are treated differently by XML Schema, though. This takes many forms, but the important one here (I think) is that attributes are (by default) not required on valid instances. Elements, on the other hand, are required unless minOccurs="0". So I was trying to guess what the XML Schema spec meant by allowing the "default" attribute for element definitions. (I did not find the spec itself to be clear on this point. But then again, I didn't read the whole thing.)
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.
I can understand this desire, surely.
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.
I was wondering what actually _happens_. (And I didn't and don't have time to try it myself.) I thought this might shed some light on how castor treats this issue.
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.
Agree. It's odd that two questions have come up about this subject in the past week -- it makes me wonder if this behavior isn't a recent regression. I don't use default values much myself, so I'm not sure how long this issue might have been present.
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.
Agree. At the same time, I can see where high-load apps might object to calling an equals method at every field. This should be taken into consideration, perhaps by making the optimization optional.
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).
Agree again. I think that this could be done in the generated descriptor, specifically in the XMLFieldHandler for the default-value-having property. Another way would be to add an isDefaultValue flag for each of the properties with a default value. It would be updated whenever the set method is called. This would circumvent the load issue at the cost of greater code complexity in the actual data-bearing class.
Before such a change were made, we'd need (or, at least, I'd feel more comfortable if I had) an understanding of what default means for elements.
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.
Well, you've got my 2c, whether you wanted it or not. :-))
I think you've done a good job of laying out a course of action. It would be nice to get Keith and Arnaud's opinion on this, too. And it would be nice if someone volunteered to make the changes :).
Rhett
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
