# Hard-coding IDs

**URL:** <https://www.ruby-forum.com/t/hard-coding-ids/151463>\
**Category:** Rails\
**Created:** [October 21, 2008, 9:29pm UTC](https://www.ruby-forum.com/t/hard-coding-ids/151463 "2008-10-21T21:29:44Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![nick](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f9ae1b/32.png) [@nick](https://www.ruby-forum.com/u/nick)\
**Post date:** [October 21, 2008, 9:29pm UTC](https://www.ruby-forum.com/t/hard-coding-ids/151463/1 "2008-10-21T21:29:44Z")

</div>

Should HTML DOM IDs be hard-coded throughout a Rails app, or stored  
within…an appropriate model or helper or …?

Here’s an example problem:

/neighbourhoods/1/map/ has a form:

# map.html.erb

\<% form\_remote\_tag … :html =\> {:id =\> ‘map-filter-form’} do %\>

When the page loads, the form needs to be submitted:

# public/javascript/submit\_map\_filter\_form.js

Event.observe(window, ‘load’, function() {  
$(‘map-filter-form’).onsubmit();  
});

Thus, I include the Javascript file mentioned above:

# map.html.erb

\<%= javascript\_include\_tag ‘submit\_map\_filter\_form’ %\>

This feels wrong because the form’s DOM ID (“map-filter-form”) is hard-  
coded in multiple locations (the view, and the Javascript file). As I  
add functionality that uses the form, the number of places where the  
form’s DOM ID is hardcoded will increase.

Does anyone have suggestions or comments for how to deal with this?

Cheers,  
Nick

---

<div class="post-metadata">

**Author:** ![nick](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f9ae1b/32.png) [@nick](https://www.ruby-forum.com/u/nick)\
**Post date:** [October 21, 2008, 9:32pm UTC](https://www.ruby-forum.com/t/hard-coding-ids/151463/2 "2008-10-21T21:32:08Z")

</div>

When it comes to HTML… it’s kind of hard to not… hard-code it.  
Either you end up having some dictionary that is a pain to manage or  
you just have good conventions.

This is what we do at Planet Argon to keep things a bit more organized.

- 

[http://www.robbyonrails.com/articles/2007/08/01/designers-developers-and-the-x\_-factor](http://www.robbyonrails.com/articles/2007/08/01/designers-developers-and-the-x_-factor)

Good luck!

Robby

On Tue, Oct 21, 2008 at 10:32 AM, Nick [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> When the page loads, the form needs to be submitted:  
> coded in multiple locations (the view, and the Javascript file). As I  
> add functionality that uses the form, the number of places where the  
> form’s DOM ID is hardcoded will increase.
> 
> Does anyone have suggestions or comments for how to deal with this?
> 
> Cheers,  
> Nick
> 
> >

–  
Robby R.  
Chief Evangelist, Partner

PLANET ARGON, LLC  
design // development // hosting

> **[Planet Argon](https://www.planetargon.com/)**
>
> Planet Argon is a Ruby on Rails development agency specializing in maintenance and support for existing Rails apps. Based in Portland, OR, Planet Argon has been a member of the Rails community since 2004.

[http://www.robbyonrails.com/](http://www.robbyonrails.com/)  
aim: planetargon

+1 503 445 2457  
+1 877 55 ARGON [toll free]  
+1 815 642 4068 [fax]

---

<div class="post-metadata">

**Author:** ![nick](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f9ae1b/32.png) [@nick](https://www.ruby-forum.com/u/nick)\
**Post date:** [October 21, 2008, 9:33pm UTC](https://www.ruby-forum.com/t/hard-coding-ids/151463/3 "2008-10-21T21:33:20Z")

</div>

One solution I can think of is to put the DOM ID into an appropriate  
model. In this case, I’d make RentalMap#map\_filter\_form\_dom\_id return  
“map-filter-form”.

However, if I do that, the contents of submit\_map\_filter\_form.js would  
need to be placed elsewhere, because RentalMap#map\_filter\_form\_dom\_id  
can’t be called from the Javascript file.

I could do something like this:

Add a class method to the RentalMap model for the DOM ID:

# rental\_map.rb

class RentalMap  
MAP\_FILTER\_FORM\_DOM\_ID = ‘map-filter-form’

```
def self.map_filter_form_dom_id
  MAP_FILTER_FORM_DOM_ID
end

```

end

The form in /neighbourhoods/1/map/ calls the new method:

# map.html.erb

\<% form\_remote\_tag … :html =\> {:id =\>  
RentalMap.map\_filter\_form\_dom\_id} do %\>

Move the Javascript into a partial so that the new method can be  
called:

# \_submit\_map\_filter\_form.html.erb

The partial above must be rendered:

# map.html.erb

\<%= render :partial =\> ‘submit\_map\_filter\_form’ %\>

But that doesn’t feel right, for several reasons:

1. Now there’s a partial whose sole purpose is to spit out some  
Javascript code (as opposed to HTML code).
2. The form’s DOM ID doesn’t feel like it belongs in a model in the  
first place.
3. As the number of DOM IDs that shouldn’t be hard-coded increases,  
the models get filled up with these tiny methods.

I’d love to hear any comments and suggestions you guys have. Thanks!  
Nick

---

<div class="post-metadata">

**Author:** ![nick](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f9ae1b/32.png) [@nick](https://www.ruby-forum.com/u/nick)\
**Post date:** [October 21, 2008, 10:04pm UTC](https://www.ruby-forum.com/t/hard-coding-ids/151463/4 "2008-10-21T22:04:04Z")

</div>

On Oct 21, 1:48 pm, “Robby R.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Robby  
> Hi Robby. Thanks for the link and for sharing those conventions. The  
> idea you guys decided upon definitely helps mitigate problems that  
> involve renaming IDs.

Hard-coding the DOM IDs still doesn’t sit right with me, though. It  
feels like the string-version of “magic” numbers, which was beaten out  
of me many, many years ago =P

Thanks again,  
Nick

---

<div class="post-metadata">

**Author:** ![nick](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f9ae1b/32.png) [@nick](https://www.ruby-forum.com/u/nick)\
**Post date:** [October 21, 2008, 9:36pm UTC](https://www.ruby-forum.com/t/hard-coding-ids/151463/5 "2008-10-21T21:36:16Z")

</div>

On Oct 21, 1:48 pm, “Robby R.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Robby  
> By the way, did you write a follow-up to the blog post above? I looked  
> through your archives and a couple of tags, but didn’t find it.  
> -Nick

---

<div class="post-metadata">

**Author:** ![nick](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f9ae1b/32.png) [@nick](https://www.ruby-forum.com/u/nick)\
**Post date:** [October 21, 2008, 11:35pm UTC](https://www.ruby-forum.com/t/hard-coding-ids/151463/6 "2008-10-21T23:35:51Z")

</div>

For anyone else who finds this thread…

There’s a plugin called “embedded javascripts”:  
[http://agilewebdevelopment.com/plugins/embedded\_javascripts](http://agilewebdevelopment.com/plugins/embedded_javascripts)

In a nutshell, it defines ActionView::Base#include\_javascript , which  
takes the name of a Javascript file as an argument, processes any ERB  
in the JS file, and returns the JS code sandwiched between \<script  
type=“text/javascript” …\> and .

That sounds like a good tool to use in a solution for the originally-  
stated problem. However, it doesn’t feel right to me. The Javascript  
file will never be cached by browsers, and it adds another call to  
read from the file system, which will slow things down a bit. However,  
for a small app, I think it’s a great tool.

Dan W. released two plugins - MinusR and MinusMOR - with the latter  
being an update of the former:  
[http://www.danwebb.net/2006/11/17/rjs-minus-r](http://www.danwebb.net/2006/11/17/rjs-minus-r)  
[http://www.danwebb.net/2006/11/24/minusmor-released](http://www.danwebb.net/2006/11/24/minusmor-released)

I like MinusMOR, as it doesn’t hijack the .rjs file extension.  
However, I don’t think it’s a tool that could [easily] be used to  
solve the original problem. But it’s still a pretty cool plugin!

In the end, I’ve decided to hard-code HTML elements’ DOM IDs in views,  
partials, RJS templates, Javascript files, and wherever else. On top  
of that, every element that is touched by Javascript will have its DOM  
ID prefixed with “x\_”. This will make it very clear which elements’  
DOM IDs shouldn’t be changed on a whim.

What I’ve just explained is Robby R.'s approach. He explained it  
quite well in a blog post:  
[http://www.robbyonrails.com/articles/2007/08/01/designers-developers-and-the-x\_-factor](http://www.robbyonrails.com/articles/2007/08/01/designers-developers-and-the-x_-factor)

Cheers,  
Nick