Re: api support

From: Mike Schrag (mschra..dimension.com)
Date: Wed Sep 14 2005 - 20:21:04 EDT

  • Next message: Greg: "Re: api support"

    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". 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? Should I make it only hide
    private fields/methods?

    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:21:10 EDT