I committed my version of your patch to SVN. Let me know your thoughts
when you get a chance. I'm not tied to my code by any means. :-)
- Dan
Dan Diephouse wrote:
Adam Chesney wrote:
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.
Technically this is a user preference those. Dates can be nilled, we
just don't want to allow that by default if that makes more sense :-)
So they're allowed, its just bad for interop.
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?
Nah, I have some other changes which I've integrated into your patch.
Specifically I created a Configuration object to pass around settings
(I need it for some other stuff later). Also, I removed the minOccurs
from Type because minOccurs can only be set on properties of a bean.
On a related note, the patch is good and I appreciate it! I hope the
debate isn't giving the wrong impression :-). I think more than
anything I'm running into flaws in my design.
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.
Heres what I think might be a good solution:
- Only do setNillable(isDefaultNillable()) if we are creating a new
type (yours was overriding old types):
if (newType && !getTypeConfiguration().isDefaultNillable())
result.setNillable(false);
- Make sure that the default type mapping that is created in
DefaultTypeMappingRegistry respects
protected void register(TypeMapping tm, Class class1, QName name,
Type type)
{
if (!getTypeConfiguration().isDefaultNillable())
{
type.setNillable(false);
}
tm.register(class1, name, type);
}
This way we're only overriding the nillable property if we explicitly
want them all the be false. Which I think is the best way to do
things. Either you're going to want a mix of true/false or have them
all false by default. You'll never want to have them all true by default.
I wrote an additional test or two and everything seems to check out
functionality wise.
Would that work for you?
- Dan
- 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
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
