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');
}
October 1st, 2009
Author: wmeurer
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:
- 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
- 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
- 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.
September 29th, 2009
Author: wmeurer
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.
August 29th, 2009
Author: wmeurer
During development of the Mumboe Contract Management product we have created and modified several open source Ruby gems and Rails plug-ins. While that code has been on GitHub, it has been managed under individual developer’s private accounts. We have now consolidated development under a single Mumboe account for all of our open source projects. The Mumboe GitHub user currently hosts our forks of:
- 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
June 24th, 2009
Author: ScottD
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.
June 12th, 2009
Author: wmeurer
Previous Posts
