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

datasource JSON string problem

Expand Messages
  • WongTseng
    Hi, I have a question about the correct JSON string format that a datasource can receive through XHR. One thing puzzling me is that when I format the JSON
    Message 1 of 7 , Feb 29, 2008
    • 0 Attachment
      Hi,

          I have a question about the correct JSON string format that a datasource can receive through XHR. One thing puzzling me is that when I format the JSON string without double quotes around the attribute names, the datasource will raise a data error message.
         for example,
             {name: "Tom"} // wrong, data error
         but if I put it like this,
             {"name" : "Toma"} // it's correct, data table displays it nicely.
         So, what is the defference between these two kind of writting? Thanks.

      --
      Best Regards
      Tseng Wong
    • Satyam
      The new JSON decoder, YAHOO.lang.JSON is more strict than the default decoder included in the DataSource. If you don t include the new JSON decoder and let
      Message 2 of 7 , Mar 1, 2008
      • 0 Attachment
        The new JSON decoder, YAHOO.lang.JSON is more strict than the default decoder included in the DataSource.  If you don't include the new JSON decoder and let the DataSource handle it, it will probably take it.  The JSON standard (see sidebox in http://www.json.org/) says that all identifiers should be strings (with quotes).  That allows for the flexibility of having reserved words or otherwise questionable strings as field identifiers, but does force you to enclose everything in quotes.
         
        Satyam
         
        ----- Original Message -----
        From: WongTseng
        Sent: Saturday, March 01, 2008 2:54 AM
        Subject: [ydn-javascript] datasource JSON string problem

        Hi,

            I have a question about the correct JSON string format that a datasource can receive through XHR. One thing puzzling me is that when I format the JSON string without double quotes around the attribute names, the datasource will raise a data error message.
           for example,
               {name: "Tom"} // wrong, data error
           but if I put it like this,
               {"name" : "Toma"} // it's correct, data table displays it nicely.
           So, what is the defference between these two kind of writting? Thanks.

        --
        Best Regards
        Tseng Wong


        No virus found in this incoming message.
        Checked by AVG Free Edition.
        Version: 7.5.516 / Virus Database: 269.21.2/1305 - Release Date: 29/02/2008 18:32
      • Adam Moore
        ... JSON is a subset of JavaScript, and the identifier requirement is one of rules an encoder must comply with in order to produce a compliant JSON string.
        Message 3 of 7 , Mar 1, 2008
        • 0 Attachment
          On Sat, Mar 01, 2008 at 11:00:55AM +0100, Satyam wrote:
          > The new JSON decoder, YAHOO.lang.JSON is more strict than the default
          > decoder included in the DataSource. If you don't include the new JSON
          > decoder and let the DataSource handle it, it will probably take it.
          > The JSON standard (see sidebox in http://www.json.org/) says that all
          > identifiers should be strings (with quotes). That allows for the
          > flexibility of having reserved words or otherwise questionable strings
          > as field identifiers, but does force you to enclose everything in
          > quotes.

          JSON is a subset of JavaScript, and the identifier requirement is one of
          rules an encoder must comply with in order to produce a compliant JSON
          string. While is it acceptable for a decoder to try to parse a broken
          JSON string, it isn't acceptable for an encoder to produce one. If you
          emit a JSON string, any decoder should be able to parse it.

          There are compliant encoders available for almost every common
          programming language, so you should not have to write your own anyway.
          Check out the bottom of json.org to find one.

          -Adam

          > ----- Original Message -----
          > From: WongTseng
          > To: ydn-javascript@yahoogroups.com
          > Sent: Saturday, March 01, 2008 2:54 AM
          > Subject: [ydn-javascript] datasource JSON string problem

          >
          > I have a question about the correct JSON string format that a
          > datasource can receive through XHR. One thing puzzling me is
          > that when I format the JSON string without double quotes around
          > the attribute names, the datasource will raise a data error
          > message. for example, {name: "Tom"} // wrong, data error but if
          > I put it like this, {"name" : "Toma"} // it's correct, data
          > table displays it nicely. So, what is the defference between
          > these two kind of writting? Thanks.
          >
          > -- Best Regards Tseng Wong
        • WongTseng
          Thanks a lot. But I wonder since javascript has eval( ) method which can evaluate the JSON string, why somebody ever bother to create this JSON string
          Message 4 of 7 , Mar 5, 2008
          • 0 Attachment
            Thanks a lot.
            But I wonder since javascript has eval( )  method which can evaluate the JSON string, why somebody ever bother to create this JSON string encoder.

            2008/3/2, Adam Moore <adamoore@...>:
            On Sat, Mar 01, 2008 at 11:00:55AM +0100, Satyam wrote:
            > The new JSON decoder, YAHOO.lang.JSON is more strict than the default
            > decoder included in the DataSource.  If you don't include the new JSON
            > decoder and let the DataSource handle it, it will probably take it.
            > The JSON standard (see sidebox in http://www.json.org/) says that all
            > identifiers should be strings (with quotes).  That allows for the
            > flexibility of having reserved words or otherwise questionable strings
            > as field identifiers, but does force you to enclose everything in
            > quotes.


            JSON is a subset of JavaScript, and the identifier requirement is one of
            rules an encoder must comply with in order to produce a compliant JSON
            string.  While is it acceptable for a decoder to try to parse a broken
            JSON string, it isn't acceptable for an encoder to produce one.  If you
            emit a JSON string, any decoder should be able to parse it.

            There are compliant encoders available for almost every common
            programming language, so you should not have to write your own anyway.
            Check out the bottom of json.org to find one.


            -Adam


            >   ----- Original Message -----
            >   From: WongTseng
            >   To: ydn-javascript@yahoogroups.com
            >   Sent: Saturday, March 01, 2008 2:54 AM
            >   Subject: [ydn-javascript] datasource JSON string problem

            >

            >       I have a question about the correct JSON string format that a
            >       datasource can receive through XHR. One thing puzzling me is
            >       that when I format the JSON string without double quotes around
            >       the attribute names, the datasource will raise a data error
            >       message.  for example, {name: "Tom"} // wrong, data error but if
            >       I put it like this, {"name" : "Toma"} // it's correct, data
            >       table displays it nicely.  So, what is the defference between
            >       these two kind of writting? Thanks.
            >
            >   -- Best Regards Tseng Wong




            --
            Best Regards
            Wong Tseng
          • Satyam
            Because it spares you from getting malicious code into your application. Ultimately, the JSON decoder does eval() your string but not before validating and
            Message 5 of 7 , Mar 5, 2008
            • 0 Attachment
              Because it spares you from getting malicious code into your application.  Ultimately, the JSON decoder does eval() your string but not before validating and ensuring it has no executable code in it, just values.
               
               
              ----- Original Message -----
              From: WongTseng
              Sent: Wednesday, March 05, 2008 1:09 PM
              Subject: Re: [ydn-javascript] datasource JSON string problem

              Thanks a lot.
              But I wonder since javascript has eval( )  method which can evaluate the JSON string, why somebody ever bother to create this JSON string encoder.

              2008/3/2, Adam Moore <adamoore@...>:
              On Sat, Mar 01, 2008 at 11:00:55AM +0100, Satyam wrote:
              > The new JSON decoder, YAHOO.lang.JSON is more strict than the default
              > decoder included in the DataSource.  If you don't include the new JSON
              > decoder and let the DataSource handle it, it will probably take it.
              > The JSON standard (see sidebox in http://www.json.org/) says that all
              > identifiers should be strings (with quotes).  That allows for the
              > flexibility of having reserved words or otherwise questionable strings
              > as field identifiers, but does force you to enclose everything in
              > quotes.


              JSON is a subset of JavaScript, and the identifier requirement is one of
              rules an encoder must comply with in order to produce a compliant JSON
              string.  While is it acceptable for a decoder to try to parse a broken
              JSON string, it isn't acceptable for an encoder to produce one.  If you
              emit a JSON string, any decoder should be able to parse it.

              There are compliant encoders available for almost every common
              programming language, so you should not have to write your own anyway.
              Check out the bottom of json.org to find one.


              -Adam


              >   ----- Original Message -----
              >   From: WongTseng
              >   To: ydn-javascript@yahoogroups.com
              >   Sent: Saturday, March 01, 2008 2:54 AM
              >   Subject: [ydn-javascript] datasource JSON string problem

              >

              >       I have a question about the correct JSON string format that a
              >       datasource can receive through XHR. One thing puzzling me is
              >       that when I format the JSON string without double quotes around
              >       the attribute names, the datasource will raise a data error
              >       message.  for example, {name: "Tom"} // wrong, data error but if
              >       I put it like this, {"name" : "Toma"} // it's correct, data
              >       table displays it nicely.  So, what is the defference between
              >       these two kind of writting? Thanks.
              >
              >   -- Best Regards Tseng Wong




              --
              Best Regards
              Wong Tseng


              No virus found in this incoming message.
              Checked by AVG Free Edition.
              Version: 7.5.516 / Virus Database: 269.21.4/1312 - Release Date: 04/03/2008 21:46
            • federico.galassi
              ... JSON decoder does eval() your string but not before validating and ensuring it has no executable code in it, just values. malicious javascript is an
              Message 6 of 7 , Mar 6, 2008
              • 0 Attachment
                --- In ydn-javascript@yahoogroups.com, "Satyam" <satyam@...> wrote:
                >
                > Because it spares you from getting malicious code into your application. Ultimately, the
                JSON decoder does eval() your string but not before validating and ensuring it has no
                executable code in it, just values.

                malicious javascript is an exception, not the common case. Most ajax apps will
                be taking json from their own servers. How much is the perfomance penalty between
                parsing and eval'ing? is there a way to say datasource to just eval the string?

                Federico
              • Satyam
                ... From: federico.galassi To: Sent: Thursday, March 06, 2008 9:01 AM Subject: [ydn-javascript] Re:
                Message 7 of 7 , Mar 6, 2008
                • 0 Attachment
                  ----- Original Message -----
                  From: "federico.galassi" <federico@...>
                  To: <ydn-javascript@yahoogroups.com>
                  Sent: Thursday, March 06, 2008 9:01 AM
                  Subject: [ydn-javascript] Re: datasource JSON string problem


                  > --- In ydn-javascript@yahoogroups.com, "Satyam" <satyam@...> wrote:
                  >>
                  >> Because it spares you from getting malicious code into your application.
                  >> Ultimately, the
                  > JSON decoder does eval() your string but not before validating and
                  > ensuring it has no
                  > executable code in it, just values.
                  >
                  > malicious javascript is an exception, not the common case. Most ajax apps
                  > will
                  > be taking json from their own servers.

                  Who says your server cannot be compromised? Never heard about SQL
                  injection? SQL is not the only thing that can be injected into a database
                  field, which your application might later happily disperse elsewhere. Even
                  if you are secured against SQL injection, you might not be able to prevent
                  injection of other code, such as JavaScript.

                  > How much is the perfomance penalty between
                  > parsing and eval'ing? is there a way to say datasource to just eval the
                  > string?

                  The JSON utility does eval() the JSON string, it simply uses a three or four
                  regular expressions to validate it before it does so. It does very little at
                  JavaScript interpreter speed and it does no looping so calling the regexp
                  engine (which is fast enough) three or four times before the actual eval()
                  doesn't really add much.

                  Satyam


                  >
                  > Federico
                  >
                  >
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  > --
                  > No virus found in this incoming message.
                  > Checked by AVG Free Edition.
                  > Version: 7.5.516 / Virus Database: 269.21.5/1314 - Release Date:
                  > 05/03/2008 18:38
                  >
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.