Fun with the simple_form Rails Gem

It’s been a long time since I sat down to write a blog about a programming related topic. I’m really hoping that changes this year, but I’ll do my best not to make promises I can’t be sure I’ll keep. I definitely hope to share more of the things I’m learning about and playing with. With that in mind, I was playing with the simple_form gem earlier today and I thought I would share the experiment that I was working on.

Often when working on a project I’ll have a few basic forms that I need for data entry within the system. Nothing too complex, just a few simple fields. For those of you who haven’t checked out simple_form yet, I highly recommend it. After getting the gem installed I created the form I needed:

<%= simple_form_for @member do |f| %>
  <%= f.input :firstname %>
  <%= f.input :lastname %>
  <%= f.input :email %>
  <%= f.input :bio %>
  <%= f.button :submit %>
<% end %>

Knowing that I would need a few more simple forms I wanted to figure out a way to be able to reuse this code snippet. Although I might not do this same approach in a large project with more complex forms I proceeded to pull out the column symbols within the snippet and came up with this:

<%= simple_form_for @member do |f| %>
  <% @member.class.column_names.each do |field| %>
    <%= f.input field.to_sym unless %w{id created_at updated_at}.include?(field) %>
  <% end %>
  <%= f.submit %>
<% end %>

This takes the @member instance variable and get its class, which in this case is Member. It looks at the column names of Member and loops through them. If the field isn’t “id”, “created_at”, or “updated_at” it creates an input field for it. This was a step closer to what I was going for. I imagine there are many opinions about this approach especially when it comes to thoughts on performance. The focus here was about experimentation. So I keep going and made some additional adjustments, caming up with this:

<%= simple_form_for form do |f| %>
  <% form.class.column_names.each do |field| %>
    <%= f.input field.to_sym unless %w{id created_at updated_at}.include?(field) %>
  <% end %>
  <%= f.submit %>
<% end %>

This allowed me to call the code as a partial like:

<%= render :partial => 'shared/form', :object => @member %>

It’s not perfect, I can’t customize the fields in any way, but it let’s me get some basic forms quickly together for testing concepts with a customer.

Anyway, that’s my recent experiment, feel free to share your thoughts and feedback.

Simulating a Table Using an Unordered List

NOTE: It should be said that semantically correct HTML should always be used in favor of <div> craziness. This is meant more as a proof of concept.

Your first question immediately might be, “why would I want to simulate a table with a list, why not just use a table?” With the raise in popularity of AJAX sortable list elements, using list items to represent a multiple column data table can allow for easy sorting of various more “tabley” information. So let’s get started.

First let’s look at our HTML:

Now the CSS:

Ok – I’ve left something out for space. I also implement the clearfix solution as given at: http://www.positioniseverything.net/easyclearing.html

I’ll keep this post short, because I’m expecting that you can figure out everything that was done by the HTML and CSS. Hope it helps someone somewhere to do something cool.

Result:

Understanding “Reverse CAPTCHAing”

I don’t know about you but to me I think the idea of CAPTCHA usage is a little backwards. We are asking humans to prove that they are human, how dumb. Plus not only that, but we are more then insisting that low/poor vision users don’t use our applications. Why not start thinking in reverse a little bit? Let’s make a form that makes the individual prove they aren’t a machine, not that they are a human.Confused? It’s simple – CAPTCHAs exist to prove that whomever or whatever is filling out the form is a human by reading some scrambled mess that a computer could not translate. However, machines behave logically – so we can easily test that a form is being filled out by something that is not a machine without making the user do something annoying like trying to recognize squiggly versions of alpha characters without having a brain aneurysm.

So how do we do this? Well simple… we add an input field to our form and then using a little CSS, hide it (style = “display:none;”). For the field label you could have “Please leave blank” – then for the input id = call it something typical, like city, name, email or whatever. But something that you aren’t using elsewhere on the form. So to review, you should have something like this:

<div style="display:none;">
  <label for="email_address">Please leave blank:</label>
  <input type="text" name="email_address" id="email_address" />
</div>

Now on the server processing page, check to see if this field is empty – if it isn’t, provide a friendly error that the form should be filled out manually.

So do you see how this works? Spiders and machines fill in fields they seen in a form – they add text to this field, and you simply ignore the interaction.

Before you complain about it, let me say it first. No. This technique is not applicable to all sites, such as news portals and such. But this will definitely help you reduce and spider related spam on those contact forms.

Geocoding in Microformats with Google

So I finished a few TextMate snippets last night to help me in the production of microformats for my client’s websites. A few little tweaks left, but all and all I’m happy with them.

Today I decided to try something new and to add some geocoding data to a new site’s “Contact Us” page address hCard. For those of you that haven’t yet really experimented with using geocoding within a microformat it is actually done quite easily. All you do is add the following code to your hCard:

<div class="geo">
	<span class="latitude">[lat number]</span>
	<span class="longitude">[long number]</span>
</div>

So, how do you get lat/long codes? Simple – you use Google Maps… Just go to http://maps.google.com and look up the location that you want to geocode. It’s good to give the found location a double-click in the map just to make sure that it is the center focused it. Then click on the “Link to this Page” button. Look up in the URL and you’ll see a ton of various query strings. Look for the ll= NOT the sll= or anything like that… it will say &ll= with a number, like so:

&ll=38.898114,-77.037163

Just after the last number will be another “&” to start the next query option, make sure you leave that last “&” out. That’s it – the first number in that string is your latitude and the second number (after the comma) in the longitude.

Happy Geocoding!

Preparing for CSS Naked Day with Ruby on Rails

So you are sitting there around the house watching reruns of Smallville and Seinfeld and you think, “I wish I could jump onto the CSS Naked Day bandwagon with my Ruby on Rails application”, well you are in luck. Conditional statements in Rails are a piece of cake and with logical expressions like “unless” we save ourselves a ton of code.

In our layout when we call our stylesheet link tag we would just add some conditional code to the end like this:

<%= stylesheet_link_tag "default"
unless (Time.now.month == 4) and (Time.now.day == 5) %>

And that’s it, show the stylesheet unless it’s April 5th. The carriage return is for the blog, this can go on one line. I do have to say, be nice to your users here, you just might break the shit out of some of your UI without your CSS. Most Rails applications have more then just a blog on them so I suggest not doing this on a production application (do I really need to be saying this?).