Ben Forta pinged me with an interesting question (and when the Forta pings you, you respond) that I thought I'd share here. It's one of those "best practices" questions that really has no best answer, so as always, I'm very eager to hear what my readers have to say. Don't feel afraid to tell me I'm completely off my rocker - that makes for fun conversation. Ok, so the question:

I have a JQ+jQM=PG app. It started off as 2 small pages and 50 lines of code, and is now 10 pages and over 1000 lines of code (excluding lots of .js libraries, some my own some downloaded, that are all included).

My question simple is how would you go about organizing the code? Each "page" in its own HTML file? Would you put page supporting event handlers with those pages? What about handlers that use JQ to manipulate other pages? Separate all JavaScript in included files? And actually, how the heck to you even use JQ to manipulate controls in another page?

I know there is no right or wrong answer, but I am about to start refactoring this entire mess, so ... any thoughts you'd like to share?

Title says it all. You can now download the final release of ColdFusion 10. There's been a lot of press/blog entries/presentations/videos already on this release so I won't repeat the feature list, but you can see even more new videos on Adobe TV.

One truly disappointing aspect of IndexedDB is that there is no (simple) support for search across your data. It is very much based on the idea of knowing your keys and fetching data based on those keys. You can easily retrieve the "Ray" user object, but you can't search for user objects that have an age within a certain range and a skill property of so and so. That's not to imply you can't do some sorting and filtering though.

IndexedDB supports the idea of key range objects. As you can probably guess, these allow you return objects based on a range of values that match with a particular index. Remember that IndexedDB objects can have any number of properties, but you have to specify which are indexed. And now you know a good reason why - it gives you a chance to filter later on.

Ranges can go in either direction and can be inclusive or exclusive. By that I mean, you can say "Anything object with a name 'above' and including Barry" or "Anything object with a name 'below' Zelda but not including that name." You can also combine both and get a single object too.

For my use-case, I wanted to use a range filter so that I could support 'filter as you type'. My data consists of notes that include a title, body, and created property. I'm not going to go through the steps of setting that up as my previous blog entries (linked at the bottom) went over most of the detail there. Instead, let's focus on how I built in the 'filter as you type' metaphor.

To begin with, I had a function that handled "get all" and displaying the data. It worked by opening a cursor and looping while data existed. Here's how that version looked:

In order to support a bound range, you have to change how you open your object store (remember, think of this like a database table). When we just get everything, we run openCursor on the objectStore (line 18 above). When we want a bound list of data, we get an index first (this is the property we said we wanted to be able to filter on), create the range, and then open a cursor on that. So with a small amount of work, we can update our displayNotes function to take an optional filter. (Note that I also switched to a table display. The change in HTML isn't terribly important here so I won't cover it.)

Focus on lines 31 to 40. You can see the different ways to open the cursor. Note specifically we do our binding based on an input string, like "ra" and append "z" to give an end to the range. So typing in "ra" means we want all notes with a title from "raa" to "raz".

Outside of that - the code is identical. I moved the success portion into a new inner function (handleResult), but it works the same no matter how I get the cursor itself.

You can demo this yourself by hitting the demo button below, but as before, this is Firefox only due to - what I believe - is a bad implementation in Chrome. (I think it could be made to work in Chrome, but as I'm building these examples to help me learn more about IndexedDB, I'm fine supporting the most compatible browser.)

You can find the complete source by .... viewing source. ;)

While preparing for my presentation earlier this week on WebSockets and ColdFusion 10, I ran into an issue trying to wrap my head around one of the features: invokeAndPublish. The docs describe it like so:

Earlier this week Steve wrote to me asking how to use data retrieved in a ColdFusion Component in a Handlebars template. While ColdFusion makes it trivial to serve up query data via JSON, the result format isn't always easy to use in JavaScript utilities. Here's a quick example I wrote that demonstrates how to work around this.

In case you haven't figured it out yet, debugging in mobile is "sub-optimal". (Whatever you do - don't do a Google Images search on sub-optimal.) Brian Leroux has an epic presentation on the topic and I highly encourage taking a look through it. I thought I'd share how I'm debugging in PhoneGap and Android right now.

To be clear - this is a sucky way of doing it. "Sub-optimal" is being too nice. Whenever possible I do as much work as I can on the desktop. But when I get desperate and need to test something on a device, I end up resorting to console.log messages. I know this is only one step better than a bunch of alerts, but I thought it might be useful to show how this is done with Android and some tips to make it a bit more palatable.

Enjoy. I'm going to have some followup blog posts on this coming up this week.

Recording URL: http://experts.adobeconnect.com/p459pvx19cw/

The demo files may be found at the bottom of this blog post.

First off - a huge thank you to everyone who came to our PhoneGap Open Q and A today. We had more than 50 attendees for most of the two hour block which I think is a great turnout. We even had a troll (for a few minutes), so that means we must be doing something right!

The questions were very interesting. I noticed lots of attention around notifications and push, two areas I've not really dug into yet. I also noticed a few questions on the front-facing camera. (According to Andrew, on devices with two cameras, the native UI should simply prompt you when you request the camera.)

The Q and A transcript, as well as the more random general chat, are attached as zip files below.

As always - if you have any feedback about the session concerning how we could improve it, just let me know in the comments below.

p.s. I had a few requests for plain text versions. Here is a plain text version of the Q and A and here is a plain text version of the chat.

Just a quick shout out to remember the BOFs (Birds of a Feather) at this year's cfObjective. You can see the full list here: Birds of a Feather Sessions Announced. While they are all cool, I wanted to call out the CFScript Community Components BOF being run by Sam Farmer. This is a mini-hackathon to help contribute to the community project launched to improve component-based CFScript support. To help sweeten the deal (and improve the code no doubt), Adobe will be providing free drinks at the hotel bar. Now you have no not to attend!

Curious about PhoneGap? Have questions? Tomorrow, Andrew Trice and myself are hosting a 2-hour Adobe Connect session on PhoneGap. This will be an open session for your questions, not a presentation. The Connect URL is: http://my.adobeconnect.com/adobehtml. The date/time is Tuesday 1PM CST to 3PM CST (that's 11AM to 1PM PST).