Thursday, August 20, 2009

IE6 DHTML fun

I had a wierd one this week.

We had a form which we were loading dynamically on a key press and the form had buttons of the form:


<a href="#" onclick="if ($('myform').onsubmit()){$('myform').submit();};"><span>go</span></a>

None of the buttons were functioning correctly, and were not producing error messages.

To make things even more interesting, the form was being created from a partial in a helper (Rails).

The code basically looked like this:


toggle = link_to_function "---HTML---", do |page|
page << "--some javascript--"
page.insert_html :top, 'main', :partial => 'friendships/new', :locals => {:friend => friend}
page << "--some javascript--"
end


The form was contained in the 'friendships/new' partial.

Needless to say, the raw html produced was very ugly and full of various amounts of escapes and quotes. I was pretty sure that this was the source of the problem. I was wrong.

It was pointed out by karma that the problem was really a permissions issue. The page.insert bit in the helper uses prototype.js to create the html and insert it into the page at the top of the div with id='main'. The problem is that the order it does this in is:

1. Instantiate the html.
2. Insert into postion.

As karma points out, that leaves all javascript operating at the security level of about:blank.

The solution was to add a funny little bit of javascript to the page:


page << "var x = $('myformcontainer').innerHTML;$('myformcontainer').innerHTML = x;"


This had the effect of re-inserting the code in place on the page, rather than instantiating it first.

Thursday, July 23, 2009

Javascript Cookies

Thanks to Jason McCreary, I was able to get Javascript cookies working very easily.

The one thing missing on that page, though, is a more general bit of help with how to safely use cookies. My first attempt (below) almost worked perfectly, however there was a little bit of weirdness.


Cookie.init({name: "macBlogMenu"});
open_nodes = Cookie.getData("open_nodes");
<do stuff>
Cookie.setData("open_nodes",open_nodes);


I am working on a rails site which is defined such that /blog shows the current blog and /blog/N shows the blog with id=N. Since both of these show a blog entry and the cookie was to keep track of menu state on the blog display page, I used a javascript cookie with just default options. This was a bad idea. State was not being updated when I looked at other blog entries, only when I used the default (current) blog entry.

Anyone familiar with cookies would probably already know the answer is to define the path option for the Cookie object. So the better code is:


Cookie.init({name: "macBlogMenu"});
Cookie.options.path = "/blog/";
open_nodes = Cookie.getData("open_nodes");
<do stuff>
Cookie.setData("open_nodes",open_nodes);


The path needs to be "/blog/" because of the scope rules for cookies. Documents at root (one level - i.e. /blog), can read and change cookies for documents on lower nodes. Lower nodes (/blog/3) can read cookies defined for higher level paths, but not set them. By defining the path this way, it is accessible to /blog and /blog/N documents.

Wednesday, July 15, 2009

Git Diff and Empty Files

I use git for local source control whenever possible.

If I am working with a system which does not have access to my repository, sometimes I use "git diff" to create patch files to update the remote site.

Today, I found a huge flaw in that strategy. If I have an empty file that was created on my local site, the "git diff" output does not include the file at all!

There are two ways around this. The first is to remember that the file needs to be created on the remote system and to "touch" the file. The second, and better way, is to never create completely empty files. Instead, create a file with a comment that it is intentionally left empty.

Friday, July 10, 2009

Jackalope Apache Virtual Hosts

I had an annoying problem with my Apache virtual hosts when I updated to Juanty Jackalope recently. Any hostname I used to access my server was resulting in the same virtual host serving the page. I lived with it for a week or so by using a2dissite/a2ensite to only enable the virtual host I needed at the time (obviously a poor solution).

I figured it out today. The trick was to go through all of my virtual hosts and change the line:


<VirtualHost *>

to

<VirtualHost *:80>

I hope this helps someone.

Wednesday, March 25, 2009

Working Environment

I've been thinking a lot lately about how I work. You know the saying: work smarter, not harder. I'm wondering if I am working smart enough.

First off, I was a Unix/Linux systems administrator for 10 years, so my preferred development OS is linux (Ubuntu, primarily). I do ruby on rails development. That means I normally have two windows open: A terminator window, and a browser window (usually flock).

I am a bit of a command line/terminal bigot. I work most efficiently that way. I know lots of people do great work with various graphical IDE's. I've just never been satisfied that I (me personally) can work faster than on the command line. I use vim extensively. With multiple windows open in terminator, each of which is running a named screen session, I am able to have a couple of edit sessions and a console or database session running. With a little hackery, I can copy text to and from the various windows using keyboard shortcuts only.

Why flock browser? Well, for starters, I was part of the development team for a while, and still in contact with those working on it. If something breaks, I know who to talk to about it. Also, I find the aggrigation of my various social networking bits useful (but the addition of linkedin would be nice).

In addition to these, I have, for one of my projects, the need to use campfire. To help with that, since the mozilla update of the number of unread messages is not always reliable, I use butane to keep up with the discussion. Finally, I use Pidgin for general IM functions.

If anyone reading this has any suggestions for working smarter, I'd be happy to entertain them.