[dev] [commits] Horde branch master updated. 76ede0ec67c40022f5d5eb74f0d2a0897f1ba7c6

Michael Rubinsky mrubinsk at horde.org
Tue Mar 22 05:58:48 UTC 2011


Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>
>> For the record, now that I have some time to explain, the references
>> are needed because this is a FB "batch" request. The api calls in
>> this section are not sent to FB until the batchEnd() method is
>> called, when they are bundled up and sent to FB in a single http
>> request, the client holds a reference to each variable that the
>> results of each request are put into.
>
> Is there a way to refactor into some kind of batch object instead?  This
> would eliminate the need for the references (I'm not presently looking at
> the code so I am not sure if this is an option).

There already is a batch object, Horde_Service_Facebook_BatchRequest::  
that accumulates the API calls before the batch is generated and run.  
Basically, I can't see a way to do this without defeating the purpose  
of abstracting out a lot of the API details. The basic flow is like so  
(in case you have any other ideas):

After starting a batch process, all the method calls perform as normal  
UNTIL it is time to send the request i.e., they perform all the data  
validation, manipulation etc... Instead, the final data is saved in a  
queue. When the batch is run, all that data is packaged up in a  
specific format and send in a single http request to FB, the results  
are parsed, and the referenced variables are set.

I've tried numerous other implementations before I settled on this for  
a variety of reasons. The most attractive alternative was to use  
callbacks and call_user_func_array(). Sadly, call_user_func_* ALWAYS  
returns by value, never by reference and the references are still  
necessary at *some* point in the process due to the abstraction  
layer(s).


mike

The Horde Project (www.horde.org)
mrubinsk at horde.org


More information about the dev mailing list