Re: "protected" attributes in Component .java files.

From: David Avendasora (webobject..vendasora.com)
Date: Mon Jul 02 2007 - 20:19:48 EDT

  • Next message: Lachlan Deck: "Re: WOLips project using a custom framework"

    Well, if you fix it, please do it _after_ you write the new
    WOBuilder. ;)

    On Jul 2, 2007, at 5:53 PM, Mike Schrag wrote:

    > It's a wolips bug for a particular case that eclipse people don't
    > tend to run into, but wobuilder people do because wob generated
    > kind of crappy java. I was not planning on fixing it, but I think I
    > may just because it's only going to become more common as more
    > people make the jump.
    >
    > On Jul 2, 2007, at 6:22 PM, David Avendasora
    > <webobject..vendasora.com> wrote:
    >
    >> Oh, believe me, I don't want to change them to public, I'm just
    >> trying to figure out why Eclipse (WOLips?) is complaining about
    >> them being protected, when WOBuilder never did. I didn't know if
    >> there was some configuration within Eclipse/WoLips that would tell
    >> it that it was okay and not an error, or if I had somehow set it
    >> up incorrectly.
    >>
    >> But it sounds like what is being said is that to make it (the
    >> error flag) go away, you have to add public getters and setters,
    >> right? I know it's easy in Eclipse, just wondering if that's the
    >> right route.
    >>
    >> Dave
    >>
    >> On Jul 2, 2007, at 4:44 PM, Janine Sisk wrote:
    >>
    >>> On Jul 2, 2007, at 2:35 PM, David Avendasora wrote:
    >>>
    >>>> The problem I'm running into is that almost all the attributes that
    >>>> were setup in WOBuilder are "protected", and now Eclipse is
    >>>> reporting
    >>>> that the attributes don't exist. If I mark them as "public" then
    >>>> the
    >>>> problem goes away.
    >>>>
    >>>> What is the proper way to handle this?
    >>>
    >>> I'm feeling an urge to channel Chuck....
    >>>
    >>> He has taught me, forcefully :), that the right thing to do is to
    >>> leave these protected and write getter and setter methods for
    >>> them. Yes, it's kind of a pain. But he says that this protects
    >>> you in the future; if you end up actually needing to use an
    >>> accessor method then you can just modify the one that's already
    >>> there instead of trying to track down all the places you accessed
    >>> the variable directly. It's also better if you need to subclass
    >>> in the future, I imagine for the same reason.
    >>>
    >>> It's not quite as much work as it sounds; if your variable is
    >>> named foo, and your getter and setter are foo() and setFoo()
    >>> respectively, WO will find and use them automatically. So you
    >>> don't have to change your bindings.
    >>>
    >>> janine
    >>>
    >>>
    >>>
    >>
    >
    >
    >



    This archive was generated by hypermail 2.0.0 : Mon Jul 02 2007 - 20:20:34 EDT