{"id":25077,"date":"2016-09-20T03:01:21","date_gmt":"2016-09-19T17:01:21","guid":{"rendered":"http:\/\/www.rjmprogramming.com.au\/ITblog\/?p=25077"},"modified":"2016-09-19T22:26:10","modified_gmt":"2016-09-19T12:26:10","slug":"parsing-url-primer-tutorial","status":"publish","type":"post","link":"https:\/\/www.rjmprogramming.com.au\/ITblog\/parsing-url-primer-tutorial\/","title":{"rendered":"Parsing Url Primer Tutorial"},"content":{"rendered":"
\"Parsing<\/a>

Parsing Url Primer Tutorial<\/p><\/div>\n

Today’s parse_url.html<\/a> HTML and Javascript web application is intended to show the power, and simplicity of use, of the Javascript function split<\/i><\/a> to parse strings that have many component elements. The example used in the web application is to parse web address URLs but this Javascript split<\/i> usage can be applied to many different and varied ways to make things happen with web client Javascript code.<\/p>\n

In the spirit of piping<\/i><\/a> with Linux or Unix (or Windows via piping in Windows Batch file scripting scenarios) we’ve talked about here a bit at this blog<\/a>, we like to think of split<\/i> as Javascript’s “relay racer” for “horizontal coding”. To us, “horizontal coding” is a style of coding where we don’t worry that a piece of code disappears off to the right of the screen, to us as much as anything, because it is far more important to us to use those “relay racer” mechanisms to have a few lines of greatly impactive codelines, rather than trying to make it all fit into a screenwidth of reading. In any case, in our increasingly mobile age, what does a “screenwidth” amount to anymore?<\/p>\n

We’d also argue that Javascript split<\/i> “relay racing” style code such as<\/b> used (to make the action property of an HTML form send the resultant GET method navigation, back to where it came from) in …<\/p>\n


\nvar formstr=\"<br><div style='width:100%;text-align:center;background-color:yellow;'><form action='\" + document.URL.split('?')[0].split('#')[0]<\/b> + \"' method='GET'><br><br><\/form><\/div><br>\";
\n<\/code><\/p>\n

… to us, is probably more self explanatory than …<\/p>\n


\nvar durlarr=document.URL.split('?');
\nvar durltwoarr=durlarr[0].split('#');
\nvar durlstr=durltwoarr[0];<\/b>
\nvar formstr=\"<br><div style='width:100%;text-align:center;background-color:yellow;'><form action='\";
\nformstr += durlstr<\/b>;
\nformstr += \"' method='GET'><br><br><\/form><\/div><br>\";
\n<\/code><\/p>\n

… because we are used to reading, and looking for more across the screen, and “relay racing” style code prepares the reader for a related more complex bit of code on which the emphasis of their concentration should fall anyway. It is for this same reasoning we love fairly complex Linux and Unix piping scenarios in (Korn) Shell code as well. Of course, this is just one opinion, and there are contrary arguments as well.<\/p>\n

So what is being “relay raced” when Javascript split<\/i> works this way? A Javascript string<\/i> is being passed in memory. In contrast it is input and output streams<\/i> normally being passed during Linux and Unix piping operations. Stream<\/i> is such an apt word for this flowing<\/i> (or “relay racing”) software coding style. It feels co-operative to work this way with tried and tested software coding components.<\/p>\n

Anyway, why don’t you try parsing some URLs with today’s parse_url.html<\/a> live run<\/a>? Or peruse this quite complex example from a recent blog posting mentioned in Spliced Audio Number Genericization Tutorial<\/a> yesterday<\/a>.<\/p>\n

If this was interesting you may be interested in this<\/a> too.<\/p>\n