> So if I setup a class with this scenario (protected field, get/set
> methods), the binding that is offered during completion by default
> is "user".
This is with existing components and bindings. The builder is marking
it as an error. I haven't been able to get the completion popup to
work. Does it work in the mpe?
> If you start to type get, "getUser" will be offered instead.
> However, because the field is protected, I'm not actually
> completing off the field, when you see "user" in the list of
> completions, it's actually completing against the getUser() method
> and stripping the get off (and lowercasing it).
> Do WO allow you to bind to a protected field directly?
Yes. But if you don't have a public accessor, then it will throw an
exception at runtime saying it couldn't find a method getUser
_getUser or a instance variable _getUser, as it is looking for a
public accessor/ivar. When using WOBuilder, when you create a new
ivar, it has the option to create a set/get accessor, if you select
them it will make the ivar protected and create public accessors.
> Should I make it only hide private fields/methods?
I think that would be the best approach as people who are migrating
over from WOBuilder will wonder why it is occuring.
Greg
>
> On Sep 14, 2005, at 8:15 PM, Greg wrote:
>
>
>> No, it is protected.
>>
>> eg
>>
>> protected String user;
>>
>> public String getUser() { return user; }
>> public void setUser(String newUser) { user = newUser; }
>>
>> That is basically how WOBuilder does it.
>>
>> On 15/09/2005, at 10:02 AM, Mike Schrag wrote:
>>
>>
>>
>>> It should be looking at fields also -- Only public ones, though.
>>> So you have a public instance field named "user" that's not being
>>> found?
>>>
>>> On Sep 12, 2005, at 8:55 PM, Greg wrote:
>>>
>>>
>>>
>>>
>>>> One thing I have noticed with this is that you are only using
>>>> the gettter/setter's to see if a binding is correct. It would be
>>>> good if you also used the classes instance variables. Since
>>>> coming from Xcode and WOBuilder, the binding created was never
>>>> to getUser, but rather user since KVC would handle getting the
>>>> accessor for user.
>>>>
>>>> Greg
>>>>
>>>> On 12/09/2005, at 9:57 PM, Mike Schrag wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I thought I had posted already, but I can't find the post --
>>>>> too much programming over the weekend I think :)
>>>>>
>>>>> Several people have emailed me asking for this -- support for
>>>>> WOD binding-name completion based on the API file is in (for
>>>>> project, framework, and core components) ... Completely
>>>>> standing on Ulrich's shoulders with his API parser :) . There
>>>>> are also a bunch of new error checks in the WOD file: check for
>>>>> element names defined in HTML but no in WOD, check for element
>>>>> names defined in WOD but not in HTML, check for duplicate
>>>>> definition of element names in WOD, check for duplicate
>>>>> definition of binding names, check for existence of type names
>>>>> + that it is instanceof WOElement, and the usual check for
>>>>> proper syntax.
>>>>>
>>>>> I don't do API binding validation yet. I can't recall if I
>>>>> asked this before, but if you have an API file that defines
>>>>> bindings, can you ONLY bind to something defined in the API
>>>>> file or is it the usual get/set methods PLUS the bindings
>>>>> defined in the API file?
>>>>>
>>>>> And I'm still working the kinks out of the error checking --
>>>>> occasionally I manage to get it to freak out a little (I think
>>>>> there a certain case where the parser gets greedy and one of
>>>>> the rules gobbles up an extra character at the end, which
>>>>> throws everything off), but I haven't nailed down the actual
>>>>> repeatable scenario that causes it. If you happen to see it
>>>>> and can figure out what causes a repeatable case, let me know.
>>>>>
>>>>> WOD error checking still is not hooked up to a builder, so you
>>>>> only see errors for files that you have opened. Incidentally,
>>>>> would people LIKE it to be a builder? The downside is obviously
>>>>> that the time to do a build increases. Going forward, any new
>>>>> file you make will have the incremental error checking, so this
>>>>> is really only an issue for finding errors in existing projects.
>>>>>
>>>>> ms
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
This archive was generated by hypermail 2.0.0 : Wed Sep 14 2005 - 20:36:19 EDT