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.

I should say that im not the kind of guy that this book is targeted at, but I ended up enjoying it anyway. I prefer a little more explanation in my books instead of the example driven cookbook style, but I gave it a read through because Jorge is an awesome guy, and it’s Ext JS related, so I cant resist – im an Ext JS addict.

The Author

I was surprised when I initially found out that this book was being put together, mostly because it was being written by a person I had never heard of. The author, Jorge Ramon at the time of starting this book had not a single post on the ExtJS forums, which is where most people head when they need to figure something out, or when they have something to share. This fact alone is a great testament to the authors intelligence and the quality of the documentation and examples that are provided with Ext JS.

Aside from the occasional quirk in the book, Jorge has done an amazing job putting together a quality product that will no doubt be useful to everyone. There can be slight grammatical problems in the text, such as incorrect tenses, and odd sentence structure, but like I mentioned earlier, the book is sparse on text.

The Approach

The cookbook style of book has a unique format where you have each example broken down into ‘what’, ‘how’, ‘why’ and ‘more’.

For Example:

• Subject (what) – short explanation of what is to be done.
• How to do it… – actual code with minimal explanation.
• How it works… – short explanation of what happened.
• There’s more… (optional) – other related uses or features.
• See also… (optional) – related sections within the book.

If you read anything, it should be the “How it works” sections, which have brief explanation of the example. The “Subject” section in big black headings is also quite useful to read before looking at the code. I would suggest ignoring the “See also…” sections while reading through, as they seem to just be used for looking up related tasks, though I found them quite unhelpful for even that.

The Recipe Code

In general, the code examples are of good quality, and the suggested methods and practices in the book are inline with whats recommended. There are a couple places where variables are not defined (var’d), making them inherently global, but hey, we all are guilty of this flaw. Probably the most confusing portion of this book is where the author uses the Ext.ux namespace to place application layout code, which is specific to your application, therefore not likely to be a “User Extension” which is what the Ext.ux namespace is reserved for.

The screenshots that go along with each example are excellent, and most have arrows directing you toward the change made. These changes also have a corresponding bold line in the code sample.

This book has a huge amount of XML examples, which can be a hard thing to come across in the JavaScript community since most of us despise XML and cant wait to get rid of it. For those of you that need to use XML, the Ext JS 3.0 Cookbook will no doubt be a huge resource for learning the oddities involved in using XML data with Ext JS.

Summary

Probably what you want to know is “would I buy this book” – the answer is yes. I have no doubt that this book will help anyone working on an Ext JS project.

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.

Word Paste

The most exciting change is to how the Word Paste plugin works, which now captures a paste event and can fix the Word garbage without any user interaction. The old UI has been ditched, and replaced with a single toggle button on the HtmlEditor toolbar which turns the functionality on or off. No pop-up window needed.

Form Validation

All of the forms used for inserting now validate their input before allowing the user to insert anything. When the user fills out the form invalidly, they get a squiggly red line (like that of a misspelling in Word). If they try to submit the form with the field still invalid, a “frame” animation effect brings their attention to the invalid field.

Context Activation

Two new features were added that allow the buttons to be enabled or disabled based on text selection, and what tags are present in the selected text or cursor position. This simply means, for example, that the ‘Bold’ button will be toggled if the selected text, or cursor position has a bold tag in it. To use this feature we just need to enable it.

Ext.ux.form.HtmlEditor.Bold = Ext.extend(Ext.ux.form.HtmlEditor.MidasCommand, {<br /> midasBtns: [{<br /> monitorCmdState: true,<br /> cmd: 'bold',<br /> title: 'Bold'<br /> }]<br /> });

The second part of this feature set is enabling or disabling a button on text selection, this is used in the Remove Formatting button because it would be silly to have this button enabled if no text was selected.

• enableOnSelection – set to true to enable button only when text is selected.
• disableOnSelection – set to true to disable button only when text is selected.

See how the Remove Formatting button takes advantage of this feature.

Ext.ux.form.HtmlEditor.RemoveFormat = Ext.extend(Ext.ux.form.HtmlEditor.MidasCommand, {<br /> midasBtns: ['|',{<br /> enableOnSelection: true,<br /> cmd: 'removeFormat',<br /> title: 'Remove Formatting'<br /> }]<br /> });

Overflow Text

The overflow text used when a toolbar has too many buttons to fit in the width has been added. This was overlooked on my first version of this plugin. Thanks to ‘feyyaz’ from the ExtJS forums for spotting this.

Conclusion

Hopefully these new features and fixes will prove useful to everyone, and as always, feedback is the only way this plugin set is going to get better, so keep the suggestions coming. Now its time for me to go get some breakfast and a large(ish) cup of coffee. Enjoy!

HtmlEditor Plugins Code

The Concept

If we could drag our tabular data into grids from other programs we could circumvent the need to upload a data file to a web server to be read and parsed, then spit back out to our browser in a readable format. Anyone who has ever had to parse Excel files on the server side knows how much of a pain it is, we might be lucky if we get a CSV file or some other simple format, but in the real world the end user running their spreadsheet program has no clue what simple tabular data is.

Using the same concept from Andrea’s example page, we can create a zone within the grid which will accept dragged data from a spreadsheet. The behavior that we are taking advantage of is the way in which an html textarea will accept dragged data from a spreadsheet and format it as tab delimited data.

The Plugin

My first version of the plugin is rough around the edges, but works in all browsers (minus Opera) very reliably. Being a plugin, the usage is straight forward, there are no configuration values that need to be defined at this time.

{<br /> xtype: ‘grid’,<br /> …,<br /> plugins: [Ext.ux.grid.DataDrop],<br /> …<br /> }

Check out the screencast below to see it in action – I am dragging rows of data from OpenOffice Calc directly to an ExtJS Grid.

The Code

As always, I have setup a Google code site for this. Please browse the source to get the plugin code. I don’t have an example page, but the documentation is online

Ext.ux.DataDrop.js

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.

The obvious next choice for a button was to add a character map which allows the user to insert special characters.

How it Works

The character map is just a DataView in a window which allows selection of each item. By double clicking on an item, a single character can be inserted or we can select a single item or multiple items using the ctrl or shift keys and click the ‘Insert’ button.

Using it

Just like the other plugins in this set, it can be added to the plugins array of your HtmlEditor.

{<br /> xtype: ‘htmleditor’,<br /> …,<br /> plugins: [new Ext.ux.form.HtmlEditor.SpecialCharacters()],<br /> …<br /> }

I also created a couple of configs that allow you to specify which characters you want displayed, along with any additional characters. Both of the following configs use the numeric portion of the ASCII HTML Character Code only – for example, to use the Copyright symbol, which is &#169; we would just specify 169 in the config.

If we wanted to only display a subset of characters, we would set the value of the charRange config to an array containing the starting and ending points of the characters we wanted.

{<br /> xtype: ‘htmleditor’,<br /> …,<br /> plugins: [new Ext.ux.form.HtmlEditor.SpecialCharacters({<br /> charRange: [192,256] // Accented characters only<br /> })],<br /> …<br /> }

There is also the option to include additional characters using the specialChars config, providing an array of the characters.

{<br /> xtype: ‘htmleditor’,<br /> …,<br /> plugins: [new Ext.ux.form.HtmlEditor.SpecialCharacters({<br /> specialChars: [42,43,45,47,60,61,62] // Math operator characters<br /> })],<br /> …<br /> }

Enjoy!

As always, please enjoy this plugin and feel free to use it wherever you want. Feedback is very appreciated.

Source available on Google Code: http://code.google.com/p/ext-ux-htmleditor-plugins/

JSMag’s blog post outlined their reasoning and intentions with this new piece:

…some of the feedback received has led us to introduce a new column this month. A recurring piece of feedback so far has been that much of the content appeared to be more advanced than many readers felt they could deal with. To that end, we’re introducing a new writer and column to our line up – Shea Frederick.

JSMag Editor

My first piece went out in the July issue of JSMag, and other than complaints from non Steelers fans (you know who you are) I was very happy with the resulting article.

Shea will be covering topics of interest to developers new to JavaScript, and perhaps even new to programming in general. His first piece this month is “Choosing a JavaScript Library” which can help someone new to the JavaScript scene understand the various options and make an informed decision.

JSMag Editor

Looking forward to increasing JavaScript’s stranglehold on the world!! muhahaha!!! (evil laugh)

ExtJS Themes

Ive been playing with ExtJS themes lately, and im having a blast creating some very fancy looking stuff. It really is amazing how quickly you can make ExtJS widgets not look like ExtJS widgets anymore. Goodbye default theme.

Keep an eye out here for stuff to do with creating themes for ExtJS, you will not be disappointed.

JavaScript User Group

The Baltimore/DC area is a hotbed of IT work. A good portion of the work here is web related, and a chunk of that of course is JavaScript related, so for the past six months I have been hosting a JavaScript meetup group in Columbia, MD (halfway between Baltimore and the District). I have throughly enjoyed meeting people in my field, and discussing various things which are most often, but not always related to JavaScript.

Our next meetup on August 4th has a local JavaScript guru Lokesh Dhakar giving us his insights into user interaction. Please come out and join us if your in the area, we always have a great mix of local badasses and newbies show up. A few local business pitch in to make this happen every month, OmniTI provides our meeting space, and Mind Over Machines keeps our bellies full of pizza – thanks goes out to both of them.