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');
}

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.

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.

• aasm Fork of the acts_as_state_machine (AASM) gem. The fork adds support for logging state changes in a DRY way.
• amatch Fork of the Approximate string matching gem. This fork incorporates Michal Granger’s Ruby 1.9 patch
• has_easy Easy access and creation of “has many” relationships for ActiveRecord models. Forked to fix some bugs around validation errors.
• param_protected A Rails plug-in that provides param_protected and param_accessible methods on controllers. This fork allows the use of a Proc for generating the action list in include/exclude from protection.
• soap4r Modified soap4r library to run on Ruby 1.9

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.

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.

The most pertinent finding was low discoverability for admin features. Participants were largely successful completing tasks but had difficulty finding where they needed to go to get to admin features. Improving discoverability of admin features will require a combination of solutions, but one method we have used to begin this effort is observing the paths our participants took looking for these admin features.

A professor of mine at the UT Austin School of Information told me a story of a university planning committee that needed sidewalks put in a new area of campus, but the committee didn’t know where best to put those sidewalks. They decided not to create the paths for the students, but rather wait and see where students wore paths into the grass and then build the sidewalks there.

Likewise, we watched multiple participants going down the same fruitless paths, looking on the same pages, trying to find features they needed to complete the tasks. Taking into account potential biases and considering related use cases, these observations helped us identify places in the application where crosslinking to admin tasks could very well improve admin feature discovery.

We’re working on sweeping changes in the user interface in the coming months, during which we plan to implement these and other usability enhancements.

• Documentation (or lack there of)

Soap4r is an implementation of Soap 1.1 for Ruby. One of the major problems is the complete lack of documentation. There are documentation entries for all the various classes but there isn’t any sort of explanation as to what does what. The only real way to figure all this stuff out is to use google and search other forums.

• Caching

Soap isn’t very speedy and neither is Ruby. Soap4r doesn’t support caching of the wsdl and xsd files so every time you initialize the driver it will go out and get a new copy of the wsdl. This slows down the system tremendously. I implemented a really basic caching check into my class that solved this problem. I think this should be a part of Soap4r but it isn’t.

t_wsdl = 'config/lecayla.wsdl'
if (! FileTest.exists?('config/lecayla.wsdl')) || (! FileTest.exists?('config/lecayla.xsd'))
File.open('config/lecayla.wsdl', 'w') do |f|
f.write(Net::HTTP.get(URI.parse(billing.wsdl)))
end
File.open('config/lecayla.xsd', 'w') do |f|
f.write(Net::HTTP.get(URI.parse(billing.xsd)))
end
end
This will store the wsdl and xsd files in your config directory for use in your driver setup. If you don’t cache them in some form you will have a huge speed hit.

• Multiple ports in the same wsdl file

In PHP soap you just tell php to use the wsdl and everything just works. It doesn’t matter if the calls you are making are designated within different ports or not. PHP just does its thing and you do yours. With Soap4r it isn’t quite as simple. For Lecayla there are 3 different ports in their wsdl file, ContractHttpPort, MeteringHttpPort, and SSOHttpPort. In your initialization of your class you need to specifically setup each one. I did this:

@contractDriver = SOAP::WSDLDriverFactory.new(t_wsdl).create_rpc_driver(nil,'ContractHttpPort')
@meteringDriver = SOAP::WSDLDriverFactory.new(t_wsdl).create_rpc_driver(nil,'MeteringHttpPort')
@ssoDriver = SOAP::WSDLDriverFactory.new(t_wsdl).create_rpc_driver(nil,'SSOHttpPort')

Now in your class if you for example want to add a user you simply do

@meteringDriver.registerUser(params)

This is another reason to cache your wsdl, otherwise for each of these it would go out and get the wsdl. You can guess as to how long just this process took.

• Data structure formats

For Lecayla the structure of your hashes can be complex for the calls that you need to make, and it isn’t completely clear as to what the format should be for some of them. In PHP this was easy because they provided a sample and it was quick to get it up and running. In Ruby this took a little work figuring out. Soap4r contains a script called wsdl2ruby.rb that takes a wsdl file and outputs a driver file and a script that you can use to test based upon the xsd and wsdl that you give it. I found it a lot easier though to just read the wsdl and xsd files myself. The code generated by wsdl2ruby seemed to be extreme overkill for what I wanted. With some help from the Soap4r maintainer and some sorting out by myself. Here are some of the structure formats.

Also make sure you wrap your calls in begin blocks so you can catch any exceptions that come across. The Lecayla documentation on their web site for developers is extremely helpful for what you will get in return and what the errors mean.

Thats about it. The above should be enough to get you started really quickly with implementing Lecayla in your system. Hopefully this is also some help to those folks out there that have been given a wsdl and don’t know what to do with it in Ruby. There is a Google group for Soap4r that I found useful for asking questions. The maintainer of it actually answers questions which is a lot better than what some other maintainers of Ruby projects do.

1. It allowed for retroactive running of migrations with versions at or below the current database version.
2. It allowed a developer to force run a migration, even if that migration had already been run before.

Point one solves the problem where you have multiple developers sharing the same development database and all writing migrations at the same time. For instance, you create a migration 002_blah, but before you run it and check it in, another developer created, ran and checked in migration 002_bleck. By default in Rail’s, your 002_blah migration will never be run because the database is already on version 002. My library instead says “ok, I’m on version 002, but lets see if there any new migrations at or below that version that have not been run yet.”

Point two is dangerous and indeed has lead our database to get all mucked up more than a few times, but hey, it’s a feature no one is forcing you to use. The “force run” feature lets you run a migration (either up or down) even if it has already been run before. This feature is nice for when you realize you made a mistake in an already run migration and instead of making a new migration, you just want to edit and fix the existing one. You “force down” it, edit/fix it, then “force up” it.

I made a plugin for Rails called Retroactive Migrations (r_migrations) that implements this behavior. For installation and documentation, please see my personal blog post about it.