>> You can see it if you declare two WOSession subclasses in your
>> reachable package tree for the project -- it has no idea which one
>> it should use, so you get combined results, which means validation
>> can lie in this.
>
> I have this situation as well, although all WOSession subclasses
> are named "Session", but in different Java packages. Might this be
> tricking the binding validator?
In the same application? The way this works is that in any particular
class, it builds a subclass hierarchy of the base class that spans
your current project as well as the projects it depends on (down ONLY,
not UP) and merges the resulting methods together as possible
candidates. So within a single application project, when you bind to
"session.something" in your component, it will see the session()
method returns a WOSession type and find all subtypes of WOSession
within that application and its dependencies, which GENERALLY is only
one. If you have two Session subclasses _in a single application_
then it is going to be confused and show you all of the bindings as
possible matches. I mentioned before this is "upside down" from how
most validation works (including Java's type system). Most bindings
only allow the declared type and its supertypes. WOSession and
WOApplication are special-cased to give generally more useful results.
>> There are tons of configuration tweaks, though, so you can tweak
>> quite a bit of this behavior.
>
> I haven't found a binding validation preference that would allow
> these sorts of unsafe key paths to generate warnings rather than
> errors. Am I missing something?
There is no setting for exactly what you're looking for. The closest
thing is that you can turn off errors on "implements NSKeyValueCoding"
which will allow you to bind to anything you want on any KVC class
without errors. This GREATLY decreases the effectiveness of
validation, though, because almost everything in WO implements NSKVC.
My personal recommendation would be to fix your type declarations so
they are type-safe based on the rules of Java. // VALID should, by
far, be the exception.
ms
This archive was generated by hypermail 2.0.0 : Fri Mar 14 2008 - 18:48:13 EDT