codeboxer.com

Code:

Returns a link to a remote action defined by options[:url] (using the url_for format) that’s called in the background using XMLHttpRequest. The result of that request can then be inserted into a DOM object whose id can be specified with options[:update]. Usually, the result would be a partial prepared by the controller with either render_partial or render_partial_collection.

Examples:

Code:

Code:

You can also specify a hash for options[:update] to allow for easy redirection of output to an other DOM element if a server-side error occurs:

Example:

Code:

Optionally, you can use the options[:position] parameter to influence how the target DOM element is updated. It must be one of :before, :top, :bottom, or :after.

By default, these remote requests are processed asynchronous during which various JavaScript callbacks can be triggered (for progress indicators and the likes). All callbacks get access to the request object, which holds the underlying XMLHttpRequest.

To access the server response, use request.responseText, to find out the HTTP status, use request.status.

Example:

Code:

The callbacks that may be specified are (in order):
:loading: Called when the remote document is being loaded with data by the browser.
:loaded: Called when the browser has finished loading the remote document.
:interactive: Called when the user can interact with the remote document, even though it has not finished loading.
:success: Called when the XMLHttpRequest is completed, and the HTTP status code is in the 2XX range.
:failure: Called when the XMLHttpRequest is completed, and the HTTP status code is not in the 2XX range.
:complete: Called when the XMLHttpRequest is complete (fires after success/failure if they are present).

You can further refine :success and :failure by adding additional callbacks for specific status codes:

Example:

Code:

A status code callback overrides the success/failure handlers if present.

As a second part in this series, I am going to talk about Lighthouse for a second. They rock. I built up a calendar app based on their API and the Ruby calendar_helper, and it barely took me a day. True story. I ended up using an API token, and I learned a lot about a lib/ based connection object, very interesting.

Here are a few caveats:
Don’t mess with the root class too much, it’s not really necessary for most of what I had to do. This is actually one of the cases where it makes sense to load the logic into the controller (a little bit).
All Lighthouse database objects are not created equal - Tickets are king, and everything else is nothing. I will explain more later - just don’t try to get picky with your call for Milestones. All I have ever been able to do is return a simple dump.

Installation: all I had to do was click through to the GIT repository. From there click lib/, and then lighthouse.rb. Cut and paste the code you see into a lighthouse.rb file in your lib/ folder. Everything you need is right there.

code snippet from my controller action:

Code:

Thankfully, you can get picky with your call for Tickets. That is where the meat of the API is. The text based date searching is pretty cool, because you get a hard limit of 30 rows returned from your query, so you need to be granular enough to catch only what you want.

This is a remote controller action that I use to get info about a particular ticket:

Code:

Notice the 8 hour time differential from UTC code, and that you have to iterate through the ticket.versions to pull out the notes (thanks to Lighthouse help staff for that one).

And then, of course, I have this at the top of my controller:

Code:

like I said before, somehow the @project.milestones method won’t take a :q argument, so you’re stuck with just a simple ’select *’ query for your @milestones recordset. Maybe they will change this soon.

So there I was, trying to piece together how to use this calendar_helper that I found for Ruby.
It actually works great, is more or less CSS-powered which is good for cross-browser issues, and is pretty easy to use BUT you sort of have to decipher how to use it. Everything you need is there, but there is not a spec of hand-holding. Ah, the good old days, when all you had to do was RTFM. Now you have to DTFM, the d standing of course for decipher, or possibly discern, assuming you actually have something akin to a manual. Anyway, here is what I got.

Good to know #1: You should actually read the part about installation - you have to add Readme.txt to the rake file in the vendors folder that is created on the calendar_helper install. Other than that, the install was a piece of cake. Remember to add all the pertinent files to your project - all the classes and style sheets, etc.

Good to know #2: Don’t bother with the ‘next’ and ‘previous’ month options, they didn’t turn out to be too useful (to my mind).

#3: Don’t use custom CSS classes until you have the UI where you want it. The default classes look A LOT better at first, so just leave it there in the beginning.

Now for the codes samples. This is from a Lighthouse integration that I did recently, which was awesome and I’ll cover the Lighthouse part in a separate post.

the controller - notice how I pull the year/month out of the parameters, this is how I use the same page for everything.

Code:

the view:

Code:

There it is. I especially love that you can pass the calendar method a block, and that each day iterates as a date object. Sweet. Remember that for some reason, the day (number) of a date object, as far as I can tell, is [date].mday, as opposed to .day, which is how it works off of a Time object. Go figure.

Just write the headers, pull up the xml by report_id, and slurp it out. Piece of cake.

Code:

Code:

works everywhere!