[dev] [cvs] commit: whups/lib Driver.php

[Jan Schneider]

Zitat von Michael Rubinsky <mike at theupstairsroom.com>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael Rubinsky <mike at theupstairsroom.com>:
>>
>>> Quoting Jan Schneider <jan at horde.org>:
>>>
>>>> Zitat von Michael Rubinsky <mike at theupstairsroom.com>:
>>>>
>>>>> mrubinsk    2007-11-27 13:12:22 EST
>>>>>
>>>>> Modified files:
>>>>>   lib                  Driver.php
>>>>> Log:
>>>>> Revert this (sort of) - still call the api to allow other apps to provide
>>>>> the ticket queue, but change the assumption about the data type returned
>>>>> to be in line with our current api code.
>>>>>
>>>>> Jan - does this make sense, or should we assume another data structure?
>>>>
>>>> Yes, but getQueuesInternal() (called through tickets/listQueues)
>>>> already *does* put the queued ids into the keys, using DB::getAssoc().
>>>
>>>
>>> The problem, though is that when this is called through rpc.php the
>>> data that is returned is just an array of the queue names - the
>>> original numeric keys are lost, and the array is re-indexed.
>>> Currently, if you call list() and listQueues() both through our rpc
>>> server, you get back the same results.  The proper data *is*
>>> returned  when called via $registry->call() though.
>>
>> But how does this change anything? You're simply rebuilding the same
>> hash again, why using xmlrpc not replacing the keys now?
>
> The hash I'm rebuilding is the hash that's returned from the api  
> call.  The api call now returns the data in the form:
>
> array[0] = array('id' => 1,
>                  'name' => 'some name');
>
> array[1] = array('id' => 2,
>                  'name' => 'some other name');
>
> instead of:
>
> array([1] => 'some name',
>       [2] => 'some other name'):
>
>
> The api call attempting to return the data in the second form was  
> what  was causing the problem. Changing *only* the api call to  
> return the  data in the first form "fixed" the issue...but required  
> changing the  logic in Driver.php to account for the change in  
> return data structure.
>
>
>> And why don't you use json or soap if xmlrpc is causing these
>> problems? Assuming you do use xmlrpc.
>
> To be honest, I'm using xmlrpc because that's what I have the most   
> experience with.

To sum up follow-up discussion on IRC for the records: the xmlrpc  
extension is automatically converting associative arrays to arrays  
instead of structs, if all keys are numeric. Even casting the keys to  
strings doesn't help.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/