...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.
Okay, yep that makes more sense!
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.
Cool, a Config objects sounds much better! :)
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.
Well... if it's any consolation... I think it's pretty impossible to think
of everything up front which is why an evolving design is fine... the real
test in your design is how easy it is to make changes to without having to
refactor large bits of it!
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?
Sounds fine to me. As long as I can make the default behavior for my system
to always spit out <xs:any/> tags and never spit out Nillable="true" or
minOccurs="0" unless I specifically say to do so on a individual property
level then I don't mind! ;)
I'll revert to the stuff in SVN and have a play with it.
Thanks a lot!
Adam.
- 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
