Yes, that "works around" the problem, but I'm still trying to understand why
WOBrowser (and possibly other WOInputList-based components) can't handle the
contents of the list binding changing during takeValuesFromRequest.
I find it interesting that instead of fixing this problem or at least keeping
an exception from happening, The Apple developers chose to simply swallow the
exception and pretend nothing happened.
Dave
On Jan 26, 2012, at 12:41 AM, Ramsey Gurley wrote:
> I blame myself personally. I overrode that method to prevent swallowed
> exceptions but overlooked an obvious use case. It should probably be
>
> if(result instanceof NSMutableArray) {
> ((NSMutableArray)result).addObjects(selections.toArray());
> } else if(result instanceof NSArray) {
> result = new NSArray(selections);
> } else if(result instanceof List) {
> ((List)result).addAll(selections);
> }
>
> Same for radiobuttonlist and checkboxlist
>
> Ramsey
>
> On Jan 25, 2012, at 4:27 AM, Farrukh Ijaz wrote:
>
>> Hi David,
>>
>> From the exception it looks like you're trying to call addAll method on
>> NSArray which is not mutable. Since NSArray is an instance of List interface
>> therefore the check at line 532 returns true and therefore addAll get's
>> called at link 533 and that's actually raising exception.
>>
>> Fix: Make sure listClassInContext(context) method is returning mutable
>> object most likely NSMutableArray.
>>
>> Farrukh
>>
>> On 2012-01-25, at 1:21 PM, David Avendasora wrote:
>>
>>> Hey all,
>>>
>>> I'm in over my head again. But at least the "good" news is that I think I'm
>>> finally inching my way toward the deep end of the pool...
>>>
>>> We're suddenly running into the WOBrowser ": addAll is not a supported
>>> operation in com.webobjects.foundation.NSArray" problem as others have run
>>> into.
>>>
>>> We have a WOComponent that has three WOBrowsers on it. One selects one or
>>> more "Categories" from all possibilities. The other two manage what related
>>> objects are related to the selected Categories. One with Available Objects,
>>> and one with Assigned Objects. Basically, with 3 WOBrowsers we are managing
>>> a Many-to-Many relationship.
>>>
>>> Now, we can easily avoid the error by just making sure that the
>>> "selections" bindings of the WOBrowsers are not null. Initializing them
>>> with NSArray.emptyArray() works just fine.
>>>
>>> There are two odd things:
>>> 1) We just started running into this problem and this code has been running
>>> unchanged for years, and Wonder's last change was 16+ months ago
>>> 2) There are three WOBrowsers on the Page (2 in one component, 1 in a
>>> parent component) and only ONE of the WOBrowsers is causing this error.
>>>
>>> I believe there is a bug in WO's or WOnder's handling of WOBrowser, but
>>> maybe (probably) I'm just not fully understanding the implications of
>>> multiple WOBrowsers in one Page and the Request-Response loop.
>>>
>>> 526 if(_selections != null && _selections.isValueSettable()) {
>>> 526 try {
>>> 527 Class resultClass = listClassInContext(context);
>>> 528 Object result = resultClass.newInstance();
>>> 529 if(result instanceof NSMutableArray) {
>>> 530
>>> ((NSMutableArray)result).addObjects(selections.toArray());
>>> 531 } else {
>>> 532 if(result instanceof List) {
>>> 533 ((List)result).addAll(selections);
>>> 534 }
>>> 535 }
>>> 536 _selections.setValue(result, context.component());
>>> 537 } catch(Exception exception) {
>>>
>>> If I add the following two lines:
>>>
>>> 531 + } else if (result instanceof NSArray) {
>>> 532 + result = new NSArray(selections.toArray());
>>>
>>> Or surround lines 529 - 535 with the following if clause:
>>>
>>> 529 + if (selections != null && !selections.isEmpty()) {
>>> ...
>>> 537 + }
>>>
>>> Then everything works just fine, even if the selections bindings end up
>>> null.
>>>
>>> That's all very special, but it just covers up the real problem by
>>> intercepting the bad data before it can cause an error. They don't fix what
>>> is causing the bad data in the first place.
>>>
>>> It appears that for some reason line 527's call to
>>> EOAssociation#listClassInContext(context) for just ONE of the three
>>> WOBrowsers returns an instance of NSArray instead of an NSMutableArray.
>>> The one that gets an NSArray Class is the third WOBrowser on the page, but
>>> possibly more significantly it's the second with a null "selections"
>>> binding.
>>>
>>> What I don't get is why would EOAssociation#listClassInContext(context)
>>> return different Class objects (NSMutableArray for the first, NSArray for
>>> the second) even when both WOBrowser "selections" bindings are null?
>>>
>>> Does anybody have any ideas?
>>>
>>> (Clarification for Chuck: I mean ideas that don't directly or indirectly
>>> involve bourbon and/or hookers)
>>>
>>> Dave
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/farrukh.ijaz%40fuegodigitalmedia.com
>>>
>>> This email sent to [email protected]
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com
>>
>> This email sent to [email protected]
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
