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

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/

The code in question is quite simple, but just enough lines to warrant some thought about how to make it simpler (read as: make my fingers type less). It disables Components based upon the SelectionModel of another component. With a plugin, we can attach events to the selection model automagically through our plugin, and run a chunk of code that would look around for related Components that need to be enabled or disabled. Setting a special config in each Component that you wish to disable or enable will determine what happens to that Component.

The SelectionEnabler

Lets say we have a grid, and we want to disable or enable the infamous “Delete” button, we would first add this plugin, and since this plugin works around the idea of having groups of Components to enable or disable we will tell it what ‘group’ to look for – in this case its ‘deletegrid’.

{<br /> xtype: ‘grid’,<br /> …,<br /> plugins: [new Ext.ux.SelectionEnabler({enablerGroup: 'deletegrid'})],<br /> …<br /> }

What this does is tell our grid that it should look for Components in that same group when a selection has been made, and disable or enable them accordingly. The next part of this process is to add the Components that we actually want to be disabled and enabled.

Welcome to “Delete”

As the SelectionEnabler plugin gets the message that a selection has changed, it searches within the layout of the current Component for other Components with the enableOnSinge or enableOnMultiple configs set, and if the group name matches, it enables or disables that Component appropriately. Here we have a button with enableOnSingle set to ‘deletegrid’ which will enable the button when a single selection is made, but disable it for multiple or no selection.

{<br /> xtype: ‘grid’,<br /> …,<br /> plugins: [new Ext.ux.SelectionEnabler({enablerGroup: 'deletegrid'})],<br /> …<br /> bbar: [{<br /> text: 'Single',<br /> enableOnSingle: 'deletegrid',<br /> disabled: true,<br /> handler: deleteRow<br /> }]<br /> }

That is all that needs to happen for an ExtJS Component (a Button in this case) to be disabled or enabled upon selection. This same method can be used to disable any type of Component, such as Panels, form fields, etc. Currently it works with Grid and Tree selection models (both multiple and single selections) and can enable or disable any component existing in the same layout that has a disable/enable handler.

Screencast Demo

Sometimes a picture (or video) just says it all, so I took this screencast of some simple example uses, which are also included in the code repo.

My next goal with this is to put some type of caching in place for this plugin so it will not be so resource intensive every time a selection change happens.

http://code.google.com/p/ext-ux-selectionenabler/

Additionally, I want to thank Home & Stone for allowing me to contribute this code back to the community, along with the previous release of the HtmlEditor buttons.

Home & Stone asked me to integrate the TinyMCE editor into their application, so of course I said yes, knowing that I had done this before and that it generally worked out just fine. Well, three or four days later (its all a blur) having written layers and layers of overrides to the TinyMCE editor, extended or overrode Ext.Panel, Ext.Window, Ext.Updater and so on. I finally said to myself “thats enough, this just isn’t worth it” – I can get this done faster and better using ExtJS the way it was meant to be used.

The Outcome

Out of my pain comes a set of plugins that start to mimic what TinyMCE provides, with way less overhead, both in file size and memory.

Currently, these are the plugins that have been created for this set:

• WordPaste
• Divider
• Table
• HR
• IndentOutdent
• SubSuperScript
• RemoveFormat
• MidasCommand

I have posted all of these in a new Google Code project, so feel free to use these in your projects and contribute back any fixes or upgrades you might have along the way.

http://code.google.com/p/ext-ux-htmleditor-plugins/

How to Use Them

First you will need to include the plugin files you want (MidasCommand will need to be included first), then set them up on the HtmlEditor as a Plugin like this:

{<br /> fieldLabel: ‘Description’,<br /> name: ‘description’,<br /> value: ‘bwah bwah’,<br /> anchor: ’100%’,<br /> xtype: “htmleditor”,<br /> height: 400,<br /> plugins: [<br /> new Ext.ux.form.HtmlEditor.Word(),<br /> new Ext.ux.form.HtmlEditor.Divider(),<br /> new Ext.ux.form.HtmlEditor.Table(),<br /> new Ext.ux.form.HtmlEditor.HR(),<br /> new Ext.ux.form.HtmlEditor.IndentOutdent(),<br /> new Ext.ux.form.HtmlEditor.SubSuperScript(),<br /> new Ext.ux.form.HtmlEditor.RemoveFormat()<br /> ]<br /> }

Thats it! They show up in the toolbar in the order they are added. A Divider can be inserted at any point, and some have dividers built in.

Make Your Own

This whole process brought about the creation of a simple base class used for adding your own Midas commands – Ext.ux.form.HtmlEditor.MidasCommand. This class can be extended and provided a simple config that will create the buttons and their handlers for you.

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

PS: Im glad to see the trend towards Plugin use in ExtJS, allowing the addition of bits of functionality without conflicting with other functionality, and without having to resort to extending.

Additionally, I want to thank Home & Stone for allowing me to contribute this code back to the community, they have expressed interest in giving back, so im sure we will see more of these types of things being released soon.