[xmlrpcflash-development] Iterative loops

[Chad S. <sp...@le...>]

Ed, Isaac :: We need to then make some iterative loop through the 
<param> object for its child nodes of each <param> . Does this really 
make it now a less than usable system [other than ZOPE] or can we 
employ an if statement? Do we need to make some sort of serverType 
function that will use a varietal function set for the type of server. 
I know this is far future but I really think this should be widely 
useable. Nuff about that for now.

Chad


On Tuesday, February 25, 2003, at 03:25  PM, Isaac Levy wrote:

> Hello Chad, Ed,
>
> Here's the xmlrpc spec regarding <param> and <params> :
>
> A single xmlrpc message payload needs to have <params>, as a container 
> for the possibility of multiple <param> nodes. i.e.:
>
> <params>
>   <param>
>     <value></value>
>   </param>
> <params>
>
> Then, inside of a <param> node, the rest of the xmlrpc data types 
> apply.
>
> <?xml version="1.0"?>
> <methodCall>
>    <methodName>example.helloFolks</methodName>
>    <params>
>       <param>
>          <value><string>First thing to pass to the 
> method.</string></value>
>          </param>
>       </params>
>       <param>
>          <value><string>Second thing to pass to the 
> method.</string></value>
>          </param>
>       </params>
>    </methodCall>
>
>
> In the above xml, both <param> nodes get passed to the server method, 
> and the server method can process them as individual parameters passed 
> to the method.  This is good for situations where a single xmlrpc 
> message is loaded with multiple (and possibly totally unrelated) 
> parameters which are to be returned to the client.
>
> Some Basic Reasoning for this design:
> Multiprocessing, for example.  This enables a group of parameters to 
> be handed to a server, which may be designed to asynchronously process 
> multiple parameters and pass them back to the client in a unified 
> payload.
>
> --
> In flash, it seems to me (Chad comment here?), it would be best that 
> when the <params> node is handled in xmlrpc, that it returns an array 
> of the <param> nodes.
>
> As much work with xmlrpc does not involve multiple <param> nodes, this 
> (param vs params) can be a stumbling block when working with the xml 
> payload itself.
>
> Hope that helps-
> Rocket-
> .ike
>
>
>
>
>
>
> On Tuesday, February 25, 2003, at 03:00  PM, Chad Spicer wrote:
>
>> Ed :: I will call Isaac Levy after this meeting I am in and ask him. 
>> More to come.
>>
>> Chad
>>
>>
>> On Tuesday, February 25, 2003, at 09:44  PM, Ed Colmar wrote:
>>
>>>
>>> Thanks Chad!
>>>
>>> Interesting...  So, as far as standards go, which is proper?
>>>
>>> Really, all I care about is how zope is going to do it, as all my 
>>> work
>>> will involve the big Z.
>>>
>>> -e-
>>>
>>> On Tue, 25 Feb 2003, Chad Spicer wrote:
>>>
>>>> Ed :: I checked the AS for getMember and there is no provision for
>>>> <params> or <param> See code below from xml-rpc.as
>>>>
>>>> function GetMember ( Arg1 )
>>>> {
>>>>     if (this.type == 'struct') {
>>>>
>>>>        for (var i in this.value) {
>>>>
>>>>            if (this.value[i].name == Arg1)
>>>>               return this.value[i].value.value;
>>>>
>>>>        }
>>>>
>>>>        return null;
>>>>
>>>>     }
>>>>
>>>>     if (this.type == 'array') {
>>>>
>>>>        return this.value[Arg1].value;
>>>>
>>>>     }
>>>>
>>>>     return null;
>>>> }
>>>>
>>>>
>>>> Now if you simply take out the <params> & <param> of the
>>>> responseexample.xml
>>>>
>>>> <?xml version="1.0"?>
>>>> <methodResponse>
>>>> 	<struct>
>>>> 		<member>
>>>> 			<name>what</name>
>>>> 			<value><string>gotoAndStop</string></value>
>>>> 		</member>
>>>> 		<member>
>>>> 			<name>frame</name>
>>>> 			<value><int>10</int></value>
>>>> 		</member>
>>>> 	</struct>
>>>> </methodResponse>
>>>>
>>>>
>>>> you get from the flash client...
>>>>
>>>> GetResults(): Finished Parsing
>>>> Transmit successfull.
>>>> accessing /what/ field
>>>> gotoAndStop
>>>>
>>>>
>>>> So provisions must be included in getMember or the response must be
>>>> simplified.
>>>>
>>>> I hope that helps. Let me know if tis unclear
>>>>
>>>> Chad Spicer :: Leadbased & ViewArt.network
>>>>
>>>> On Tuesday, February 25, 2003, at 02:14  AM, Ed Colmar wrote:
>>>>
>>>>> <xml-rpcflash_0_5_modified_tests.zip>
>>>
>>> -- 
>>> Green Graphics   :::   Print and Web Design   :::   510.923.0000
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This sf.net email is sponsored by:ThinkGeek
>>> Welcome to geek heaven.
>>> http://thinkgeek.com/sf
>>> //
>>> //  xmlrpcflash-development mailing list
>>> //  xml...@li...
>>> //  
>>> http://lists.sourceforge.net/lists/listinfo/xmlrpcflash-development
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> //
>> //  xmlrpcflash-development mailing list
>> //  xml...@li...
>> //  
>> http://lists.sourceforge.net/lists/listinfo/xmlrpcflash-development
>>
>>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> //
> //  xmlrpcflash-development mailing list
> //  xml...@li...
> //  http://lists.sourceforge.net/lists/listinfo/xmlrpcflash-development
>