Development Blog: Viget Labs

Tony Pitale, Web Developer, November 26, 2008 8

When outputting sets of data that may or may not be present it is valuable to have some default to display in the cases when that data does not exist.  As this set grows to the point where detection becomes unwieldy, perhaps as new fields are added, having complex conditionals in your view code is typically not the best solution. In this example, Dining & Kitchen and Appliances have no information.

Listing Price Information

• Original Price: $239,999.00
• Low Price: $139,000.00

Dining & Kitchen

Appliances

Bedroom Information

• Main Floor Beds: 2

Enter jQuery: with a simple statement we can easily detect which elements on our page are empty, and fill them with some default value to notify a user of that case.

$('ul').each(function() {
  if(jQuery.trim($(this).html()) == "") {
    $(this).html("<li>No information available</li>");
  }
});

The above code checks every unordered list element on the page to see if the html within is empty. If so, it adds a simple list item with a default value to inform the user that the section on the page has no information, instead of simply being empty. The end result is below.

Listing Price Information

• Original Price: $239,999.00
• Low Price: $139,000.00

Dining & Kitchen

• No information available

Appliances

• No information available

Bedroom Information

• Main Floor Beds: 2

This solution has the benefit of speed, and a fairly accessible global reach, while keeping view code and helpers free of potentially gargantuan if statements.

Mark Cornick, Web Developer, November 13, 2008 0

OAuth is, according to its creators, “[a]n open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.” It accomplishes this primarily by passing various tokens and secrets between the API provider and the application wishing to access it. Understanding what happens with these tokens and secrets (which I will call “credentials” for the sake of clarity) makes OAuth slightly less “simple” to comprehend at first. Fortunately, it’s not too hard, and in this post I’ll share what I learned when implementing an OAuth-speaking client application.

Continue reading "OAuth By Example"

Mark Cornick, Web Developer, October 28, 2008 2

Over the first few years of Rails' history, there have been a few attempts to simplify the process of handling file uploads. FileColumn was one of the early winners. Now Paperclip is becoming popular, for a variety of reasons (among them the lack of a dependency on RMagick, which is the source of enough problems to fill a few more blog posts.)

Recently, I decided to take one of my older Rails projects and replace FileColumn with Paperclip. The process isn't exactly straightforward, but it can be done.

Continue reading "Migrating From FileColumn To Paperclip"

Patrick Reagan, Development Director, October 24, 2008 3

There was a palpable excitement in the air when I arrived at the office yesterday – voting for the Rails Rumble competition had started and 2 of the Viget teams at HQ were tracking progress as our applications bounced around at the top of the leaderboard. Ben posted the list of the competing Viget teams and the the lessons learned, so I thought I'd expand on some of lessons we learned as a team while building the Qflip application:

Continue reading "Fast, Cheap, and Good: My Rails Rumble Experience"

Ben Scofield, Development Director, September 30, 2008 6

It's been some time since we originally proposed the idea of resourceful plugins—a solution to the persistent problem of integrating distinct Rails applications. Over the past year, we've worked on refining the approach (in the context of our two main resourceful projects, Sandstone and Bloget), and in the course of preparing for the tutorial I gave at Railsconf Europe, we've been able to formalize (somewhat) the process of creating resourceful plugins.

Extraction

Like most good, reusable code, the best resourceful plugins are extracted from an existing app, not created ex nihilo. I generally recommend creating a new plugin only after you've built the same functionality into an application at least twice—that way, you've worked through the same problems at least two times, and should be able to create a much better solution than you'd have been able to at the start.

Once you've built the functionality into an application, the extraction process isn't that complicated. You start with the Rails plugin generator (in the examples that follow, I'll use the Bagpipes plugin):

Continue reading "Creating Resourceful Plugins"