Column

Maritime Law Book, Javascript, HTML Forms and the Post Method

Maritime Law Book has been re-designing its website. As of the date of writing, I hadn’t seen an announcement. It was just something I happened to notice on May 3, 2011.

The change I’m going to talk about isn’t the most obvious one to a casual observer, but it is a very welcome one. The change I particularly want to notice is that people can now create links like this one to cases reported by Maritime Law Book:

http://search.mlb.nb.ca/?IW_BATCHSIZE=20&IW_SORT=-11&IW_DATABASE=OAC&IW_FIELD_TEXT=271+O.A.C.+135+\\+MLB

The best way to cite a case is to provide a hyperlink. Because of that, the people who report cases on the web should make it as easy as possible for writers to provide links to their publications. So congratulations to Maritime Law Book! One thing hasn’t changed: the reader still has the choice between the “raw law” and the pay-per-view headnoted version.

It was possible to create hyperlinks to Maritime Law Book cases before this change, but it was way too complicated. Naturally, now that the good times have arrived, I’m going to tell you about the bad old days. I used to walk a mile through snow drifts to get to school too.

The big change from the old to the new–and I think this is a recent change–is from the POST method to the GET method. The object of both methods is to submit user data from the browser to the web site. In each case, the parameters and values making up the query are part of a message sent to a database on the web site. The POST method sends this data in the body of the message. The GET method only uses a message header. As far as I know, in the history of HTTP, both methods are equally old. For additional reading, see section 9 of RFC2616.

The truth is, I’m not absolutely sure that I couldn’t have used the GET method with Maritime Law Book at some earlier date. I have a vague recollection of having tried at various times. Unfortunately, I didn’t document those attempts. What I do know for sure is that the form tag method attributes on Maritime Law Book’s web pages recently changed from POST to GET.

Maritime Law Book’s new page is:

http://mlb.nb.ca/html/canadian-case-law-search.html

The old ones (still around at the date of writing) were:

http://www.mlb.nb.ca/cf-docs/FreeSearch.cfm (the starting point)

and

http://www.mlb.nb.ca/cf-docs/FreeSelectDB.cfm (the halfway point)

Note: Going to this page first produces an error message.

Of course, you don’t see hyperlinks to particular cases on these pages. Instead there are text boxes, check boxes, and submit buttons. As always, to understand how the pages work and what all can be done with them, one views the source code. In a nutshell, the difference between hyperlinks and submit buttons is the difference between ANCHOR tags on the one hand, and FORM and INPUT tags on the other. The METHOD attribute on the form tag tells you whether the method is POST or GET. The ACTION attribute gives you the the URI of the web page which is waiting for your queries. The names of the query parameters are indicated in the NAME attributes of the various input tags which are nested within the form tag; the TYPE attributes indicate how the parameter values will be obtained by the browser before the query is submitted. Inside and outside the form tag, there is Javascript code, primarily in order to validate user-supplied data prior to submission. The rest of the source code is mostly just for decoration.

In the new world, the ACTION on

http://mlb.nb.ca/html/canadian-case-law-search.html

is to

http://search.mlb.nb.ca/.

Simple.

In the old world, the ACTION on

http://www.mlb.nb.ca/cf-docs/FreeSearch.cfm

was to

http://www.mlb.nb.ca/cf-docs/FreeSelectDB.cfm,

from which, in turn, the ACTION was to

http://search.mlb.nb.ca/.

To the same destination, by a longer route.

Where the GET method of submitting data is available, there’s no need for a form: it can be just as simple as adding appropriate parameters and values to the URI. In the example at the top, it’s just:

IW_BATCHSIZE=20&IW_SORT=-11&IW_DATABASE=OAC
&IW_FIELD_TEXT=271+O.A.C.+135+\\+MLB

To do something that looks similar using the POST method, we need Javascript and the Document Object Model (alternatively ECMAscript and DOM). The general procedure is as follows:

1. Load a new page of our own containing a suitable HTML form and input tags.

2. Have the form submitted automatically by the browser as soon as the page has completely loaded.

It is a tenet of my religion that pop-ups are evil. Just to be ecumenical for a moment, however, I’ll add that the pop-up way of doing step one would be to create a link like this:

<a href=”#” onClick=”mlb_create()”>

where mlb_create is just a name arbitrarily chosen for a Javascript function I could write containing a window.open command and a bunch of document.write commands.

Quite apart from my religious scruples, this was not a satisfactory approach. In the first place, I would have needed to write a separate Javascript function for each citation. What a pain.

My preferred solution was to create a separate web page that could be loaded from the first. One advantage of this approach was that, whereas a page created on the fly always went into a pop-up window, a reader could use the browser to choose to load the pre-existing page into the existing tab, into a new tab, or into a new window. Much better.

The second advantage was that most of my pre-existing page was re-usable. All I needed to do was to pass the varying portions of my query over from my first page to my second page. I did this by using the query portion of the URI of my second page. When that link was clicked, the necessary information from the first page (for example, “271%20O.A.C.%20135%20\\%20MLB”) was sent to the second. The DOM window.location.search property was used by the second page to receive it.

One little bother was that percent encoding had to be used in the query portion of the URI on the first page: the <space> character had to be encoded as “%20”. Then, on the receiving end, the Javascript had to replace each occurrence of “%20” with a <space>. Fortunately, that could readily be done with replace and a regular expression: replace(/%20/g, ” “). Once this was done, the Javascript would find the appropriate input tag on the second page, and add a value attribute containing the appropriate text.

The final thing the Javascript then had to do, once all the necessary changes to the second page had been made, was to submit the form on the second page. That replaced the tab containing my second page with the appropriate Maritime Law Book page containing the response to my query.

I’ll admit to having gotten a certain satisfaction out of doing things the hard way. Congratulations, though, to Maritime Law Book on making its site so much easier to use.

Comments are closed.