Call & Scope

So as it turns out, the simple answer is no. The each method uses the call method of the Function constructor to apply scope to the function executed on each pass of the loop. When no scope is provided to the each method, it uses the current item as the scope – which is kinda strange, but whatever.

No Scope

Here is my smart idea – don’t use the call method if there is no scope provided. Simple, and it seems like it would help speed things up, so let’s give it a shot.

Ext.each = function(array, fn, scope){<br /> if(Ext.isEmpty(array, true)){<br /> return;<br /> }<br /> if(!Ext.isIterable(array) || Ext.isPrimitive(array)){<br /> array = [array];<br /> }<br /> for(var i = 0, len = array.length; i < len; i++){<br /> if((scope) ? fn.call(scope, array[i], i, array) : fn(array[i], i, array) === false){<br /> return i;<br /> }<br /> }<br /> };

The basic change here is on line 9 where I check to see if scope was passed in, and decide to either call the function to apply scope or just execute it directly.

// original<br /> fn.call(scope || array[i], array[i], i, array)<br /> // my version<br /> (scope) ? fn.call(scope, array[i], i, array) : fn(array[i], i, array)

Using my current web app as the guinea pig, this version ran between 5-18% faster in Firefox than it’s non scope checking predecessor. Internet Explorer’s results were so far scattered across the board that I could not draw a conclusion – in some tests 50% faster, in others 350% slower. As usual, IE left me confused, so im just going to ignore that for now.

Can We Do Better?

The next thing that caught my eye was the fact that when a single item is passed into the each method, it is shoved into an array and sent through the for loop – this seemed like a place for improvement.

Ext.each = function(array, fn, scope){<br /> if(Ext.isEmpty(array, true)){<br /> return;<br /> }<br /> if (!Ext.isIterable(array) || Ext.isPrimitive(array)) {<br /> if ((scope) ? fn.call(scope, array, 0, array) : fn(array, 0, array) === false) {<br /> return 0;<br /> }<br /> } else {<br /> for (var i = 0, len = array.length; i < len; i++) {<br /> if ((scope) ? fn.call(scope, array[i], i, array) : fn(array[i], i, array) === false) {<br /> return i;<br /> }<br /> }<br /> }<br /> };

In this case I have simply taken any single non array item that is passed in and executed the function immediately, bypassing the for loop. Results of this change were not noticeable, and matched almost identically with my previous version. Upon closer inspection, it turns out that this case is never reached, in other words, there is always an array passed in. Go figure.

Summary

The moral of the story here is to think simple when trying to optimize code, otherwise we end up going to far into optimizing and actually make the code more complex and likely slower, but this does not mean that the code with the fewest characters or lines will be the quickest. Experimenting is fun, so I would encourage everyone to try things like this just to see how they work and in turn gain a better understanding of how the methods you use every day actually work. Priceless.

Code for these tests can be downloaded from my Ext.ux.Misc Git repo on Github.

My next step is to test each loop “unrolling” to see what the effect is…let me know what you have tried on your own, and how it has worked out for you.

DC Meetup Videos

We held the first in a series of meetups that will happen in the DC/NoVA area last week, a sprout of our Baltimore area Meetup for our southern friends, and I have to say that it was a huge hit. The meetups are going to be managed by Pat Sheridan from Three Pillar Global, and we are hoping it will be a way to get JavaScript developers from the DC area more involved in the community. Jay was kind enough to bring video equipment and record our presentations, along with editing the videos and posting them to the intertubes.

There are some photos and other information about the event on its meetup page.

If you are in the Baltimore area and into JavaScript with a fury, you should visit our Meetup that happens the first Wednesday of each month at 6:30PM in the Beehive Baltimore. This month’s meetup has a presentation from Paul Barry about Node.js – it’s gonna be bad ass.

Speed Testing

My little addiction I like to call speed testing has rolled into full swing. Now that I have the tools in place to create and launch tests, along with run reporting on the results with ease, I can pretty much just sit down and spend 30 minutes or so to design and launch the test. I have two tests currently gathering data, one is testing the speed of rendering an image with and without a data URL, the other has to do with the speed of code wrapped in a try catch statement. Should be some interesting results, which I will be posting a summary on soon. My first test was for JSON decoding speed, which I posted results for a couple of weeks ago.

HtmlEditor Plugins

The Ext JS team has expressed an interest in including my HtmlEditor Plugins as a UX in the SDK. This will mark the third development of mine that has become part of the Ext JS SDK download, first it was the GMapPanel UX, then the Grid Filter backend PHP code, now it seems that the Ext JS SDK will finally come with a more robust HtmlEditor example. A few updates have been committed recently that add the option to change the language in these plugins, along with some general code cleanup. Also starting to move my code over to Github as suggested by many.

Books

Soon we will have Jay Garcia’s Ext JS in Action book released in print, and the 2nd edition of Learning Ext JS should be released later this year, titled “Learning Ext JS 3.0″. Cutter, Colin and I got together to update the book, fix some errors, and add new chapters to take advantage of new features in Ext JS 3.0. It’s gonna be an awesome resource for anyone just getting started with Ext JS.

JSConf

Again, JSConf is being held in the DC area, which makes it incredibly cheap for me to attend, but this year I decided to try my hand at submitting a talk proposal. I can’t wait to find out if I will be chosen. My submission was for an introduction to rapid application prototyping using the Ext JS library. Here is my submission:

{<br /> “name”:”Shea Frederick”,<br /> “email”:”________@________.com”,<br /> “twitter”:”VinylFox”,<br /> “location”:”Baltimore, MD”,<br /> “topic_title”:”Rapid Web Application Development with Ext JS”,<br /> “topic_description”:”Discuss general principles of the Ext JS library<br /> and show how easy it can be to rapidly prototype a web application<br /> using the library.”,<br /> “claim_to_fame”:”One of the core contributors to the Ext JS library<br /> along with other Open Source JavaScript projects. Author of<br /> ‘Learning Ext JS’ published in December 2008. Observed ‘Talk Like<br /> a Pirate Day’. Maintain a Blog of JavaScript fun at<br /> http://www.vinylfox.com”<br /> }

Did I mention that all submissions have to be in the form of valid JSON? Yeah, geeky, but good – very good. With any luck, I will find out later this week if ive been accepted.

Now that our new buddy Karl has been properly introduced, lets move on to the boring stuff. I have been trying to optimize decoding of a large chunk of JSON data by testing decoding speeds between the three main methods of decoding JSON and how that applied to the type of data that was being decoded, along with the environment, ie: the browser. My data has been gathering for over a month now, and has run on 3500 unique clients, so I feel like I can come to a decent conclusion.

The Decoded Data

I figured for my testing purposes that there were five main types of data that would be commonly decoded.

• Empty Array
• Empty Object
• Array Data Only
• Object Data Only
• Mixed Array and Object Data

The Decoding Methods

Generally speaking, you will find three methods of decoding JSON used in the wild, though eval is by far the most common. I am not using any decoding/encoding libraries because I don’t want to taint the results with any browser targeted workarounds that might be present in them, I just want to know what the actual browser does.

o = eval( “(” + testData + “)” );

eval – This is the old standard for decoding JSON, which is considered dangerous to use because of its ability to create functions.

o = JSON.parse( testData );

native – The latest and greatest method of decoding JSON, recent browsers include this built in feature. The ‘safe’ way to decode data.

o = new Function( “return ” + testData )();

new function – This method is essentially the same as eval, but uses the evaluating mechanism of the Function constructor to decode data.

In The Wild

I wanted my testing to represent actual usage in the wild, so I used a tool that allowed my tests to run in the browsers of unsuspecting internet surfers. So the results I have can be considered an accurate depiction of what will actually be encountered on the intertubes. If you’re creating intranet sites targeted to a particular browser, then these results should be interpreted differently. Any browser that cannot handle all three methods of decoding JSON was not included in the test, so you IE6/7 guys are out of luck. Also, any browser that has an active console (console object present) was excluded.

The Outcome

The results are quite interesting, and confusing in some cases. Im guessing there is room for some browsers to optimize their JSON decoding routines here. This first chart shows results grouped by browser make.

This is all good and fine if your a browser vendor and want to know how you’re browser stacks up against others, but in web development we don’t have the option of picking our clients browser. What we want to see is what programming techniques we can use to take advantage of browser efficiency across the board. Which leads us to the next chart, showing results grouped by decoding method

That’s more like it, I now have a clearer idea of how the methods themselves stack up against each other, the red line indicates the average of all the data types.

The Conclusion

Even though the results seem to indicate that native JSON decoding is only mildly faster than eval, its actually a bit faster if you exclude the strange handling of empty objects in Firefox. For the purpose of choosing a method, I think we can draw the conclusion that native JSON decoding is the clear winner here, followed closely by eval, and the function constructor being a general bad idea.

Comparing the browsers for native decoding, Safari is a clear winner here, with our new buddy Chrome losing the race by quite a lot.

Quirks

By far the biggest quirk is Firefox‘s slowness in decoding an empty Object natively, which skews the results, making it appear that native JSON decoding is only mildly faster than eval.

Another interesting result was decoding using eval ran 500% slower with FireBug enabled, while native decoding suffered no degradation at all when FireBug was enabled.

Safari apparently does not handle the function constructor very efficiently.

As a general rule of thumb the straight array data decoded the slowest, so when considering system design, array data should only be used when there is a clear benefit to it.

Feedback

If there are any particular ways you would like to see the data broken out, just let me know in the comments and ill see what I can do.

At 6:30PM on 1/19/2010, Three Pillar Global will be hosting a gathering of industry leading minds in the metro DC area to discuss and share development practices, ideas, tips and tricks revolving around the Ext JS framework. There will be four presentations that are jam-packed with information that can aid to your success in developing applications with the Ext JS framework

About the presentations:

Patrick Sheridan will kick off the meeting, where he will explain how analysis-driven development can aid in the success of your application construction, reducing time from conception to production. Shea Frederick will be guiding us through advanced JavaScript debugging techniques, demonstrating some of the best tricks for the latest and greatest JavaScript development tools. Jonathan Julian is going to share and elaborate on five areas to improve your Ext JS applications, which range from defining your own components to properly overriding the framework. Lastly, Jay Garcia will discuss how to build extensible applications using a two-tiered approach with Ext JS.

Food and refreshments to be provided. We look forward to seeing you there!

About the presenters:

Pat Sheridan is a successful Ext JS developer that leverages his user experience background to accelerate successful development with RIA JavaScript frameworks, including Ext JS. With success stories such as the complete rewrite of the U.S. Treasury’s Pay.gov website and the production of four large RIA applications for the Financial Regulatory Authority (FINRA), he continues to dominate this space with a progressive thought process that enhances the development and user experience alike. He demonstrated his UX leadership with the release of an Ext JS 2.0 OmniGraffle template that has garnered over 50,000 downloads world wide.

Shea Frederick is an active community member for ExtJS. His expertise is drawn from community forum participation, work with the core development team, and his own experience as the architect of several large ExtJS-based web applications. Shea is also an author for JavaScript Magazine, his own blog (http://vinylfox.com), and the Ext JS blog. He is the lead author of the Learning Ext JS book and is the organizer for the Baltimore JavaScript developers meetup group.

While not very well known in the Ext JS community, Jonathan Julian is successful independent web developer specializing in Rails and Ext JS applications with extensive experience in Java and related technologies. He occasionally blogs about software and web development at jonathanjulian.com and tweets as @jonathanjulian. He has presented at the Baltimore JavaScript developers meetup group.

Jay Garcia, author of the up and coming book, Ext JS in Action (http://extjsinaction.com/), provides daily support on the Ext JS forums as well as free extensions and widgets to the library. He is an author for JSMagazine, the Ext JS blog and his own blog at http://tdg-i.com. He’s developed enterprise-level applications using Ext JS since early 2006, when it was known as “yui-ext” and has continued to support and assist in the expansion of the product ever since.

Yeah, so what?

The problem comes when we want to mask a part of the screen, but also want the elements behind that mask to continue responding to user interaction. This behavior is counter to most native behavior. What we are left with, is having to forward mouse events through the masking layer to the layer below, an option that simply does not exist in the standard JavaScript/DOM API.

Why do this?

A plugin that I recently wrote – DataDrop - used a textarea overlaying a grid to act as the receiver of dragged data from spreadsheet type programs. One of the limitations that I was not so happy about was the fact that this overlay could only exist in the ‘empty’ area of the grid, not over rows of data, headers, toolbars, etc. otherwise it would cause all of those elements below to become unresponsive to user input. If our textarea that receives the data were positioned over the entire grid area, our GridPanel could not be controlled using the mouse anymore.

How to fix this?

This is where my friend Nige White (Animal) came in to help, it turns out that he had an idea about how to forward these mouse events using a couple of not well understood methods in the JavaScript/DOM API used for creating mouse events. Here are the steps taken:

1. The textarea (my masking element) that is positioned over the grid receives mouseover, mousemove, mousedown , mouseup and other events.
2. The top masking layer is hidden for a moment, so we can figure out what element is below the mask at the event location.
3. The event is re-fired – this is where the W3 DOM Event model and the simpler Microsoft equivalent come into play.
4. Start the process again – ready for the next event.

What’s element to fire upon?

Knowing the cursor position and event that occurred, the only obstacle now is determining what DOM element to fire the simulated event through. It turns out that finding which element is the topmost element at a certain document coordinate position is quite simple in modern browsers. The document.elementFromPoint method is supported in IE, Mozilla, Webkit and Opera.

So it is possible to capture the document coordinates of a mouse event fired on the masking element, momentarily hide that masking element, and then ask the document what is under that coordinate position before showing the mask again.

A new event can be then fired on the found element. Obviously there are some complexities such as firing mouseover and mouseout events when the found element is different from the last time, but that is the gist of the technique. To see it in action, check out the screencast or play with the live Grid DataDrop example or simple DOM element example yourself.

I have posted an override of Ext.Element that Nigel created on my Google Code site for all to enjoy, it is now a requirement for the ExtJS DataDrop plugin. A big thanks goes out to Nige (Animal) for digging into the nuts and bolts of JavaScript to find a solution to my problem.

The Next Step

Having the data that is dropped into the grid automatically insert into the grids rows at the correct position is my next task for the ever-improving DataDrop plugin. Should be fun :/

UPDATE (12-1-09): Seems that Mozilla has also noticed this issue.

this.config[col] is undefined

The autoExpandColumn feature of the ColumnModel accepts an ‘id’ as the argument, this ‘id’ needs to match the ‘id’ given to the Column configuration.

{<br /> columns: [{<br /> id: 'not_so_super_column_id', // column id defined<br /> header: 'Super Duper',<br /> dataIndex: 'superduper'<br /> }],<br /> …,<br /> autoExpandColumn: ‘super_duper_column_id’ // wrong column id used – fail!<br /> }

Another thing to keep in mind, is that while it works sometimes, the value for autoExpandColumn should NOT be a column index – the id of the column should always be used.

types[config.xtype || defaultType] is not a constructor (b[d.xtype || e] is not a constructor)

This happens when trying to instantiate (create) a component that does not exist, the most common reason is a typo or spelling error. For instance, using ‘gridpanel’ as the xtype instead of ‘grid’ – which is a mistake I make often myself. Sometimes we can forget a level of namespacing, like using Ext.FormPanel instead of the proper Ext.form.FormPanel.

{<br /> xtype: ‘formpanel’ // fail<br /> },{<br /> xtype: ‘form’ // win!<br /> }

Another one I always run into is typing ‘combobox’ instead of the correct ‘combo’ for the xtype – a list of xtypes can be found in the ExtJS documentation under Ext.Component.

this.addEvents is not a function

This is not a new problem (you like that pun?) but unfortunately the error message sends us off in the wrong direction. When this message appears it sounds like its an event related problem, but what it simply means is that we have forgotten to preface a constructor with the ‘new’ operator.

Ext.form.TextField({}); // fail<br /> new Ext.form.TextField({}); // win!

el is null

So with this one, its a little easier to figure out what went wrong just from the error message. In shorthand variable naming, a couple of letters are picked out of a longer word that phonetically make sense, and do not spell something else or sound like other commonly used words. So in this case ‘el’ is short for ELement. As the error message says ‘el is null’, which if we translate from geek speak to English it says ‘html element does not exist’.

</p> <div id="sweet_dude"></div> <p>new Ext.Button({<br /> text: ‘Clicky’,<br /> renderTo: ‘dude_sweet’ // does not match the id!<br /> });

f.convert is not a function

This one is not so common, but still happens every once and a while. It means that your data reader was trying to read the data you passed to your store with a particular data type that did not exist. Thats allot to take in, so lets take a look at this example.

var myStore = new Ext.data.ArrayStore({<br /> fields: [{<br /> name:'fullname',<br /> type:'badass'<br /> }, {<br /> name:'first',<br /> type:'string'<br /> }]<br /> });

In this example the ‘fullname’ column has a datatype of ‘badass’, which does not exist. On the flip side, the datatype for ‘first’ of ‘string’ does exist.

Summary

Now if we can just keep these in our memory, we might be able to have a productive day -or just drink more coffee and see how that pans out.