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