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:16:12 EDT