Archive for April, 2009

DrawIt 3.7.7 is Out

Friday, April 24th, 2009

DrawIt.jpg

I noticed this morning that DrawIt has released an update to 3.7.7 with a few interesting fixes:

  • Fixed a bug that crashed DrawIt when opening a contextual menu
  • Fixed a bug that crashed DrawIt when vectorizing a text layer that contains multiple colors

Interestingly, they anticipated a problem in the auto-updating, and so advised that if you had a problem, go to the web site and download a new copy. I had the problem - an invalid update signature, and did the manual update. Worked like a charm.

Coda 1.6.4 is Out

Friday, April 24th, 2009

Coda.jpg

I noticed this morning that there was a new version of Coda released a few days ago. The release notes say that there are a few things fixed - including a little better support for Git, which is very nice. Also, there's better syntax highlighting for regexo in Javascript, which is nice, now that I'm getting hip deep into Javascript.

In general, it'd be nice if they also added Tomcat support, but I understand that's not their target audience, and I'm OK with that. It's just such a nice tool.

Interesting Way to Print Complete JavaScript Object Heirarchy

Thursday, April 23rd, 2009

SquirrelFish.jpg

I was working with the JSON response from my servlet and needed to be able to print the complete structure of a JavaScript object. I wanted to make sure that I was evaluating what I was receiving from the servlet properly. Well... there isn't something that's a part of JavaScript natively, but you can do something simple and you'll get something pretty close:

  var data = eval('(' + xhr.responseText + ')');
  var guts = '';
  for (var key in data) {
    guts += key + ' : ' + data[key] + '\n';
  }

and you get the keys and values for those keys. You aren't not going to get a complete recursive output, but if you wanted to, it's easy to imagine making a print function and you're good to go.

Just a neat little trick.

iTerm 0.9.6.20090415 is Out

Thursday, April 23rd, 2009

iTerm.jpg

OK, once again, we have an update from the iTerm group - this one appears to have been release on 4/15 and I just missed it. Fair enough. It's update says:

  • Fixed clipping bottom of fonts that are not Monaco (#2735995)
  • Smart window placement remembers initial window (#2736180)
  • Windows will no longer be placed under the dock (#2740187)
  • Fixed default background colour being drawn over background image
  • Fixed a bug when pasting more than 1024 characters of text
  • Fix overwriting of static window/bookmark titles (#2744363)
  • Revert to old force screen update behaviour for 10.4 (#2738986)
  • Rewrote large parts of PTYTask

all of which aren't a big deal to me, but nice to see movement is being made. My remaining issue is the lack of "Workspace" support where Terminal.app has it. If it weren't for that, I'd be able to switch back to iTerm. Because I sure do like the absence of the scrollbars on the windows.

UPDATE: I decided to send in a feature request about the 'workspaces' feature. I don't have high hopes for this as it's probably not what they are interested in adding, but you never know. No harm in asking.

Interesting Issue with eval() and JavaScript JSON

Thursday, April 23rd, 2009

SquirrelFish.jpg

I was enhancing my web app today based on a request that someone voiced about making it easier to have a user see everything all the time. Face it, there are a good chunk of users that are in the Risk Management group that are going to need to see everything all the time. If I made a permissioning scheme based on an enumerated list, then when I added a new portfolio, I'd have to update these users. Sort of a hassle.

So the request was to have a wildcard for the portfolio list, and when a user had this, they would be able to see all portfolios regardless of how many there were. It's a good idea, I just hadn't thought of it.

But that's not the issue.

What I realized was that there were likely going to be a lot more changes to the permissioning scheme, and in that case, my semi-colon-delimited list of values was not going to do. What I needed was to be able to pass in a fully created JavaScript object and then let the page be able to interrogate it as necessary.

For example, if my validation applet was given a parameter out of json then it might return the following JSON output:

  { username: 'beatyr',
    page: 'PnLTool',
    approved: true,
    portfolios: ['Indexes', 'Nasdaq'] }

then when parsed, I should be able to say things like:

  if (!userInfo.approved) {
  }

Nice.

All this seems well and good, and I should be able to simply say:

  var userInfo = eval(xhr.responseText);

but that won't work. Why? The fact lies in the interpretation of the initial '{' in the string value. The parser in eval() thinks it's the start of a block of code, not a JSON value, so you have to force eval() to get into object evaluation mode by wrapping the JSON in '()'. Like:

  var userInfo = eval('(' + xhr.responseText + ')');

When you put this into the script, it works like a charm. Perfectly understandable from the point of eval(), but a little tricky if you forget about it.

Adding User Permissioning with AJAX

Wednesday, April 22nd, 2009

AJAX.jpg

I got a request for my web app to add in user-based permissioning. Basically, the management wanted to restrict the data any one person in the Shop might see based on their login name. Since I'd already done the user authentication with a signed Java applet, it seemed like a natural extension to add in the portfolios that the individual user could see. I simply change the JavaScript code to parse the response and then went back to the java servlet and added in the database lookup of a new column of data from the database table with the list of usernames.

I decided that it was easiest, for now, to just have a semi-colon-separated list of values, the first would be the YES or NO of the approval, and if YES, then the remainder would be the names of the allowed portfolios for this user. This was taken straight out of the database column.

Like I said, simple.

As I get more requests, I'll probably try to make it JSON and have that allow for the map-like capabilities of the basic JavaScript object. At that time, I'll move to returning JavaScript and then running eval(xhr.responseTest) in the return method. That will make it easier to extend in the future. The only wrinkle is that I'll have to assume that there's a standard variable that the response is coded to, but that's not horrible.

When I got the servlet working, and the simple parsing of the results, I then set about to allow the user to see only that portion of the data that was contained in the portfolio list I'd just parsed. This, as it turns out, was pretty easy.

The first thing I did was to get rid of the repetition in the HTML and JavaScript for all the individual portfolios. There were check boxes, checks on the data, etc. All those needed to be automated and made expandable simply. When I looked at the code, it was pretty simple. Leave all the checkboxes as-is, and create a simple JavaScript array of the names of the portfolios. Then, in the initialChecks() call, use document.getElementById() where the id was the name of the portfolio. Simple.

The tougher part was making the checkboxes disappear when the user shouldn't be able to see their data. The answer was really rather simple: make a div that surrounds the checkbox and name it "div_Portfolio". That way I can make an array of them and get their references by again using document.getElementById('div_' + portfolio). Then, I can make them invisible by:

  // get all the references of the checkboxes and enclosing divs
  var portfolioChecks = [];
  var portfolioDivs = [];
  for (var i = 0; i < portfolioNames.length; ++i) {
    portfolioChecks[i] = document.getElementById(portfolioNames[i]);
    portfolioDivs[i] = document.getElementById('div_' + portfolioNames[i]);
  }
 
  // ...get the list of the available portfolios
 
  // remove the portfolios that the user can't see
  for (var i = 0; i < portfolioNames.length; ++i) {
    if (response.indexOf(portfolioNames[i]) < 0) {
      portfolioChecks[i].checked = false;
      portfolioDivs[i].style.display = 'none';
    }
  }

with this 'turn off, then remove' code, I was able to leave the large part of the app unchanged and it just worked. I was very pleased with the way it turned out.

Now I have something that looks good for all users, and they can see only the data the management wants them to see. Lovely.

Detecting Installed Plug-Ins in JavaScript

Wednesday, April 22nd, 2009

WebDevel.jpg

The support guys at the Shop have asked me if I could detect the presence/absence of the Flash plug-in on the allowed browsers for my web app. Currently, I check for IE and toss it out due to it's horrible JavaScript memory management. I also toss out versions of Firefox prior to 3 for the same reason. But after that, I was letting the browser deal with the existence of Flash and Java applet support. This was a mistake, as a lot of the folks didn't have these and it made for a bad user experience.

So I set about getting the detection code working. It turns out that it's really pretty easy to do because it's all pretty much there in the data within the browser, you just have to know how to parse it up. The method I came up with was part of a browser detection script, as it seemed most logical that I extend that and add methods like BrowserDetect.gotFlash and BrowserDetect.gotJava.

The code looks at the MIME types for the existence of the plug-in and then looks at the list of plug-ins to see if the version matches the minimum versions for my application.

  var BrowserDetect = {
    init: function() {
      // ...checking code for browser, version, and OS
      // check for the Flash plug-in
      this.gotFlash = this.checkPlugin('application/x-shockwave-flash',
                                       'Shockwave Flash', 10);
      // check for the Java Applet plug-in
      if (this.OS == 'Windows') {
        this.gotJava = this.checkPlugin('application/x-java-applet',
                                        'Java Plug-in', 1.6);
      } else {
        this.gotJava = this.checkPlugin('application/x-java-applet',
                                        'Java(TM) Plug-in', 1.6);
      }
    },
 
    // ...more methods...
 
    checkPlugin: function(mime, descKey, minVer) {
      // assume there's no valid plug-in matching these requirements
      var flag = false;
      var plugin = (navigator.mimeTypes && navigator.mimeTypes[mime]) ?
                   navigator.mimeTypes[mime].enabledPlugin : 0;
      if (plugin) {
        var cnt = navigator.plugins.length;
        for (var p = 0; p < cnt; ++p) {
          if (navigator.plugins[p].description.indexOf(descKey) >= 0) {
            var words = navigator.plugins[p].description.split(' ');
            for (var i = 0; i < words.length; ++i) {
              if (isNaN(parseFloat(words[i])))
                continue;
              var pluginVersion = parseFloat(words[i]);
            }
            flag = (pluginVersion >= minVer);
            // no need to check any further
            break;
          }
        }
      }
      return flag;
    },
 
    // ...more methods...
  };
  // initialize this guy so we can be ready to read all the values
  BrowserDetect.init();

With this code, I'm able to use the BrowserDetect.gotFlash call to put out a little notice about downloading the latest Flash plug-in - which is great because I'm not only detecting the existence, I'm also checking the version. This has proven to be a major hassle with Flash as the Google Visualization widget appears to work, but there are subtle things that make it seem broken. It's always been the version of Flash being less than 9. With version 10, we're good to go. That's a load off.

In general, I can see all these AJAX frameworks popping up. If I had known of one that had all this built-in, it'd be really nice. As it's already built, I'll look after-the-fact and if I run across something, I'll look at using it. But I can see why folks write these frameworks, and then use them over and over again.

Great code.

Firefox 3.0.9 is Out

Wednesday, April 22nd, 2009

Firefox.jpg

Once again, we have a 'security and stability' update from the Mozilla crew for Firefox. This time, it's an update to 3.0.9. It's not bad to update my Mac, but at work, on linux, it's a pain as it's an RPM and not allowed to auto-update.

Still... it'd be great for them to get a better JavaScript engine into their code so I can use it freely without crashing on my web app. They will... eventually.

Google Labs Releases Open Source 3D Viewer – O3D

Wednesday, April 22nd, 2009

google-labs-logo.gif

This morning I read about something new out of Google Labs - an Open Source 3D viewer for the browser call O3D. The Mac plugin is at version 0.1.34.2 and while it's still a little rough around the edges, it's got something there that is worth looking into. VRML just hasn't really taken off, and I thought that was going to be a beautiful solution for complex visualizations. It just never found critical mass.

I'm looking at O3D and hoping that with the Google backing, it's going to have a lot better chance of being the web standard for complex, 3D visualizations. I'm not looking for a game engine, or a general drawing package - both those exist built on OpenGL and other technologies. No, I'm looking for the tool to easily represent 3D spaces (real and imagined) so that, for example, the output of a 2D solid-state simulator can be visualized from many angles, etc., using 3D and color. It's a powerful idea.

So I got O3D for my Mac, and we'll see how it evolves. Like I said, it's got a long way to go, but I'm hoping it makes it.

Exciting How Easy AJAX Really is to Work With

Tuesday, April 21st, 2009

WebDevel.jpg

I was working on my web app and I needed to have a simple AJAX call to a servlet to hit the back-end database and verify that the provided username was in a table of authorized users for this app. This wasn't going to be using the Google API, so I had to decide if I wanted to code it up on my own, or use one of the AJAX Frameworks. I looked at the code if I rolled it myself, and decided that it was far easier if I did it myself - considering that I did not have to support IE, so I did.

The result was amazingly simple:

  var username = document.bridgeApplet.getUsername();
  var xhr = new XMLHttpRequest();
  xhr.open("GET", "validate?" + escape(username) + "&page=PnLTool");
  xhr.onreadystatechange = function() {
    // if we're not yet done, skip doing anything
    if (xhr.readyState != 4) {
      return;
    }
    // ...otherwise, look at the response for what I need
    if (xhr.responseText != 'YES') {
      // we can't allow unauthorized access
      var tag = document.getElementById('chart_div');
      tag.innerHTML = '<br/><br/><br/><p class="header">'
            + 'Unknown User</p><br/>'
            + '<p class="reason">The user "' + username + '" is not registered '
            + 'on this application. Please contact the Risk Analytics Team '
            + 'about adding your username to the list of known users.</p>'
            + '<p class="reason">Response: ' + xhr.responseText + '</p>';
    } else {
      // this user was valid, so finish the initialization
      initialize();
    }
  }
  xhr.send(null);

in this little bit, I can issue the URL, track it's progress, and then decode the answer. It's absolutely the most elegant solution I've seen in ages. I'm getting hooked on the AJAX way of doing things and while I wasn't a big fan of servlets, I'm getting there as they are a wonderful way to get into the back-end without having an enormous overhead, and subclassing really works there. Have a nice servlet that does all the database work, and subclass a bunch of servlets off that.

I have to admit, this is changing the way I look at web site building. It's also a lot more fun than the old way.