Namespace Collisions, NS_ERROR_XPC_CANT_CONVERT_WN_TO_FUN and GWT

So, the abstraction layer provided by GWT just leaked–well, more of a flood than a leak.

I am working on a site that is pulling in an html fragment which included some javascript code via an XML HttpRequest.  This new code will make paging the results of a search quicker, hopefully leading to happier users.  For reasons too obscure to go into, I was creating a variable named ‘r1’ which I was then adding to the DOM.  The name was completely arbitrary, and was due to laziness (hey, why type 3 characters when you can type 2?).

Fast forward to today, when we’re getting ready to launch the update.  Occasionally, but not often, code that GWT was executing was throwing an exception.  One of the other developers found it because some functionality was disabled.  Here’s what that exception looked like:

exception: (NS_ERROR_XPC_CANT_CONVERT_WN_TO_FUN): Cannot convert WrappedNative to function
QueryInterface: function QueryInterface() {
[native code]
}
result: 2153185293
filename: http://stageserver/gwt/2B17113CD349EDFD95DC846F38AB0857.cache.html
lineNumber: 4268
columnNumber: 0
inner: null
data: null
initialize: function initialize() {
[native code]
}

Now, usually, the first thing I do when I see an exception is to recompile the GWT with -style DETAILED instead of -style OBF and see where the error occurs.  However, when I did that, I didn’t see the error message any more.

OK, I added more debugging.  If I added a certain number of alert statements, the error message was nowhere to be found.  OK, go back to the previous code.  Try different pages, different browsers.  Sometimes the exception reared its head, other times it didn’t.  It appeared on some browsers and not others. Sprinkled alerts throughout the code, found the exact line where the exception was being thrown.  All that line did was create a click listener.

Nothing really clear on google; however, this post was useful in pointing to the error message being a collision between a function name and a DOM element.  Searching the GWT google group was not helpful.   I tried using the Firebug debugger, but on obfuscated source, it was not helpful to me.

These kind of bugs make me want to tear out my hair.  Hardly reproducible bugs are no fun. However, I finally found the issue (if I hadn’t, I’d still be working and wouldn’t be posting, that’s for sure).

How I finally solved it:  I was getting a line number.  I finally edited the generated GWT .cache.html file and added some newlines.  This would let me find out exactly which function was really causing the issue.

And, lo and behold, the problematic function was named ‘r1’.

Changing the name of the DOM element fixed this issue. Beware short named javascript DOM elements when working with GWT.

Hope this helps you.


GWT Marketplace

Two years ago, I surveyed the state of GWT widgets.  It was pretty fragmented and a bit confusing.  While I haven’t been paying very close attention, I don’t think things have changed much.

I was browsing around the GWT google group, and found this interesting announcement.

I’m a huge fan of GWT and the only problem I have with it is not really a problem with GWT but with the fact that there isn’t a centralized place for registering component and associated tools AFAIK.  I have created an application to do this which is available at http://gwtmarketplace.appspot.com/

I visited the marketplace and while it is currently in its infancy, it could be very useful. If you have GWT code that you want to share with the world, consider registering it. I added gwt-crypto, which I help maintain.


My experience implementing GWO for a non profit, part 2

I was finally able to get access to the wild.org server via FTP (previous cliffhanger resolved).  After cautioning me to be very careful (“please proceed with caution and help keep wild.org from blowing up…warnings from my IT guy”) Emily handed over FTP access.

I proceeded very carefully.

We had already had discussions about what we were going to vary to test the donation button.  Pictures, location of button, text of button, and text around button were the major variables.  One of the hard things about GWO is deciding what to test–the possibilities are infinite.  Even with our handful of variables, we ended up dropping some options and still have 100 variations to test!

Actually installing GWO was pretty easy.  The only wrinkle was the fact that the goal was a click of a button and not another page.  This post was helpful.  One item that that post didn’t cover was validation–GWO doesn’t let you start an experiment if the program can’t verify that the script tags are installed correctly.  Since we were doing a non standard install, I gimmicked up a goal page for validation, then added the goal tracking to the onclick event as described in the post.

So, the experiment is currently running on The WILD Foundation homepage.  It’s been running for about a week, and has only 1 non test conversion.  I worry that we are not testing big enough changes (a donate lightbox, rework the entire front page), but I think it makes sense to let the test run for a few weeks and see what kind of data we get.


Musings on php development as a career path

I was at a TedXBoulder preparty last night.  Ran into some really interesting folks–the usual tech folks, but also Charles, a high flying audio engineer (we’re talking Wembley stadium), Emily, a money manager bizdev lady ($30 million, minimum, please) and Donna, an engineer on leave from a big aerospace firm who is interested in entrepreneurialism.  Really looking forward to the talks on Saturday (tickets apparently still available).  I also ran into an old friend, roommate and colleague.

We chatted about a wide variety of topics, but one stuck out in my mind.  His brother is getting back into software development, and is starting out doing a lot of php.  Fair enough–it’s a great language, I’ve done a fair bit of it, and one can write good, maintainable, fase code with it.  But last night, we agreed that if you don’t want to be competing against, how do I say this politely, the lowest common denominator, it is wise to develop your software dev skills elsewhere, into one of three paths.  I thought it’d make a good blog post.  As I see it, the three options are

  • a compiled language–C#, Java, c, erlang: these tend to be used by large companies
  • a sexy dynamic language–Ruby, javascript (especially server side), groovy, python, clojure, lisp: my feeling is that these are more used by startups
  • particular packages in php–magento, drupal: these are often more configuration than coding, but can be customized to produce astonishingly powerful applications

The end goal, to be clear, is not to avoid php, but just to avoid competing against developers who are likely to undercut you.  For example, I knew of someone, in the US, who was doing contract php work for $18/hr a few years ago.  I just don’t think that’s someone with whom you want to be competing for business (I certainly don’t!).  Following one of the above career development paths will help you avoid that.  I personally have followed the first and third paths, with some dabbling in the second.



© Moore Consulting, 2003-2017 +