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

Re: [ydn-javascript] Re: DataSource and parseJSONData

Expand Messages
  • Hollywood
    Luke, I am anxiously, as everyone I assume, am looking forward to 2.5 especially with the DataTable/DataSource enhancements. I ll definetly check out the
    Message 1 of 8 , Jan 31, 2008
    • 0 Attachment
      Luke,
       
      I am anxiously, as everyone I assume, am looking forward to 2.5 especially with the DataTable/DataSource enhancements.  I'll definetly check out the parseJSONData updates as I would definetly perfer to use stuff as is as it makes migration to new builds much less painful!
       
      Indeed, you are right, it may be faster to do it that way.  However, from a programming point of view, I wanted to keep things as similiar in nature as possible; i.e. the resultsList/field combo works in way X, params should work in much the same way.
       
      However in speaking of all this, I do begin to wonder if it is really the DataSource's place to be dealing with tabular data only.  Should not the DataSource just deal with being a wrapper around the connection and being able to return and say in the case of JSON (or XML, etc.) data return a parsed object (i.e. just the jsonObj in parseJSONData) and then let the client, i.e. DataTable, do any additional work such as dealing with the "resultsList/fields"?  DataSource seems to be a very useable piece of functionality for many different data fetch tasks, hate to see it locked down to only being able to deal with tabular info as it sorta is now with regards to at least JSON parsing.
       
      ----- Original Message -----
      From: y_lsmith
      Sent: Thursday, January 31, 2008 10:30 AM
      Subject: [ydn-javascript] Re: DataSource and parseJSONData

      --- In ydn-javascript@ yahoogroups. com, "Hollywood" <impulsegto@ ...> wrote:
      >
      > That is all well and good. But that is not the issue. The issue is
      when it gets back to the dataTable. I'm not interested in overriding
      the data when its in the DataSource, but rather when it gets to the
      DataTable.
      >
      > The server-side pagination/sorting examples I believe is not the
      correct solution. To me the DataSource should not be modifying the
      DataTable. DataTable should request data via the DataSource, the
      DataSource should provide that data, and then its up to the DataTable
      to do with it what it wants. With the my override to the
      parseJSONData, instead of defining a doBeforeCallback function on the
      DataSource to setup the dataTable.set( ) for the sorting when the data
      is returned from the server, you can just define a doBeforeLoadData
      function on the DataTable and have it call the set sorting. This
      keeps both operations for the sorting within the scope of the
      DataTable where it belongs. The DataSource should know *nothing*
      about the setting up the DataTable.

      >
      >
      > And yes, but there are also two issues with that, its in 2.5.0 and
      not 2.4.1 which is current, and secondly its still an issue in that
      its in the DataSource and that the DataSource is sending the DataTable
      stripped down information.

      > Lastly, and while everyone has their own coding style, when I
      actually took a look at the parseJSONData it from a code standpoint
      didn't make a whole lot of sense. There are three conditions and
      unmodified parseJSONData needs to meet: a) you must have a valid
      oRawResponse, b) you must have a responseSchema. resultsList defined,
      and c) you must have a responseSchema. fields array defined. If you
      don't have all three of those then the parseJSONData isn't going to
      work. In the code as it stands, there is a check for the
      oRawResponse and fields, but never the resultsList, so if you pass in
      a null or empty string you get an error during the jsonList =
      eval("jsonObj. "....) call. IMO (and yes, its no better or worse than
      anyone elses, some people not withstanding) you should check for the
      three conditions up front. If those three conditions aren't
      satisfied, return with your error message. Next step would attempt
      to parse the oRawResponse to produce your jsonObj. Since you are in a
      big if/else condition, doing all the (!jsonObj) and setting bError is
      superfluous. Just wait til you get done with your if/else for parsing
      the raw data and then do a single (!jsonObj) check and kick out with
      error if jsonObj is bad. Less coding, one less variable, always good
      thing. Then process your jsonObj to produce your jsonList. Now my
      example doesn't do the upfront checks for the resultsList/ fields, it
      does it a bit lower after parsing the jsonObj, and it really
      shouldn't. jsonList *is* required, so that means the
      resultsList/ fields is mandatory. First check should really be this:
      >
      > if (!oRawResponse &&
      !YAHOO.lang. isString( this.responseSch ema.resultsList) &&
      !YAHOO.lang. isArray(this. responseSchema. resultsFields) )
      >

      Hollywood,

      Thanks for the feedback! We appreciate the code review. It looks
      like you found some areas in DataSource and DataTable that we had also
      noted needed some improvement. I hope you'll take a look at the
      changes in 2.5. Among other things, parseJSONData got a good deal of
      attention, and the parsed-but-not- reduced data will be provided from
      the DataSource as well. Hopefully you'll find that all your
      requirements will be met without the need for extensive customization.

      In 2.4.1 land, it sounds like yours is a clear case for either
      overriding DataSource's parseJSONData as you have done or overriding
      the DataTable's doBeforeLoadData to, as Satyam suggested, reparse the
      oRawResponse JSON to access the additional response payload. As eval
      can be quite expensive, you might try benchmarking a reparse in
      doBeforeLoadData vs your parseJSONData override. With smaller JSON
      strings, it *might* be faster to do a single JSON parse followed by
      explicit object access than to execute a series of evals to pull key
      data for your params array.

      By all means, if you (or anyone) see a performance issue or bug,
      please file a bug on SourceForge.

      If, as in this case, you have a suggestion for how to override a
      function to solve a particular problem, we encourage you to share. We
      all benefit.

      Thanks,
      Luke

    Your message has been successfully submitted and would be delivered to recipients shortly.