The app I’m working on is very heavy in 2.0 features.  The majority of the actions are initiated from a single page and updates are done asynchronously.  Many of those operations create or update records in the database and as a result need some kind of validation.  My solution to displaying the error messages was to render a template that called error_messages_for to build the message and then dump it into a div.  More precisely I setup a template that called a helper to render the messages and update the div.  According to the docs, when using helpers with RJS responses, there should be a page method that’s accessible from the helper and it surely was.

class ApplicationHelper
def render_rjs_errors
page.replace_html :errors, error_messages_for(:account)
end
end

But to my surprise, error_messages_for was not available!  After a bit of digging I discovered what was happening.  When you call update_page or render an RJS template your code is evaluated in a JavaScriptGenerator instance instead of an instance of ActionView::Base.  This instance gives you access to all the miscellaneous Javascript/Prototype helpers such as replace_html, show and hide, but it doesn’t include any of the ActionView::Helpers.  As far as I could tell the only things that it included automatically were ApplicationHelper and any helpers that you’d explicitly included in your controller.  I felt a bit gypped.

After still more digging I discovered that the original ActionView::Base instance is available via a @context member variable that’s available in your helpers in much the same way that the page method is available.  Since your helper modules are being included into the JavaScriptGenerator instance you have access to all it’s methods and member variables.  The page method, for example, is just a special instance that returns self.  Since the @context member refers to the original ActionView::Base instance we could use it to get to all the helpers.

class ApplicationHelper
def render_rjs_errors
page.replace_html :errors, @context.error_messages_for(:account)
end
end

Pretty lame though.  The code is very magic.  It doesn’t follow the pattern of the other helpers.  Why do I suddenly have to access the member via @context.  Where did it come from?  The page method is enough of a stretch. What to do?

It turns out that JavaScriptGenerator implements a method_missing method that catches any calls it doesn’t know about and passes them off to a JavaScriptProxy object (it’s not really important for this discuss but that object appears to generate some fancy JS from your call).  If we hooked method_missing we could ask it to route to @context behind the scenes and our helpers would be clean once again.  After a bit of tinkering I created a plugin that does just that, BetterRJSHelpers.  All is now right with the world.  My helpers are clean and all (most) of the magic is hidden away.  Enjoy!

= link_to_function 'My Link' do |page|
  page[:some_div].show()

The resulting JS included some dandy error handling but where I expected an Element update what I saw was literally ‘page[:some_div].show()’.  After a little Googling and some thinking I realized my mistake.  The Haml interpreter has to parse every line of your input file.  Those lines that you flagged to be evaluated with Ruby, those that start with ‘-’ and ‘=’, are chunked into sections and eval’d (or something along those lines).  The interpreter was therefore treating my line as straight text, not to be treated as Ruby code!  Silly me.

The working code looks like this.  Eval all the lines of my block please Haml!

= link_to_function 'My Link' do |page|
  - page[:some_div].show()

FYI, the reference for using blocks in Haml can be found here.  The documentation is correct but another example or two wouldn’t hurt.

Initial print.  Based on a test strip including mostly exterior areas.  Result was very dark.  Contrast on the outer areas was relatively low.  Ran a couple more test strips at higher contrasts.  Was still focusing on the exterior.  Pretty much decided that some significant dodging would be required for the interior.

Second print had better contrast on the exterior but was somewhat dark.  No interior detail.

Cut out a mask for the interior and made a couple of prints similar to this one.  Note the burn shadow at the top of the door.  Needed to adjust the mask to leave more of the doorway open.  Area to the right of the door was still too light but generally contrast on the exterior was pretty good.

Came back the next day and made this print with fresh developer.  Learned a bit of a lesson that day.

I liked the darker print so went a bit darker on the exterior and burned in to the right of the door.  Got kind of a crappy burn on the right side and the bottom of the door.

Slightly too dark around the upper left due to some crappy hand burning.  Bad halo around the doorknob and got a bad dodge from the mask at the bottom.

Final print.  The main area is a just how I wanted it.  The only issue is another bad dodge around the bottom.  Some of it will be cut off by the mat and it’s not especially obvious in the print.  Overall I’m very happy with it.

I had a situation where I had an associative array that contained a single key value pair.  I wanted to extract the key and the value into two separate variables.  First I tried this:

$key = array_keys($array)[0];
$value= array_values($array)[0];

If I’d had more experience with PHP I would have known that it won’t allow the result of a function to be indexed directly (if I’m wrong about this and there is some syntax that allows this please let me know!).  The ugly alternative was something like this:

$key = array_keys($array);
$key = $key[0];
$value = array_values($array);
$value = $value[0];

It then occurred to me that I could use the list function (it’s really a language construct, not a function) to accomplish the same thing.  That resulted in the following code:

list($key) = array_keys($array);
list($value) = array_values($array);

Much cleaner!  Obviously this is a very specific case but handy if you ever run into it.

If you dig deep enough you’ll find that Cake hooks into Configure when it goes looking for those ‘classes’ of files (e.g. Vendor, Core, Components).  As an example, if I wanted to be able to load files from a util directory that lived inside my root directory I could do the following.

Configure::write('utilPaths', APP.'util'.DS);
App::import('Util', 'MyLibClass');

When App::import is called it will look for a key in configure matching the lowercase of the key you provided followed by ‘Paths’.  The fact that it’s lowercase actually seems like a bug and is rather unintuitive but it does work.

The next day I went back with some fresh developer to finish things up.  Big difference.  Have a look at the scans below to see for yourself.  In some ways it was a happy accident as I actually prefer a darker, but still slightly revised, version of the print.  On the other hand it would have been nice to know that I had my numbers right in the first place so I could get a consistent result if I wanted to reprint down the road.  I take careful notes of all my prints but if my development conditions aren’t the same then those notes are useless.  I think I’ll be mixing a lot more chemistry in the future.

Abbey Door with stale developer.

Abbey Door with fresh developer. Notice the much darker tones

Network and Sharing Center

In XP I could right click and share.  Not so with Windows 7.  Twice it has taken me upwards of half an hour to share a file between two machines on the same network, both running 7.  I’m still not sure what the proper procedure is.  Most recently I had luck with Homegroups.  If you haven’t setup a homegroup on your network you can do so from Control Panels -> Network and Sharing Center.  It will provide you with a ridiculously long password that you’ll need to enter on the other machines in you network.  I’m not sure if it’s possible to recover or change this password.  After setting up your homegroup on the two machines you want to share between you can right click on a folder (probably only in a directory you own) and choose the Share With… option.  One of the options that comes up should be your homegroup.  Be sure that you have file and printer sharing turned on in your Home network options, Control Panels -> Network and Sharing Center -> Advanced Sharing Settings.

Wasn’t one of those Microsoft commercials about making Windows easier to use?

try {
throw new Exception('fail whale');
} catch(Exception $e) {
echo 'got here';
}

Simple right?  I thought so too but despite the fact that the exception was being caught I was still seeing stack traces being dumped to my console (and via stdout, not even stderr).  In this case it looked something like this:

Exception: fail whale in C:\Users\Tim\Desktop\test.php on line 3

Call Stack:
0.0005 322640 1. {main}() test.php:

Variables in local scope (#1):
$e = *uninitialized*

got here

After much poking around I discovered that the problem was XDebug.  Apparently it has a setting, show_exception_trace, which will dump exceptions, even those that are caught and handled.  I’m not sure if I copied the setting from somewhere or if it was the default but it certainly through me off.  Change it to zero in your php.ini file and you’ll be much happier.