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.

These Overrides are a way for us to change the way the base library works, usually because of a defect, but sometimes just because we don’t like or agree with the way something works. Here we are going to cover how to write a basic Override that ‘fixes’ or adds a feature to something in the library.

Why?

The last thing we want to do is edit any of the Ext JS distribution files, such as ext-all.js or ext-core.js, we want to instead apply our changes into the library without touching the library files directly, using the library itself to overwrite specific functions where needed. Editing the library files directly would make upgrading nearly impossible. This is where the Override method comes in to help.

Downfall

Overriding a base function causes an extra maintenance responsibility – a shift of responsibility – simple as that. Though less of a problem than say, editing the ext-all.js file. Every upgrade of the base library (Ext JS) we make requires that we re-examine all of our Overrides to make sure they still sync up with code from the base library, and that the problem were overriding has not been fixed by the Ext JS development team.

Override

Were going to start with an override that adds a feature to the library that we desperately need! Or at least that’s what our boss tells us.

We are adding an option to cascade the placement of new windows based on the position of the previous window. The reason I am adding this as an Override instead of a Plugin or Extension is because im lobbying to get it added as a feature to the library (not really) and when it gets added to the library and I upgrade, I will be able to simply remove my override and continue with life.

The goal is to end up with an no Overrides in your application, by reporting bugs and enhancements to the Ext JS team, and following through so they get fixed in the library.

The Override method of the Ext JS library will take the function(s) we pass to it and overwrite functions of the same name within the component specified. The previously defined function that were replacing are completely removed, and the new ones put in their place.

Two arguments are accepted for the Override method, the first is the class that we are overriding, and the second is an object with the methods we are overriding.

Ext.override(/*CLASS*/, /*METHODS OBJECT*/{<br /> /*METHOD NAME*/:function(){<br /> /*DO IT!*/<br /> },<br /> /*ANOTHER METHOD NAME*/:function(){<br /> /*DO IT MORE!*/<br /> }<br /> });

The Code

We start by copying the source of the original method from the Ext JS source files that come with the SDK download (located in the src folder), in this case it’s the beforeShow method of Ext.Window (in Window.js). Using the source as a starting point, we can modify the function to do what we need.

Ext.override(Ext.Window, {<br /> beforeShow : function(){<br /> delete this.el.lastXY;<br /> delete this.el.lastLT;<br /> if(this.x === undefined || this.y === undefined){<br /> var xy = this.el.getAlignToXY(this.container, ‘c-c’),<br /> pos = this.el.translatePoints(xy[0], xy[1]);<br /> if(this.position === ‘cascade’){<br /> this.x = Ext.winPosx = (Ext.winPosx)? Ext.winPosx+20 : pos.left;<br /> this.y = Ext.winPosy = (Ext.winPosy)? Ext.winPosy+20 : pos.top;<br /> }else{<br /> this.x = this.x === undefined? pos.left : this.x;<br /> this.y = this.y === undefined? pos.top : this.y;<br /> }<br /> }<br /> this.el.setLeftTop(this.x, this.y);<br /> if(this.expandOnShow){<br /> this.expand(false);<br /> }<br /> if(this.modal){<br /> Ext.getBody().addClass(‘x-body-masked’);<br /> this.mask.setSize(Ext.lib.Dom.getViewWidth(true), Ext.lib.Dom.getViewHeight(true));<br /> this.mask.show();<br /> }<br /> }<br /> });

NOTE: Find the source on my Github ExtJS.Patterns repo.

Here it has been modified to add an if statement that looks at our new position config to see if its been set to ‘cascade’. From there we can add 20 pixels to both the x and y axis of the previous window position to place it cascaded. The previous window position has been stored in the winPosx/y properties of the Ext object. The else simply runs the original window position code.

This is all overwriting the original beforeShow method of the Window, which simply placed the window in the center of it’s container. This change applies to every single window that is created, even windows that might be extended from the base window class, it’s essentially changing the source code of the Ext JS library, without touching the source files.

How About Fixes

Fixes are really the same thing, if were adding new features or fixing problems it’s all the same as far as Overrides are concerned, though most of the time an Override would be used to fix a bug. Need I say more?

Summary

Overrides are great for adding features or fixes to the library code without disturbing the source files. Keep this in mind when you run into a bug in the library and need to ‘patch’ it to get things working, or have required features that should be part of the base library. The goal should be having NO overrides at all, which can be achieved by reporting bugs and posting feature requests. Enjoy!

Scenario (our use case)

Our goal here is to create a ‘required’ indicator on all form fields by setting a required flag on the configuration object of each component – in our case, form fields. The code base (the web app) is already in place, so this is a web application that has been completed and is in use.

We have a few options available to make this happen:

• Override
• Extend
• Intercept/Sequence

Lets take a look at the benefits and problems imposed by these methods.

Override

Of course one way to get what we want is to override a particular method in the component were using. If were lucky, there is a stub function in place that we can use, but more often than not, this is not the case. What were left with is having to copy code from the library source files and modify it to fit our needs – not the optimal solution. This means that each time the Ext JS codebase is updated, we need to check the changes against our overridden copy. This is a maintenance nightmare, though there are cases where this is the optimal solution.

Extend (new Component)

The better of our two options is the Extend method. This way creates a copy of the component that we can modify to fit our needs. Not a bad solution all and all. The two problems here are that any components that inherit from our extended component will not get our new functionality, and we now have a copy of the component with a new name, so each place we use that component needs to use our updated component name, ie: ‘mysupertextfield’ instead of ‘textfield’. Again, not a big deal, but if I already have a complete web app, and im adding a bit of functionality to a common component, I don’t want to have to run a find/replace on the entirety of my code.

Meet intercept/sequence

My personal favorite in this situation is to add our functionality either before or after an existing method. The intercept method of Ext JS takes whatever function you provide and executes it right before whatever method in the component you specify. The function we define is also executed in the same scope as the method were intercepting.

Ext.intercept(Ext.form.Field.prototype, ‘initComponent’, function() {<br /> var fl = this.fieldLabel, ab = this.allowBlank;<br /> if (ab === false && fl) {<br /> this.fieldLabel = ‘<span style="color:red;">*</span> ‘+fl;<br /> } else if (ab === true && fl) {<br /> this.fieldLabel = ‘  ‘+fl;<br /> }<br /> });

NOTE: Find the source on my Github ExtJS.Patterns repo.

With this override, we can use the existing allowBlank flag to trigger the required indicator

…<br /> {<br /> fieldLabel: ‘Last Name’,<br /> allowBlank: false,<br /> name: ‘last’<br /> },{<br /> fieldLabel: ‘Company’,<br /> allowBlank: true,<br /> name: ‘company’<br /> }<br /> …

In this case, intercept seems to be the perfect fit, allowing us to add a visual required indicator to each component that is extended from the Field base class. The one downside I see here is that this code is executed every single time a field is created, so be sure to make it lean.

We could also use Sequence to achieve this, which uses the same syntax and concept as Intercept, but executes after the method we define has executed instead of before. The order of execution is like this:

• Intercept
• Method (ie: initComponent)
• Sequence

Summary

I hope this has helped. Over the next few weeks I will be blogging about the many Ext JS patterns available, their pros and cons, and practical usage. Each one will have code paired with it on Github.

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