| <?xml version="1.0" encoding="UTF-8"?> | |
| <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | |
| <plist version="1.0"> | |
| <dict> | |
| <key>Label</key> | |
| <string>com.brettterpstra.gitlogger</string> | |
| <key>EnvironmentVariables</key> | |
| <dict> | |
| <key>LANG</key> | |
| <string>en_US.UTF-8</string> |
Where, instead of my inefficient approach, I execute XHR JavaScript responses. Behaves just like JangoSteve said it should for 400 or 424 HTTP response status codes.
Binds the event on $(document) so that dynamically created forms will be affected, too.
Because Rails' Unobstrusive JavaScript (UJS) driver rails.js and jQuery won't execute any JavaScript in XMLHttpRequest's response bodies when the status code is 400 or 424 or something similar, I had to instruct the client (jQuery) myself to render error messages on form validation.
This is my first attempt to do so: instead of a JS request, respond with JSON and do the interface changes client-side. Problem is, the JavaScript code is sent to the client only once, hence ERB view templates aren't available during execution. I couldn't just use Rails helpers this way to refactor rendering flash messages. The HTML was spread across three places then: create.html.erb to handle synchroneous requests and render both flash messages and form validation error, entries.js.coffee to render errors and lastly create.js.erb to render success messages and insert the new entry.
It worked, and it was a fun ride since I didn't