Adding the includeClassIf Method to Ext.Element

I’ve created an includeClassIf method on Ext.Element with the following code:

Ext.override(Ext.Element,{
includeClassIf: function(cls,condition){
condition ? this.addClass(cls) : this.removeClass(cls)
}
});

There are few situations when Ext.Element.toggleClass is the best choice. In fact, just willy nilly toggling anything is risky because you’re assuming that whatever the current state, you want it to be the opposite. That’s messy in most cases.

Then there’s addClass and removeClass, but those are literal, so you must switch between the two using a conditional if you know the state you want to use.

What’s missing in the Ext.Element Class is a way to specify the css class and the state dynamically, when the desired state is known. So with the includeClassIf method, you can do the following:

var state = checkbox.checked;
Ext.get('some_div').includeClassIf('selected',state);

instead of:

var state = checkbox.checked;
if(state){
Ext.get('some_div').addClass('selected');
} else {
Ext.get('some_div').removeClass('selected');
}

Add comment October 1st, 2009 Author: wmeurer

New Search Design

We’ve launched the new search tool! Read more about it on our main Mumboe blog.

For this project customer feedback was the driving force behind the change. Customers requested to see results for documents and contacts in addition to agreements. We looked over past customer searches, which indicated they were also looking for agreement templates and where to perform actions, like where to add a user.

Once we understood the requirements, we fleshed out a few questions that guided the development of the search tool, from design through implementation:

1. What would a searcher most likely search on? e.g. searching for Paul Jones, a contact, the searcher may search for ‘paul’ or part of his email address they remember
2. How can the searcher distinguish good results from unwanted ones? e.g. searching for a document, the searcher may be looking for the most recently uploaded
3. Once the correct item is located, how does the searcher get the information they want? e.g. looking for a contact, they may want to see the related agreements for that contact

Referring to these questions throughout the process directed decisions and kept us focused on the general goals of search: get the searcher to the information they want, quickly, and with little effort. The result is a search results page that provides both pertinent information about the search term and actions to take on that information. This is a big change from the report-style results page of yore.

We’re always looking to improve features, so feel please feel free give us feedback on the new search tool. We hope it helps get you the information you’re looking for.

Add comment September 29th, 2009 Author: wmeurer

Ext JS – Getting order of events for an Ext component

Ext provides public events to which you can attach listeners. Understanding the order in which these events occur is key to building and interacting with components effectively. Although there isn’t any Ext documentation that specifies the order of events for objects, there is a way to have Ext spit out the events it fires when an action is performed on an object (thanks to the folks at Ext for pointing me to this solution).

Run this script after your component is defined:

Ext.util.Observable.capture(Ext.getCmp('my-comp'), console.info)

replacing ‘my-comp’ with the id of the Ext component. All public events will then log to the Firebug console as they occur for actions on that component. For example:

example_window = new Ext.Window({id:'eg_win'});
Ext.util.Observable.capture(Ext.getCmp(’eg_win’), console.info);
example_window.show();
// console will return:
//    beforerender
//    render
//    beforeshow
//    activate
//    show


See http://blog.extjs.eu/know-how/which-events-are-fired/ for the original post on this technique.

See http://extjs.com/deploy/dev/docs/?class=Ext.util.Observable for info on the Observable class.

Add comment August 29th, 2009 Author: wmeurer

Customer Contact Notes are an Excellent Resource

Small companies like us can’t perform a lot of usability studies or afford focus groups; we just don’t have the resources. So, we’re constantly asking ourselves, “How are we going to get in better touch with what our customers are doing and what they need to better manage their contracts?”

Among those with answers are our Business Development and Support folks. Turns out, they take pretty good notes when they talk with customers, both current and prospect. They readily shared the info they have, in the name of improving the user experience.

We’ve recently spent some time reading that info. It has immediately begun to refine our understanding of what’s important to our customers. We’re always looking to narrow the gap between the real world of working with contracts and what our perception of that is, and this is an excellent, resource-affordable way to do that.

Add comment June 12th, 2009 Author: wmeurer

Working Around Errors and Crashes in Adobe Fireworks

Adobe Fireworks is my prototyping tool of choice, but it’s got a lot of problems. It crashes often when using custom symbol scripts, and gives no useful response. After working hours on projects, I often find Fireworks “quits unexpectedly” when opening a file or that it is “unable to drag and drop” when dragging a symbol from the Common Library. In this post, I’ll describe best practices to keep errors to a minimum.

Environment: Mac OS X 10.5.5, Adobe Fireworks CS3

Before You Continue to Work in Fireworks
Install and learn to use Adobe Version Cue (VC) and Bridge, even if you just run a VC server on your local machine and for you alone. VC is a version control system for Adobe files and Bridge is a great way to access those files and versions. The more often you check in changes to a file, the more likely you are to be able to troubleshoot files that crash Fireworks (and it happens, oh yes, it happens) and get back to versions that worked, before they were borked. For more information on each of these and installation instructions visit the Adobe Help Site article or the Adobe PDF all about installation and usage of these two products (FYI: these resources are for CS4, but I’m thinking they’ll work for most versions).

Debugging errors and crashes
Most problems in Fireworks involve advanced script handling (I am planning to soon write a post about advanced symbol script writing, so come back soon). The problem is not that Fireworks doesn’t understand or parse the jsf file correctly. It is that there are few, weak fault tolerance features. When writing javascript code for a symbol, the only way to find out if it works is to load the symbol into a project file. Fireworks WILL let you know when you’ve done something wrong, but it does it in mysterious ways. The trick is to know what to look for.

When you drag a custom symbol from the Common Library to a project, Fireworks loads the script to render the symbol and initialize custom symbol properties. At this time if there are syntax errors or for some other reason Fireworks cannot fully process the script, it will return with the error of “Could not drag and drop. An error occurred.” What Fireworks means to say is, “Encountered a javascript error. Cannot load the symbol. Correct the error and try again.” Fireworks is funny like that. When you encounter this error, remove the symbol from the file, resolve the issue, and try again. Commonly I find these errors are parsing issues, e.g. missing a } or encountering a variable that hasn’t yet been defined. Consider the following:

• Even if you just use the Commands > Create Custom Script window when editing your symbol, there’s a good possibility that a js error will result. Especially if you’ve changed the symbol since you created the script.
• Edit jsf files in a javascript editor, like Textmate or Notepad++. Doing this will keep you from making too many syntax errors.
• Check for issues with boolean operators. Fireworks sets defaults for boolean values as strings “true” and “false”. I have seen odd behavior when mixing true and “true”

Lately, I’ve experienced a lot of files that Fireworks can no longer load. One symbol that I used in all those files was causing Fireworks to crash when the file was opened. Fireworks embeds into the file both the symbol and the script when you import a symbol. So if the file cannot be opened for a fault in loading the symbol or script, that file is gone. You can never open it again. Fireworks needs to fix this, but until then here’s what was causing the fault and what you should avoid.

A symbol script file (symbol_file_name.jsf) must include 3 parts: the functions setDefaultValues() and applyCurrentValue(), and the switch statement that begins switch (Widget.opCode). With that in mind, here is an example of code that will crash Fireworks CS3 (note: this is not useful code, even if it would work–it’s an example of the code that would break):

origHeight = Widget.elem.height;

switch (Widget.opCode){
case 1: setDefaultValues(); break;
case 2: applyCurrentValues(); break;
}

The problem is in the global variable declaration at the top (origHeight = Widget.elem.height;) and the subsequent setting of the height (Widget.elem.height = origHeight;). Height is a read-only property, so setting it does not work. When you drag the symbol into the project file, Fireworks won’t complain, it just doesn’t do anything with the height set line. When you save that file and reopen it, Fireworks crashes with a “Fireworks quit unexpectedly” message. Since you can’t remove the imported symbol or change the script once it’s imported, your file is gone. Consider the following to avoid losing files:

• As discussed above, install Adobe Version Cue and check in changes often. If you cause a crash, you’ll have a late version to return to, instead of square one.
• Read the API and make sure you aren’t using objects you can’t get a handle on or setting properties you can’t set (like height or width).
• Be careful when referencing global variables set on load. They work most of the time, but in some cases can corrupt every file you import the symbol into.

Summary
Fireworks is an excellent prototyping tool but is buggy, even at it’s mature age. You must be vigilant when using custom symbol scripts not to cause major errors. As a catch all, install Version Cue and check in often to avoid total loss of a file. Use Fireworks at your own risk, and let me know if you’ve had these issues before and if they’ve been solved by CS4.

NOTE: While I was writing this, using Fireworks to attempt to recreate issues, Fireworks crashed for a reason I do not understand, nothing to do with what I just wrote. Fun.

Add comment February 27th, 2009 Author: wmeurer