Knut,
> Stefan,
>
> On 6/17/05, Liebig, Stefan <[EMAIL PROTECTED]> wrote:
> >
> > Your proposed ´default´ attribute would "conflict" with the already existing
> > possibilty to define defaults within the initializers of the translators.
> > So, this
> > would lead to two places defining defaults with slightly different
> > semantics!
> >
>
> On 6/17/05, Liebig, Stefan <[EMAIL PROTECTED]> wrote:
> >
> > Your proposed ´default´ attribute would "conflict" with the already existing
> > possibilty to define defaults within the initializers of the translators.
> > So, this
> > would lead to two places defining defaults with slightly different
> > semantics!
> >
Yes, the ´default´ attribute
could work, because the ´provider´ of the configuration point
is responsible for choosing
his ´default´-mechanism. The
existing translator implementations
should not care, if they do
not have a default within the initializer string.
With the ´default´ attribute
future translators wouldn´t need to take care about
defaults
anymore.
>
> Yes, the semantics would be slightly different and would "conflict" in
> so far that the default value could be specified in two locations.
>
> As you pointed out, however, the current semantics of a default value
> is "flawed" as the default value is only used if the attribute value
> is the empty string, or if the 'skip-if-null' attribute is used.
>
> > How about adding something like a ´skip-if-null´ to the <conversion>
> > element?
> > This could tell the underlying
> > <create-object>/<read-attribute> to use this vaule.
> > The default of this attribute would be ´true´, for compatibility.
> >
>
> I thought about that as well. But what about the attributes which
> don't specify a default value in the translator initializer? I think
> this could cause object properties to be set to null (i.e.
> setFoo(null)), which in turn could cause default values in the Java
> code to be overwritten...
> Yes, the semantics would be slightly different and would "conflict" in
> so far that the default value could be specified in two locations.
>
> As you pointed out, however, the current semantics of a default value
> is "flawed" as the default value is only used if the attribute value
> is the empty string, or if the 'skip-if-null' attribute is used.
>
> > How about adding something like a ´skip-if-null´ to the <conversion>
> > element?
> > This could tell the underlying
> > <create-object>/<read-attribute> to use this vaule.
> > The default of this attribute would be ´true´, for compatibility.
> >
>
> I thought about that as well. But what about the attributes which
> don't specify a default value in the translator initializer? I think
> this could cause object properties to be set to null (i.e.
> setFoo(null)), which in turn could cause default values in the Java
> code to be overwritten...
Yes, this is
true.
>
> IMHO it should be either left as is (adding a caveat notice to
> <conversion> would not hurt) or a 'default' attribute to <attribute>
> should be considered. What do others think?
> IMHO it should be either left as is (adding a caveat notice to
> <conversion> would not hurt) or a 'default' attribute to <attribute>
> should be considered. What do others think?
I would vote for the
´default´ attribute!
>
> --knut
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> --knut
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
Stefan
