Software and Technology Ramblings

I just solved an issue that I couldn’t find an answer for on the web, so I thought I’d just put it out there so that maybe it could help someone else. I am creating a simple CMS tool for one of my clients and always like to use the FCKEditor for CMS tools. I hadn’t built such a thing in Rails before, nor had I used ActiveScaffold before today. But Rails + ActiveScaffold + FCKEditor seemed like the perfect combination. And it is, once you get it working. Here’s what I had to do to make this work for a table called content_items and a field called content.

After installing the FCKEditor and ActiveScaffold plugins, I created, for the content column, a form column override file in my views/content_items directory called _content_form_column.rhtml. After some trial and error, I landed at this solution:

<%=column.name.to_s.titleize %>:

<%= fckeditor_textarea( :record, column.name, :toolbarSet => 'Simple', :width => '100%', :height => '400px') %>

<input name="commit" type="submit" value="Save" class="submit"
	onClick="var oEditor = FCKeditorAPI.GetInstance('record_<%=@record.id%>_<%=column.name%>_editor');
        document.getElementById('record_<%=@record.id%>_<%=column.name%>_editor').value = oEditor.GetXHTML();" />

Now, this is my 15-minute solution. What I’d like to do is get that onClick JavaScript to fire on the form’s onSubmit event and remove this secondary submit button altogether. But, since it’s late, I decided to remove the ActiveScaffold Update button and make this column the last on the page. How’s that for an I’ll-deal-with-it-later hack!?

Just a quick note on a surprising feature of Apple Mail and iCal. After I upgraded to Leopard, I noted that some items in my email (addresses, dates, times, etc) had contextual menus appear when you rolled over them. The menus let you create a contact or an iCal event from the data in the email. But, again, Apple surprises with attention to the smallest details. For example, I was emailed this simple confirmation for an upcoming meeting:







When I rolled over the 6:00, the menu appeared and selected Create New iCal Event…. A little pop-up appeared and I began filling it out. When I went to choose the date, to my surprise, it was already selected:







It scoped out the rest of the message to find the mention of Thursday to select the 20th.

The ability to add an iCal event from an email message isn’t what makes a Mac fantastic. It’s the fact that the functionality does not get in your way and when you choose to use the feature, it works as you’d expect… and better.

I was publishing PositiveWare’s first AIR application (PositiveWare time card now on your desktop!) and got this helpful error message:

Error creating AIR file: 105: ERROR, application; 105: ERROR, application

After Googling it, I could find nothing of use. So I decided to start from scratch with the app.xml file and found it there.

It’s my guess that 105: ERROR means malformed app.xml file.

Hope that helps someone out there.

Now that I have my little AIR application, I need to follow through to the point where it can be added to my client’s internal toolset.

Here’s a rough shot at how I’ll do that (this is really for my client only but feel free to play along):

• Enable Flex-side login into the application via SOAP (if necessary)
• Add an image browser to allow for easy selection of thumbnail and detail image
• Take the key pieces of activity data and create an activity with an exsiting web service call
• Shoot the user over to the Activity Wizard. (Interesting hurdle here… how do I send the user from my AIR app to a URL inside of a browser?)
• Reset the Scaper to allow for the creation of the next activity

Once that is in place, the following features can be added

• Selection by the user of additional activity fields to scrape off the page
• Full integration of the Activity Wizard. So the user doesn’t actually exit the AIR app, the AIR app contains the ‘Wiz
• Addition of some versioning for the AIR utility (would allow for easy software updaets). This is more as a proof-of-concept since this tool is an internal tool.

Have you ever wanted to buy something that you knew you’d have to find a use for it after you got it home?

Well, the iPod is an awesome example of that. In ‘02, I knew that I really wanted one but couldn’t really explain its value to my wife. Well, thankfully she didn’t need to hear about its value and surprised me with a 10GB iPod right before a week-long vacation.

I quickly found a use for it (albeit after the fact). Pretty much every day since I’ve had my iPod nearby to entertain/distract/focus me during work hours… Clearly millions of other people have seen the value in the technology since.

Adobe’s AIR is kind of the same way for me. I know it’s great and it’s going to be very relevant in the next 5 years, but I haven’t proved it with anything tangible. I actually am a lot further down the path of understanding its value than I was when an iPod was handed to me, but I have yet had the opportunity to prove it with an AIR project of my own.

First, the value. Flex itself brings the best way to bulid browser-based RIAs. But AIR allows Flex to see its full potential as Flex on AIR is now a way to build fully-featured, client-side applications. AIR can also allow for the deployment of HTML/Ajax based apps, but I prefer Flex.

Here’s what AIR gives you that Flex does not:

• The ability to take a Flex application offline. AIR even provides APIs to easily determine the state of connectivity.
• Access to client-side resources like storage and devices. You can upload files using a browser-based Flex app, but you can’t write files and read directory structures, etc.
• Closer integration of Flex and HTML. The browser is no longer a container, it can become a component within your Flex application. This gives you full access to the DOM. Also, not possible in a standard web browser

So, I am a huge fan of what AIR can do and an even bigger fan of where it can go. But all of my ideas for an AIR application are either super lame (like the majority of my ideas) or way too complex to bite off in an hour-long session of let’s-see-what-fun-can-be-had-with-AIR.

But then, finally, a managable idea was handed to me. I was on-site last Wednesday working with a client who wanted to use Dapper to scrape a bunch of data off of existing web pages and pump it into their inventory system. Having never seen Dapper, and having built several screen scrapers from scratch, I really liked the idea. And I still think the idea has merit, but we decided that with the low number of screens to scrape and the eventual end-users of this tool, Dapper may not be the way to go.

The guy I was working with then had a really cool idea revolving around Google Notebook’s FireFox plug-in. And we were getting even closer to our usability goal.

Finally, it hit me that an Flex/AIR application might do the trick. The UI would consist of empty fields on the left-hand side and then a large HTML container on the right. The user could highlight the content on the web page and click a button in the Flex app which would pull the selected HTML (using JavaScript) into the Flex fields.

My proof of concept (an HTML container, a button and an alert box that displayed the selected text) took 15 minutes to build. That’s from no AIR project to a distributable AIR file. It was also a pretty useless application.

But when I resumed the next day, it took only 45 more minutes to present a usable interface including a feature that pulled all of the images out of the HTML page for selection inside of the Flex app.

That illustrates the third feature of AIR, tight Flex-HTML integration that’s easy to leverage. And it also demonstrates the fourth feature of AIR… it’s really, really easy to build an AIR application. 1 Flex Application .SWF file + 1 .xml AIR descriptor file = all you need.

Now, on to taking this Scraper utility to the next level…