the singularity of being and nothingness
Archive for August, 2011
ColdFusion Gotcha: Switch Statement in CFScript
Aug 30th
The other day, I was reworking a bit of tag-based code to use my preference of <cfscript> syntax. While doing this, I ran across something like this:
<cfswitch expression="#img.extension#"> <cfcase value=".gif,.jpg"> Not transparent </cfcase> <cfcase value=".png"> Transparent </cfcase> </cfswitch>
No rocket-science here, just a simple switch statement which just so happens to have a “case” which evaluates a list of values. Honestly, I’m not sure I had ever done a list of values in a <case>, but it just works.
Thinking nothing of it, I quickly converted it to <cfscript> syntax:
<cfscript>
switch(img.extension) {
case ".gif,.jpg":
writeoutput("Not transparent");
break;
case ".png":
writeoutput("Transparent");
break;
}
</cfscript>
At first, I thought it was working. But as I tested a bit more, I noticed that it wasn’t. No error, per se, but the “case” was not evaluating as it did in the tag-based equivalent.
Turns out you have to do something a bit different with <cfscript>. Here’s an alternative that will replicate the tag-based functionality:
<cfscript>
switch(img.extension) {
case ".gif": case ".jpg":
writeoutput("Not transparent");
break;
case ".png":
writeoutput("Transparent");
break;
}
</cfscript>
According to the docs,
Multiple case constant: statements can precede the statement or statements to execute if any of the cases are true. This lets you specify several matches for one code block.
Ah, so More >
Why Does God Hate the East Coast So Much?
Aug 29th
Over the weekend, Presidential-hopeful Michele Bachmann joked that the recent string of natural disasters to hit the East Coast are clearly the sign that God is displeased with current levels of government spending.
It seems pretty obvious that her “joke” was a calculated rhetorical ploy to connect with her audience that day, so I think speculation about whether or not she actually “believes” that these disasters were somehow ordained by God are unnecessary. However, joking aside, there are many others–like the now predictable Mr. Robertson–who sincerely believe that this or that natural disaster are not only initiated by God, but are moreover intended to bring about some desired end. That is, the devastation is not just punitive; it’s also supposed to bring about a change in behavior.
But what change? The problem, of course, is how one is supposed to interpret a divinely ordained natural disaster. Earthquakes, tornadoes, and hurricanes are hardly *targeted* phenomenon. So if the presumed instigator of God’s holy wrath is particular sins by particular people (you know, the usual: homosexuality, supporting comprehensive health care reform, or voting for Obama), how does one discern against whom (or what) the natural disaster is directed when everyone in the path of the More >
Hello 2003, Let’s Build a Stylesheet Switcher!
Aug 27th
Back in the day, stylesheet-switchers were super-cool. I can clearly remember the thrill of creating several “themes” for a website, hooking them up to a cookie, and letting the awesome-ness roll. And in a way, they were pretty cool. After all, having the ability to switch the theme of a website did give *some* customizability to your website, even if the rest of the website was horrifically static!
But the big problem with switching stylesheets in the old days was the incredible headache of trying to maintain X-number of iterations of stylesheets. Need to switch the hue of the link colors? Bust out the find and replace, and be sure you don’t miss any! Want to add a bit of padding to your navigation? Rinse, repeat, and puke. It was burdensome, and prone to many mistakes. I can remember advocating STRONGLY on many occasions to just “live with” the current styles, rather than facing down the daunting task of modifying 8 different stylesheets which may or may not have had any comments/guidance/formatting to them (ok, some of that’s my bad I’m sure…).
So because of these frustrations, stylesheet-switching fell out of favor…at least with me. Too much work for not enough payoff. But those days More >
ExtJS 4: My First Build
Aug 25th
One of the really great aspects of ExtJS 4 is the ability to configure how dependencies in your application are loaded, using asynchronous loading, synchronous loading, or a combination of both. This flexibility lets you really dig into detail when debugging, and you are able to file-by-file see where errors are occurring, where processes can be improved, etc. But even more, you can specify very granularly which files you want–and need–while excluding those you don’t.
Of course, all of this is really meant for your development environment. While it’s fine to load 70+ individual JavaScript files while working out your app’s functionality, you *definitely* do not want to impose such a monstrous load on your site’s actual visitors. This, after all, is why everyone uses ext-all.js. It’s the whole framework, smashed down into a single, minified file. But the problem is that it’s still the *whole* thing. There are probably a bunch of bits of ExtJS that you don’t need. This is where the Sencha SDK tool’ can help create a custom build that includes everything you need for your application to run, without the overhead of all the stuff you don’t.
In what follows, I’m going to outline my first ExtJS 4 build using the SDK More >
ExtJS 4: A Modified Ext.util.History
Aug 21st
I recently implemented Ext.util.History for the first time in a project that I’m working on. If you’re not familiar with History, it allows you to “register arbitrary tokens that signify application history state on navigation actions”. You can then take these “tokens” and use them in your application to display certain views, fire actions, etc. when the user uses their browser’s “back” and “forward” buttons. In other words, it can help you prevent your 1-page AJAX application from reloading completely when someone accidentally hits the back button. But on a more positive note, it allows your AJAX application to use regular navigation conventions of the browser to control in-application functionality. Pretty cool.
The best part about History, however, is that it is stupid-simple to implement. There are basically 3 steps:
- Initialize Ext.util.History
- Build in the “token-building” logic into your application at appropriate places
- Define the listener for handling History events.
That’s it. History is not only easy to implement, but it is also pretty unobtrusive–you can implement it fairly simply into an existing app without completely reworking the whole thing. There’s a lot more to History, of course, so be sure to check out the docs and Sencha’s example.
First, My Example…Before I talk about the More >
ExtJS 4: Intercepting a Window Closure
Aug 18th
In a blog post I ran across recently, someone was trying to intercept the closure of a window via the “X” icon in the top right corner. The idea was to be able to run additional processing before closing the window (such as confirming save/cancel of data, resetting a form, updating a record, or whatever else).
Turns out this is pretty simple to accomplish, but it’s good to understand what’s going on behind the scenes before implementing the solution.
The “Close” ToolWhen you specify that your Window (a glorified extension of Panel) is “closable” (the default behavior, btw), here’s what happens in the background:
initTools: function() {
var me = this;
me.tools = me.tools || [];
......
// Add subclass-specific tools.
me.addTools();
// Make Panel closable.
if (me.closable) {
me.addClsWithUI('closable');
me.addTool({
type: 'close',
handler: Ext.Function.bind(me.close, this, [])
});
}
// Append collapse tool if needed.
if (me.collapseTool && !me.collapseFirst) {
me.tools.push(me.collapseTool);
}
}
As you can see, if the Window is closable, a tool of “close” type is added automatically, and fires the panel’s “close” method when clicked. Here’s what close() looks like:
close: function() {
if (this.fireEvent('beforeclose', this) !== false) {
this.doClose();
}
}
The important thing to note here is that the “beforeclose” More >
ExtJS 4: Adding an App-wide Keystroke Mapping
Aug 16th
In a previous post, I showed how it’s pretty simply to catch keystrokes in your controller, and then do cool stuff in your app. But what if you want to add an app-wide keystroke mapping? For example, consider you’re create something like Sencha’s desktop demo. Within such an interface, it might be nice to map keystrokes to functionality within your app (like initiating a search, closing a window, etc.).
So here’s an easy way to do that.
In this example, I’m creating an app-wide keystroke mapping for search functionality. When a user enters the keystroke of the letter “S” and the Ctrl key, I want to give focus to a search box that exists within the app.
First of all, here’s the app.js for my application:
Ext.application({
name: "MyApp",
appFolder: "app",
autoCreateViewport:true,
controllers: ["Search"....],
launch: function() {
var map = new Ext.util.KeyMap(Ext.getBody(), {
key: 83,
ctrl: true,
handler: function() {
this.getController("Search").activatesearch();
},
More > ExtJS: Selecting Radio Buttons
Aug 14th
As you develop your ExtJS application, you’ll inevitably need to use a good ol’ radio button. Whether you’re using radio buttons as part of a larger form, or just a one-off for a special purpose, ExtJS has some powerful ways to use them…if you know how.
Let’s say we have a simple form for adding cars to our imaginary application. First, let’s create a model to define our data:
Ext.define("Cars.model.Car"), {
extend: "Ext.data.Model",
fields: [
{name: "make", type:"string"},
{name: "model", type: "string"},
{name: "color", type: "string"}
]
});
Okay, nothing to out of the ordinary here. We’ve defined a simple model for our “car” data, and for each car we’ll enter the make, model, and specify the color.
Now let’s make our form for entering this data:
Ext.define("Cars.view.cars.CarForm", {
extend: "Ext.form.Panel",
alias: "widget.carform",
title: "Enter Car Details",
items: [
{
xtype: "textfield",
name: "make",
fieldLabel: "Make of Car"
},
{
xtype: "textfield",
name: "model",
fieldLabel: "Model of Car"
},
{
xtype: "radiogroup",
fieldLabel: "Color",
id: "colorgroup",
defaults: {xtype: "radio",name: "color"},
items: [
{
boxLabel: "Red",
inputValue: "red",
},
{
boxLabel: "Silver",
inputValue: "silver",
},
{
boxLabel: "Blue",
inputValue: "blue",
}
]
}
]
});
Pretty simple stuff here as well. One thing to point out, however, More >
ExtJS 4: ComponentQuery Selectors in a Controller
Aug 6th
In ExtJS 4, you can do some pretty powerful stuff inside your controllers using ComponentQuery. In the following example, I have a simple grid panel view, and I’m using ComponentQuery in my controller to handle itemcontextmenu events within the grid:
views/Bookmarks.jsExt.define("ME.view.bookmarks.List", {
extend: "Ext.grid.Panel",
alias: "widget.bookmarks",
store: "Bookmarks",
scroll: "vertical",
title: "My Bookmarks",
initComponent: function() {
this.columns = [
{
text: "Bookmark",
dataIndex: "title",
flex: 1,
renderer: function(value,meta) {
meta.tdAttr = 'data-qtip="' + value + '"';
return value;
}
},
{
text: "Created",
dataIndex: "created",
xtype: "datecolumn",
format: "m-d-y",
hidden: true
}
];
this.callParent(arguments);
}
});
controllers/Bookmarks.js
Ext.define("ME.controller.Bookmarks", {
extend: "Ext.app.Controller",
stores: ["Bookmarks"],
models: ["Bookmark"],
views: ["bookmarks.List"],
init: function() {
this.control({
"bookmarks": {
itemcontextmenu: function(view,record,item,index,e) {
var me = this;
var r = record.data;
e.stopEvent();
if (!item.ctxMenu) {
item.ctxMenu = new Ext.menu.Menu({
items : [
{
text: "Delete Forever",
icon: "images/delete.png",
handler:function(btn) {
me.deletebookmark(record,item);
}
}
],
defaultAlign: "tl"
});
}
item.ctxMenu.showBy(item);
}
}
});
}
});
First things first. You’ll notice this bit in the view:
alias: "widget.bookmarks"
This allows me to define my class as a custom xtype. This is important because you can use ComponentQuery to select components by xtype. With this in mind, I can now use the alias of my More >
ExtJS 4: A Textfield, a Grid, and Some Keystroke Interception
Aug 2nd
Recently, I’ve been working pretty furiously on the rewrite of Gloss, my first serious ExtJS application. I wrote Gloss in ExtJS 3, but wanted to give it a much-needed overhaul now that ExtJS 4 is out.
One of the more useful features of Gloss (well, I think it is at least) is the search functionality. In my rework, I’ve been trying to solidify some of the keyboard navigation to allow for a more fluid experience.
Ideally, I want the flow to go something like this:
- Enter a search, with as-you-type results
- When the full list of results is returned, be able to TAB from search text field to first row in the list of results
- Be able to TAB or DOWN ARROW to the next result in the list
- When focused on the desired result, be able to strike ENTER or SPACE to load the record
I’ll start with the last two: navigating inside the grid panel itself.
Grid NavigationWith ExtJS 4, this is stupid easy. In my Search controller, I have some listeners set up. They’re keyed in on the “itemkeydown” event of the grid.
Ext.define("Gloss.controller.Search", {
extend: "Ext.app.Controller",
init: function() {
this.control({
"searchgrid *": {
itemkeydown: function(grid,rec,item,idx,e,opts) {
if(e.keyCode==13 || e.keyCode==32) {
... do some stuff More > 
