We can rename load() to get() and add the data parameter.  But I disagree that we 
should be the ones who decide what the varible is named when there is nothing gained 
by doing so.  Instead we can always use a data object, where the variable names are 
arbitrary:

var data = {
  name : "My Name",
  number : 2,
  array : (1,2,3)
}
io.get('script.asp',data,fn);

This would serialize the object and load the url as:

url.asp?name=My%20Name&number=2&array=1,2,3

This way you are not forced to code your ASP/Perl/PHP code in any particular manner.  
Except for maybe transferring an array where you'd probably need to unencode it within 
the server script.

The same goes for retrieving data from the page, have no default variable, and l
et the developer choose the variable name:

var myResult = "success";  // generate on server

e.getSource().getVariable('myResult');  // obtain in load handler

For an intermediate version we can just support numbers and strings.  But for anything 
much more complex than arrays (like linked lists, and multidimensional arrays), we 
should forfeit to an XML/RPC based solution because I'd like to keep IOElement a small 
and easy communication scheme.

Regards,
Dan Steinman


On Fri, Jan 18, 2002 at 05:52:07AM -0800, Raymond Irving wrote:
> 
> --- Dan Steinman <[EMAIL PROTECTED]> wrote:
> >... Maybe replace the
> > common send() method with separate post() and get()
> > methods.  I believe get() can be exactly the same as
> > what load() does, for http get you don't have to
> > submit a form, but for post we definately need the
> > submit that you added.
> 
> The post() method is certainly the way to go, but I
> think the load() method should be  uused in place of
> the get() by just adding the data param:
> 
> ioelm.load(url,data,fn)
> 
> It would be much easier to use the IOData object for
> sending data rather than appending the name=value pair
> to the url (as we now do with the load() method).
> I also think there should be a default variable name
> used when sending/receiving data. for example, let's
> say a user wants to send/receive some xml data to and
> from the server, they could simple type the following:
> 
> var xmldata='<root><node></node></root>'
> ioelm.post('foo.asp',xmldata,fn)
> // note the "data" paramater should be either an
> IOData object or String
> 
> The default variable sent to the server could be
> "ioData". This could also be the name of the
> javascript variable return from the server if no name
> is supplied.
> 
> 
> > I don't think the .getResult() method is necessary. 
> > I don't like the idea of being restricted only one
> > variable to recieve data from.  Instead of
> > generating a textarea which contains the
> > information, you can just generate a JavaScript
> > variable and retrieve it with
> > e.getSource().getScope().variableName - maybe we
> > should add a wrapper like
> > IOElement.getValue('variableName')?.
> 
> I like the idea of a getValue() method, but I think if
> should be on the created object and not on IOElement:
> 
> instead of using:
>   e.getSource().getScope().variableName
> use:
>   e.getSource().getValue(variableName)
> 
> I only used the <form> element to return large text
> values. A mixture of javascript variables and form
> elements can be used when retrieving data. It's very
> difficult to send 5K of xml data in javascript
> variable. There's still a way to get 5ks of data into
> a variable, but you might have to use some form of
> encoding/decoding.
> 
> Note (while on the topic of encoding/decoding):
> The getURLArguments() found in dnyapi is not decoding
> the url data. Example: Hello+world should be decoded
> as Hello World.
> 
> > We could also distribute some prebuilt server
> > scripts (PHP and ASP) for examples.  Like one for
> > retreiving the contents of a URL (from another
> > server) as a JavaScript variable.  We could also
> > encapsulate an http post/get call into a server
> > script, so that you can post to another server, and
> > recieve the results from that server as a JavaScript
> > variable also.  This functionality would allow you
> > to avoid the security violation of obtaining data
> > from a different server through JavaScript.
> 
> Yes! I'm all for that! This would be the very first
> time dynapi enters the server-side :)
> 
> 
> --
> Raymmond Irving
> 
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/
> 
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://www.mail-archive.com/[email protected]/

_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[email protected]/

Reply via email to