Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #15644 > unrolled thread

String Processing in JavaScript

Back to article view | Back to comp.lang.javascript

Contents

  String Processing in JavaScript Gene Wirchenko <genew@ocis.net> - 2012-08-31 15:56 -0700
    Re: String Processing in JavaScript Mike Winter <usenet@michael-winter.me.invalid> - 2012-09-01 02:30 +0100
      Re: String Processing in JavaScript Gene Wirchenko <genew@ocis.net> - 2012-09-02 17:56 -0700
    Re: String Processing in JavaScript Jim T. <x@y.z> - 2012-08-31 22:30 -0400
      Re: String Processing in JavaScript "Mel Smith" <med_cutout_syntel@aol.com> - 2012-08-31 21:47 -0600
        Re: String Processing in JavaScript "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-09-01 08:51 +0000
          Re: String Processing in JavaScript "Mel Smith" <med_cutout_syntel@aol.com> - 2012-09-01 08:38 -0600
        Re: String Processing in JavaScript Gene Wirchenko <genew@ocis.net> - 2012-09-02 18:04 -0700
          Re: String Processing in JavaScript "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-09-03 16:30 +0000
          Re: String Processing in JavaScript Mike Winter <usenet@michael-winter.me.invalid> - 2012-09-03 21:23 +0100
            Re: String Processing in JavaScript Gene Wirchenko <genew@ocis.net> - 2012-09-03 14:26 -0700
    Re: String Processing in JavaScript Stefan Weiss <krewecherl@gmail.com> - 2012-09-03 19:29 +0200
      Re: String Processing in JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-03 21:45 +0200
      Re: String Processing in JavaScript Gene Wirchenko <genew@ocis.net> - 2012-09-03 14:27 -0700
        Re: String Processing in JavaScript Stefan Weiss <krewecherl@gmail.com> - 2012-09-04 00:48 +0200
          Re: String Processing in JavaScript Gene Wirchenko <genew@ocis.net> - 2012-09-03 17:20 -0700
          Re: String Processing in JavaScript Tim Streater <timstreater@greenbee.net> - 2012-09-04 10:06 +0100
            Re: String Processing in JavaScript Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-09-04 20:02 +1000
            Re: String Processing in JavaScript Gene Wirchenko <genew@ocis.net> - 2012-09-04 08:47 -0700

#15644 — String Processing in JavaScript

Dear JavaScripters:

     I will be passing back long result strings to my Web pages. These
strings have to be parsed into error codes and form field contents.
What I am working with looks like
          <fieldname>:<value length>:<value>\n
The value is encodeURIComponent()ed.

     The way that I am doing it right now for the first two values on
a line is to look for a colon (with String.indexOf(), grab what is in
front of the colon, and then delete up to the colon from the string.
(I then grab the indicated number of characters and decode for the
field value and ensure the following character is "\n" and delete up
to the "\n".)

     I have to delete because of how String.indexOf() works.  It does
not have a string start point.  Am I better off:
  1) doing what I am doing,
  2) keeping track of where I am in the string and have each
.indexOf() operate on a .substr() of the string,  or
  3) using some other function I know not of?  (What?)

     I suppose that another way of doing it would be a regex, but they
have poor error handling.  I expect to make a lot of errors while
working this all out, and I prefer to get good error messages rather
than just a parse failure.

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]

#15647

On 31/08/2012 23:56, Gene Wirchenko wrote:

[snip]

>       I have to delete because of how String.indexOf() works.  It does
> not have a string start point.

Yes it does. The String.prototype.indexOf method has a second, optional 
argument that specifies the position (zero-based, inclusive) from which 
the search begins. The same applies to String.prototype.lastIndexOf 
except that the default start is obviously the string length (the end) 
rather than 0.

For what it's worth, you can't actually delete characters from a string. 
Strings are immutable and any changes are separate, modified copies 
(with all the performance implications that may bring).

[snip]

Hope that helps,
-- 
Mike Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[toc] | [prev] | [next] | [standalone]

#15660

On Sat, 01 Sep 2012 02:30:10 +0100, Mike Winter
<usenet@michael-winter.me.invalid> wrote:

>On 31/08/2012 23:56, Gene Wirchenko wrote:
>
>[snip]
>
>>       I have to delete because of how String.indexOf() works.  It does
>> not have a string start point.
>
>Yes it does. The String.prototype.indexOf method has a second, optional 
>argument that specifies the position (zero-based, inclusive) from which 
>the search begins. The same applies to String.prototype.lastIndexOf 
>except that the default start is obviously the string length (the end) 
>rather than 0.

     Somehow, I missed that.  Maybe, a dodgy site.

     Thank you.

>For what it's worth, you can't actually delete characters from a string. 
>Strings are immutable and any changes are separate, modified copies 
>(with all the performance implications that may bring).

     At the abstract level I am operating at, yes, you can.  The
implementation details do not matter so much to me as long as I get
reasonable performance.  That stated, I do prefer to not change things
if I need not.  It tends to be faster, and lets me ignore more of the
things under the hood.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15648

On Fri, 31 Aug 2012 15:56:27 -0700, Gene Wirchenko <genew@ocis.net>
wrote:

>Dear JavaScripters:
>
>     I will be passing back long result strings to my Web pages. These
>strings have to be parsed into error codes and form field contents.
>What I am working with looks like
>          <fieldname>:<value length>:<value>\n
>The value is encodeURIComponent()ed.
>
>     The way that I am doing it right now for the first two values on
>a line is to look for a colon (with String.indexOf(), grab what is in
>front of the colon, and then delete up to the colon from the string.
>(I then grab the indicated number of characters and decode for the
>field value and ensure the following character is "\n" and delete up
>to the "\n".)
>
>     I have to delete because of how String.indexOf() works.  It does
>not have a string start point.  Am I better off:
>  1) doing what I am doing,
>  2) keeping track of where I am in the string and have each
>.indexOf() operate on a .substr() of the string,  or
>  3) using some other function I know not of?  (What?)

Perhaps String.split() ?

>     I suppose that another way of doing it would be a regex, but they
>have poor error handling.  I expect to make a lot of errors while
>working this all out, and I prefer to get good error messages rather
>than just a parse failure.
>
>Sincerely,
>
>Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15651

Jim said:
> Perhaps String.split() ?


Gene:

    Agree 1000% with Jim !

    I send 2000+ chars strings to/from my server, and my server .exe builds 
a 'splittable' string back to the browser.

    Your structure is ideal for a 'double' split. The 1st split would bust 
up the string at the 'newline' char creating an array of n-rows of chars

    Then, during the parse of each row,  you can break that row of this main 
array into another 1-d array of three values by 'splitting' at the colon 
char.

    I found this to be a nifty way of parsing my incoming strings.

    Because your main split is at 2-char '\n' set, I guess you'd have to use 
a regex expression to make the split.  Why not just use the 'not' charater 
('~') as the line terminator ?

    btw, because I know *my* incoming data, I use other chars for delimiters 
that would never appear in my incoming string (e.g., ~  ^  ! etc)

    So, if you *know always* the set of chars input, then others can be used 
as delimiters.

Good Luck !

-Mel Smith
 

[toc] | [prev] | [next] | [standalone]

#15653

Mel Smith wrote on 01 sep 2012 in comp.lang.javascript:

>     Because your main split is at 2-char '\n' set, I guess you'd have
>     to use a regex expression to make the split. 

Nothing wrong with that:

var t = t.split(/\n/);

However, you guess wrong, this works just fine:

var t = t.split('\n');

And, a 2 character boundery split() does not need regex in general:

var t = t.split('ab');

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#15655

Evertjan said

>>     Because your main split is at 2-char '\n' set, I guess you'd have
>>     to use a regex expression to make the split.
>
> Nothing wrong with that:
>
> var t = t.split(/\n/);
>
> However, you guess wrong, this works just fine:
>
> var t = t.split('\n');
>
> And, a 2 character boundery split() does not need regex in general:
>
> var t = t.split('ab');


Evertjan:

    I never knew that one could split on a 2-char sequence.

Thank you for more enlightenment !

-Mel

[toc] | [prev] | [next] | [standalone]

#15661

On Fri, 31 Aug 2012 21:47:40 -0600, "Mel Smith"
<med_cutout_syntel@aol.com> wrote:

>Jim said:
>> Perhaps String.split() ?

>    Agree 1000% with Jim !
>
>    I send 2000+ chars strings to/from my server, and my server .exe builds 
>a 'splittable' string back to the browser.
>
>    Your structure is ideal for a 'double' split. The 1st split would bust 
>up the string at the 'newline' char creating an array of n-rows of chars

     Assuming an encodeURIComponent() result can never contain
newline.  I have not come across a precise definition of exactly what
it does.

>    Then, during the parse of each row,  you can break that row of this main 
>array into another 1-d array of three values by 'splitting' at the colon 
>char.

     If I have a safe split character, then two values as I do not
need the length indication.

>    I found this to be a nifty way of parsing my incoming strings.
>
>    Because your main split is at 2-char '\n' set, I guess you'd have to use 
>a regex expression to make the split.  Why not just use the 'not' charater 
>('~') as the line terminator ?

     I was thinking of readability if I ever have to debug.

>    btw, because I know *my* incoming data, I use other chars for delimiters 
>that would never appear in my incoming string (e.g., ~  ^  ! etc)

     Anything might appear in mine.

>    So, if you *know always* the set of chars input, then others can be used 
>as delimiters.

     If.  I think that I am safe with encodeURIComponent() on the
user-entered values, but I need a guarantee that such an encoded value
can never contain some character to be safe using String.split().  I
have not seen anything about encodeURIComponent() that gives such a
list.  Pointer, please, if you have one.

>Good Luck !

     She is a fickle lady.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15663

Gene Wirchenko wrote on 03 sep 2012 in comp.lang.javascript:

>   If.  I think that I am safe with encodeURIComponent() on the
> user-entered values, but I need a guarantee that such an encoded value
> can never contain some character to be safe using String.split().  I
> have not seen anything about encodeURIComponent() that gives such a
> list.  Pointer, please, if you have one.

If you use a string as a split pointer, you can be reasonably sure it does 
not exist by accident in human readable text:

var arr = t.split('^^yyGrGr#~~#%');

However if you are free to specify the source split pointer, 
why not test for that character or string source side?


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#15667

On 03/09/2012 02:04, Gene Wirchenko wrote:
> On Fri, 31 Aug 2012 21:47:40 -0600, "Mel Smith"
> <med_cutout_syntel@aol.com> wrote:
>
>> Jim said:
>>> Perhaps String.split() ?
>
>>     Agree 1000% with Jim !
>>
>>     I send 2000+ chars strings to/from my server, and my server .exe builds
>> a 'splittable' string back to the browser.
>>
>>     Your structure is ideal for a 'double' split. The 1st split would bust
>> up the string at the 'newline' char creating an array of n-rows of chars
>
>       Assuming an encodeURIComponent() result can never contain
> newline.  I have not come across a precise definition of exactly what
> it does.

The formal definition is in section 15.1.3 [1] of ECMA-262 (5.1/June 
2011 Edition, but it seems to me to be functionally identical to the 
third edition).

Essentially, if the string argument contains any characters other than 
the following from the ASCII character set, those characters will be 
percent-encoded in the returned string: letters and digits, hyphen-minus 
(-), underscore (_), full-stop/period/dot (.), exclamation mark (!), 
tilde (~), asterisk (*), apostrophe ('), and parentheses ("(", ")"). 
These are the characters from the "unreserved" and "mark" grammar 
productions in RFC 2396 - URI Generic Syntax [2] (although this RFC has 
been superceded).

So yes, you will not encounter a CR or LF (or /any/ control character 
for that matter) after successfully returning from the 
encodeURIComponent function.

I hope that helps,
Mike

[1] <http://ecma-international.org/ecma-262/5.1/#sec-15.1.3>
[2] <http://tools.ietf.org/html/rfc2396#page-27>

-- 
Mike Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[toc] | [prev] | [next] | [standalone]

#15669

On Mon, 03 Sep 2012 21:23:15 +0100, Mike Winter
<usenet@michael-winter.me.invalid> wrote:

>On 03/09/2012 02:04, Gene Wirchenko wrote:

[snip]

>>       Assuming an encodeURIComponent() result can never contain
>> newline.  I have not come across a precise definition of exactly what
>> it does.
>
>The formal definition is in section 15.1.3 [1] of ECMA-262 (5.1/June 
>2011 Edition, but it seems to me to be functionally identical to the 
>third edition).

     I have that handy.  Thank you for the pointer.

     Some of the algorithms for various functions are written in
not-terribly-readable form.  The p-code in this section is
particularly bad.  YIKES!

     The writing is not the best.  It includes this gem of ambiguity:
"When a character to be included in a URI is not listed above or is
not intended to have the special meaning sometimes given to the
reserved characters, that character must be encoded."  Listed above
are a number of sets of characters, and it is unclear which are being
referred to.  It might be all, but a more precise statement would have
been better.

>Essentially, if the string argument contains any characters other than 
>the following from the ASCII character set, those characters will be 
>percent-encoded in the returned string: letters and digits, hyphen-minus 
>(-), underscore (_), full-stop/period/dot (.), exclamation mark (!), 
>tilde (~), asterisk (*), apostrophe ('), and parentheses ("(", ")"). 
>These are the characters from the "unreserved" and "mark" grammar 
>productions in RFC 2396 - URI Generic Syntax [2] (although this RFC has 
>been superceded).

     Would that I could do
          Copy previous paragraph to ECMAScript standard section
15.1.3.

>So yes, you will not encounter a CR or LF (or /any/ control character 
>for that matter) after successfully returning from the 
>encodeURIComponent function.
>
>I hope that helps,

     It does.  Thank you.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15664

On 2012-09-01 00:56, Gene Wirchenko wrote:
>      I will be passing back long result strings to my Web pages. These
> strings have to be parsed into error codes and form field contents.
> What I am working with looks like
>           <fieldname>:<value length>:<value>\n
> The value is encodeURIComponent()ed.

From your other posts, it appears that you're in control of both backend
and client code. If that's the case, you may want to consider one of the
many standardized data transfer formats.
JSON would be the obvious choice, as it's trivially easy to use for a
JavaScript client, and it's well supported in every major server-side
language. Others possible choices include XML (also well supported by
JS) or YAML, etc.

The major advantages over homebrew data formats are

1) less code, because native support already exists

2) no worrying about separators and "safe" characters

3) they support hierarchical/structured data

4) they're standardized, so you'll still know how they work 2 years
after you finish writing this part. As will other people who may inherit
your code.

5) they're standardized, which means your data is now accessible to
other tools (like debuggers, syntax checkers, and unit test frameworks)


- stefan

[toc] | [prev] | [next] | [standalone]

#15665

Stefan Weiss wrote:

> On 2012-09-01 00:56, Gene Wirchenko wrote:
>>      I will be passing back long result strings to my Web pages. These
>> strings have to be parsed into error codes and form field contents.
>> What I am working with looks like
>>           <fieldname>:<value length>:<value>\n
>> The value is encodeURIComponent()ed.
> 
> From your other posts, it appears that you're in control of both backend
> and client code. If that's the case, you may want to consider one of the
> many standardized data transfer formats.
> JSON would be the obvious choice, as it's trivially easy to use for a
> JavaScript client, and it's well supported in every major server-side
> language. Others possible choices include XML (also well supported by
> JS) […]

In contrast to built-in JSON support from ECMAScript (ECMA-262) Edition 5 
forward [0], ECMAScript and its conforming implementations have no native 
support for XML.

However, many more recent host environments provide features to support XML 
with ECMAScript binding that are standardized or in the standardization 
process, thus host objects such as DOMParser [1] and XMLSerializer [2], and 
of course XMLHttpRequest (which has a responseXML property to implement 
refer to an object implementing the Document interface if the Content-Type 
fits) [3].

There have been implementations of ECMAScript for XML (E4X, ECMA-357) in 
Mozilla, thus Mozilla-based browsers, but development of that and support of 
E4X has been discontinued there, unfortunately.  Firefox 10 and later do not 
support E4X syntax and objects in ES5 strict mode.  E4X support will likely 
be disabled by default per Firefox 17. [4]  E4X support today can still be 
found in the older Rhino 1.7 implementation, for example.  The ECMAScript 
Support Matrix [5] already contains one test case for the for-each statement 
of E4X.  As time permits, there are going to be more E4X-related test cases 
there.


PointedEars
___________
[0] <http://ecma-international.org/ecma-262/5.1/#sec-5.1.5>
[1] <https://developer.mozilla.org/en-
US/docs/DOM/DOMParser?redirectlocale=en-US&redirectslug=DOMParser>
[2] <https://developer.mozilla.org/en-US/docs/XMLSerializer>
[3] <https://developer.mozilla.org/en-
US/docs/DOM/XMLHttpRequest?redirectlocale=en-US&redirectslug=XMLHttpRequest>
[4] <http://en.wikipedia.org/wiki/E4X> pp.
[5] <http://PointedEars.de/es-matrix/>
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#15670

On Mon, 03 Sep 2012 19:29:38 +0200, Stefan Weiss
<krewecherl@gmail.com> wrote:

>On 2012-09-01 00:56, Gene Wirchenko wrote:
>>      I will be passing back long result strings to my Web pages. These
>> strings have to be parsed into error codes and form field contents.
>> What I am working with looks like
>>           <fieldname>:<value length>:<value>\n
>> The value is encodeURIComponent()ed.
>
>From your other posts, it appears that you're in control of both backend
>and client code. If that's the case, you may want to consider one of the
>many standardized data transfer formats.

     I am.

     There is the issue of enough information to use them.  I have not
done well trying to find that.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15672

On 2012-09-03 23:27, Gene Wirchenko wrote:
> On Mon, 03 Sep 2012 19:29:38 +0200, Stefan Weiss <krewecherl@gmail.com> wrote:
> > From your other posts, it appears that you're in control of both backend
> > and client code. If that's the case, you may want to consider one of the
> > many standardized data transfer formats.
> 
>      I am.

Then I would recommed looking at JSON first. If you know ECMAScript
object and array literals, you know 95% of JSON already. There are some
additional syntactic restrictions, but since you're using native/library
methods on both ends, you don't have to worry about that.

In the simplest case, server-to-client communication can look like this:

-- server (using Perl as example) --
   my $data = {
      str => "foo",
      arr => [2, 4, 6],
      nested => {
         bar => {
            value => "baz",
         }
      },
   };
   print encode_json $data;

-- client --
   var data = JSON.parse(xhr.responseText);
   console.log(data.nested.bar.value);

If your target clients can't be guaranteed to have native support for
JSON, you'll want to include a JS library as a fallback. I use a
minified version of the json2.js script by Douglas Crockford:

  https://github.com/douglascrockford/JSON-js/blob/master/json2.js

Further information:

  Gentle introduction (usual wiki caveats apply)
  http://en.wikipedia.org/wiki/JSON

  Author's site (with numerous links and some diagrams)
  http://www.json.org/

  The standard
  http://www.ietf.org/rfc/rfc4627.txt

>      There is the issue of enough information to use them.  I have not
> done well trying to find that.

With all due respect, I find it hard to believe that you had trouble
finding "enough information" about XML or JSON. Did you even try?


- stefan

[toc] | [prev] | [next] | [standalone]

#15675

On Tue, 04 Sep 2012 00:48:21 +0200, Stefan Weiss
<krewecherl@gmail.com> wrote:

>On 2012-09-03 23:27, Gene Wirchenko wrote:
>> On Mon, 03 Sep 2012 19:29:38 +0200, Stefan Weiss <krewecherl@gmail.com> wrote:
>> > From your other posts, it appears that you're in control of both backend
>> > and client code. If that's the case, you may want to consider one of the
>> > many standardized data transfer formats.
>> 
>>      I am.
>
>Then I would recommed looking at JSON first. If you know ECMAScript
>object and array literals, you know 95% of JSON already. There are some
>additional syntactic restrictions, but since you're using native/library
>methods on both ends, you don't have to worry about that.

[snip]

     I will have a look at the links.

>>      There is the issue of enough information to use them.  I have not
>> done well trying to find that.
>
>With all due respect, I find it hard to believe that you had trouble
>finding "enough information" about XML or JSON. Did you even try?

     Yes.  This applies to the Web in general as well as USENET:
"Usenet is like a herd of performing elephants with diarrhea. Massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it." -- Gene
Spafford

     It is not sufficient that the information be there.  It must be
in a form that I can start with.  Otherwise, it is just a flood.

     Armed with your links, I will see what I can do.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15686

In article <k23c3l$ldn$1@news.albasani.net>,
 Stefan Weiss <krewecherl@gmail.com> wrote:

> On 2012-09-03 23:27, Gene Wirchenko wrote:
> > On Mon, 03 Sep 2012 19:29:38 +0200, Stefan Weiss <krewecherl@gmail.com> 
> > wrote:
> > > From your other posts, it appears that you're in control of both backend
> > > and client code. If that's the case, you may want to consider one of the
> > > many standardized data transfer formats.
> > 
> >      I am.
> 
> Then I would recommed looking at JSON first. If you know ECMAScript
> object and array literals, you know 95% of JSON already. There are some
> additional syntactic restrictions, but since you're using native/library
> methods on both ends, you don't have to worry about that.
> 
> In the simplest case, server-to-client communication can look like this:
> 
> -- server (using Perl as example) --
>    my $data = {
>       str => "foo",
>       arr => [2, 4, 6],
>       nested => {
>          bar => {
>             value => "baz",
>          }
>       },
>    };
>    print encode_json $data;
> 
> -- client --
>    var data = JSON.parse(xhr.responseText);
>    console.log(data.nested.bar.value);
> 
> If your target clients can't be guaranteed to have native support for
> JSON, you'll want to include a JS library as a fallback. I use a
> minified version of the json2.js script by Douglas Crockford:
> 
>   https://github.com/douglascrockford/JSON-js/blob/master/json2.js
> 
> Further information:
> 
>   Gentle introduction (usual wiki caveats apply)
>   http://en.wikipedia.org/wiki/JSON
> 
>   Author's site (with numerous links and some diagrams)
>   http://www.json.org/
> 
>   The standard
>   http://www.ietf.org/rfc/rfc4627.txt
> 
> >      There is the issue of enough information to use them.  I have not
> > done well trying to find that.
> 
> With all due respect, I find it hard to believe that you had trouble
> finding "enough information" about XML or JSON. Did you even try?

Why fiddle about with this when you can structure the data using simple 
delimiters as the OP has been suggesting. I use hex 0, 1, and 2 as 
delimiters which you can make e.g. as follows:

  var  delim0 = String.fromCharCode(0);
  var  delim1 = String.fromCharCode(1);
  var  delim2 = String.fromCharCode(2);

and then it is simplicity itself to take the results back from your ajax 
call and use e.g.:

  var  items = results.split (delim0);

to give you an array of items, any of which can then be further split:

  var  subItems = items[0].split (delim1);

and so on.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#15687

On Tue, 04 Sep 2012 10:06:57 +0100, Tim Streater wrote:

>Why fiddle about with this when you can structure the data using simple 
>delimiters as the OP has been suggesting. I use hex 0, 1, and 2 as 
>delimiters which you can make e.g. as follows: [snip]

Or just use the very ordinary HTTP post or get conventions to pass data
to the server. All they need is either:

* let a form post or get the data in the fields, browser will handle it
* use encodeURIComponent from JS to create a string of parameters to
pass to the server

There are various conventions at the server side to deal with more
complex data sets than simple key:value sets, e.g. Classic ASP can
handle arrays simplistically, and PHP can handle nested arrays if the
fields have names that reflect array nesting.

IMHO, the only reason to use anything other than CGI parameter
conventions is when you want to pass more complex data to the server,
e.g. objects with multiple complex members using JSON or similar. SOAP
et al aside...
-- 
Ross McKay, Toronto, NSW Australia
"It doesn't matter if the Rock wants to go get diamond rings or not!"
- The Rock

[toc] | [prev] | [next] | [standalone]

#15691

On Tue, 04 Sep 2012 10:06:57 +0100, Tim Streater
<timstreater@greenbee.net> wrote:

>In article <k23c3l$ldn$1@news.albasani.net>,
> Stefan Weiss <krewecherl@gmail.com> wrote:

[snip]

>> With all due respect, I find it hard to believe that you had trouble
>> finding "enough information" about XML or JSON. Did you even try?
>
>Why fiddle about with this when you can structure the data using simple 
>delimiters as the OP has been suggesting. I use hex 0, 1, and 2 as 
>delimiters which you can make e.g. as follows:

     I have been wondering about this.  I did look at the JSON links,
but what I saw handles only the syntax.  That is the easy part.  The
difficult part is tying it to semantics.  I am probably going to go
with the delimited strings.  I have code that I understand and that
works.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web