FlyerTalk Forums - View Single Post - Reservation pages revamped (was: Anybody seen the new swabiz features?)

Oct 24, 2009 | 1:52 pm

#82

ftnoob

Moderator, Southwest Airlines and Choice Privileges

Join Date: Mar 2008

Location: Central Texas

Posts: 3,112

Quote:

Originally Posted by SWAVictor

I didn't say we weren't working on correcting it . . .

You probably started your reply before my edit above, which noted that I tested SWA's String.trim function and found it incorrectly returns 'dal ' (instead of 'dal') when asked to trim 'dal '. I saved and edited the javascript source file to include a correct trim function, ran it locally, and found the problem was still not solved. Being clueless about the overall structure of the flyout scripts, I had to resort to setting a breakpoint on the trim function, and then stepping out to the caller. (Clue #1: that was far more difficult than it should have been; trim was being called numerous times, even with just one letter typed into the input box.) Examining the calling function I found:

Code:

var isStationCodeOrNameMatching=function(b,a){
  return a.stationCode.indexOf(b)==0||a.stationName.trim().toUpperCase().indexOf(b)==0};

Examining the variables I saw that b contained the characters typed into the input box and a contained an object, with a.stationName being a string of the format City, ST - AAA. That made the logic error very obvious: the code should not be trimming a.stationName, it should be trimming the user input. Rewriting the above to:

Code:

var isStationCodeOrNameMatching=function(b,a) {
  b = b.trim() ;
  return a.stationCode.indexOf(b)==0||a.stationName.toUpperCase().indexOf(b)==0 ;
};

(in combination with using a corrected RegEx) fixes two problems:

the user will no longer be told 'dal ' is not valid airport, and
the user's computer will no longer have to waste time trimming predefined station name values.

A few other notes: both destination_flyouts.min.js and destination_flyouts_filter.min.js" declare the incorrect string.trim prototype function. I haven't looked into whether that duplication is necessary. Also, Firefox 3.5 provides trim as a native function. I'd be inclined to test for a null String.trim before creating my own. Something similar is pretty standard practice when declaring Array.indexOf to make up for it being missing from IE.

I realize there are much bigger problems to work on, but for a developer who knows a bit about the structure of the code and who has access to the pre-min source, crossing that bug off the list would be trivial. Once I managed to de-min the source and get past the distraction of far too many calls to trim, it took less than five minutes to identify the problem, write the fix, and confirm it worked. Crossing even small bugs off the list quickly may be wise at this stage.

Reply