Hi Dan,
comments inline...
Hi Adam,
I've been looking at this but still have problems with the nillable stuff,
but your example below breaks the semantics. You stated in your other
email:
We still need the 2 different properties in order to tell what is ALLOWED
to be Nillable (nullable) from what the user would LIKE to be Nillable
(nillable).
But in your snippet below, you're reversing those semantics.
setNullable(false) doesn't mean in that case that Date isn't allowed to be
Nillable, its just what the user would like. You follow?
No... you said that Date's cannot be set to Nil="true" (even though in Java
they can be set to NULL) because of a limitation of .net. So, I said that to
make sure that we never output Nil="true" for Date you can set Nullable to
true as below. So, the setNullable(true) is because Date's are not allowed
to be Nilled, it has nothing to do with the user's wishes.
So... to reduce confusion we should probably change the nullable property of
Type.java to be called nillableAllowed.
Do you want me to do the refactoring and upload a new set of patches?
The real issue here is how do we know that a user hasn't overridden the
nillable property on the type. For instance, say I create some custom type
which I want to be nillable but set the nillable default to false. The
patch will overwrite that property since there is no way to override it.
Or the other way around - I set a specific type's nillability to false but
set the global default to true. Once again it gets overridden.
I'm not sure there is a simple solution for this, but I'm up for ideas...
You are right, if a user creates a new type, there is no way for them to set
the default value for Nillable to anything other than the System wide
default for Nillable. I also don't see an easy way around this, but I also
don't see it as a huge problem in the real world. Surely, the presents of a
global default for Nillable is better than the not having it?
As I see it, in the real world the users probably sit in 2 camps:
1) Not bothered about highly constrained interfaces. In which case they set
the global default for Nillable and MinOccurs to true and 0 respectfully and
maybe use the per property overrides to add mandatory elements to their
interface definition.
2) Highly constrained Interfaces are important. In which case they set
global defaults for Nillable and MinOccurs to false and 1 respectfully and
then use per property overrides to declare optional elements.
In either case, if they add their own user types, they probably will not
deviate from case 1) or 2) and therefore the fact that they cannot set a
default for their new Type that is different from the global default is
neither here nor there.
Adam.
- Dan
Adam Chesney wrote:
Hi Dan,
Any idea when you will get a chance to integrate my updated patches?
http://jira.codehaus.org/browse/XFIRE-295?page=all
Then add:
public DateType()
{
setNullable(false);
}
to DateType.java
Cheers,
Adam.
----- Original Message ----- From: "Adam Chesney" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, March 16, 2006 4:21 PM
Subject: Re: [xfire-dev] [jira] Updated: (XFIRE-295) optionally add
xs:any & xs:anyAttribute to complex types produced by Aegis WSDL builder
Hi Dan,
Ok well if dates can never be nillable then just override:
public booean isNullable()
{
return false;
}
in DateType.java, or alternatively call:
public DateType()
{
setNullable(false);
}
in the constructor.
This will mean that it will never come out as Nillable="true" even if
the default for Nillable is true. Which it is.
Repeat for any other types that cannot be Nilled.
We still need the 2 different properties in order to tell what is
ALLOWED to be Nillable (nullable) from what the user would LIKE to be
Nillable (nillable).
Cheers,
Adam.
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
