Loading ...
Sorry, an error occurred while loading the content.

21747Re: [ydn-javascript] DataSource Using URL w/ Query Parameters

Expand Messages
  • Satyam
    Dec 3, 2007
      ----- Original Message -----
      From: "Randall R Schulz" <rschulz@...>
      To: <ydn-javascript@yahoogroups.com>
      Sent: Monday, December 03, 2007 7:03 PM
      Subject: Re: [ydn-javascript] DataSource Using URL w/ Query Parameters


      > On Monday 03 December 2007 09:27, Randall R Schulz wrote:
      >> ...
      >>
      >> While I try to sort out the problems Grails seems to be having with
      >> POST requests, at least some of them, is there a way to get DataTable
      >> / DataSource to use a GET to retrieve its data? I wasn't able to find
      >> anything that suggests I can control this (but using such a common
      >> word as "GET" in a web search tends to confound things).

      Yes, the connMethodPost property of the DataSource lets you decide on that.

      http://developer.yahoo.com/yui/docs/YAHOO.util.DataSource.html#connMethodPost

      The default is false, which means queries will be sent as GET requests.
      Setting it to true will tell the DataSource to do a POST: In that case, the
      URL base you set when you instantiate the DataSource will be used as the
      server address and the arguments set in the initialRequest configuration
      parameter of the DataTable will be in the POST data.

      Usually, when you retrieve information, when you only sent a few arguments
      to identify what is it you want, you would usually use a GET request because
      that is basically what you are doing, you want to get something and you are
      telling the server what is it. On the other hand, when you meant to change
      something in the server, then you use a POST request. In a GET request you
      send a few bytes and you get a usualyl large response. In a post data the
      opposite is true, you send possibly a lot of data and you receive an Ok,
      well, in AJAX you usually do, in normal web pages, you would receive the OK
      framed in a full HTML page. Thus, GET has limits as to the amount of data
      it can send to the server, it depends on each browser and has even changed
      in between versions so never attept to send the contents of an unlimited
      textarea in a GET since it might silently truncate it. POST does not have
      practical limits in neither direction. On the other hand, a GET request you
      can add to the browser bookmarks or favorites and it will store its
      arguments, in a POST requests, the arguments will never go into the
      bookmark. For AJAX transactions, the user doesn't see them so he cannot
      bookmark them. Thus, I prefer POST, specially since YUI makes it simple to
      use either. I don't use the History Manager so I don't know if it matters
      there. In the examples in the YUI blog articles, I used GET most of the
      time, except for the inline-cell editing examples because they deserve a
      POST.

      >
      > Welcome (me) to the world of open source development (on the bleeding
      > edge). It _was_ a Grails problem and the fix went into the snapshot
      > builds earlier this morning.
      >
      >
      >> Also, GET seems much more appropriate for a pure information
      >> retrieval operation, which surely characterizes any request whose
      >> purpose is to populate a client-side data structure or display. Why
      >> do DataSource / DataTable use POST?

      They don't the default is GET.

      >
      > I'd still like to know if GET is an option. I found one Nabble entry
      > where a person was asking if he could use POST instead of GET, which
      > suggests it is, or at least was, possible. But I still haven't found
      > any details on how to control which HTTP request method is used by
      > DataSource and / or DataTable.
      >

      see above.

      Satyam


      >
      > Randall Schulz
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      > --
      > No virus found in this incoming message.
      > Checked by AVG Free Edition.
      > Version: 7.5.503 / Virus Database: 269.16.13/1165 - Release Date:
      > 02/12/2007 20:34
      >
      >
    • Show all 10 messages in this topic