blog@osd.se

In my quest to figure out why Prototype’s request method sent all my submit buttons, I stumbled upon this, not so pretty, piece of code:

if (value != null && (element.type != 'submit' || (!submitted &&
    submit !== false && (!submit || key == submit) && (submitted = true)))) {

It’s from a changeset in Prototype’s Trac page and is supposed to fix this bug.

The reason I started reading the code was that I’m using multiple submit tags with different names. Instead of just varying the value, I set the type tag to “submit”. Example:

<input name="create" value="Create New..." type="submit" />

and in Rails I check if params[:create] is set to see if that button was pressed or not. Perhaps this is really bad for some reason that I have missed, I don’t know (it does work in my version of IE6 aswell), but the fix doesn’t solve my problem. It just solves when using multiple input tags with the name submit and vary the name. The reason I don’t like looking what the value attribute is set to, is that it’s part of the design and should be free to change, without having to modify the controller. Of course, hidden values are always an alternative, but requiring Javascript to use a simple form seems wrong.

Anyway, I opened up my prototype.js and started reading the code and found the above piece of code. Note the assignment in the end of the second row. I think it’s intentional.

Ni vill inte titta på den här, tro mig. Man fastnar.

Ubisoft visar sig vara ett företag man bör undvika. Det är nästan så att man kan tro att det är ett skämt, men det finns en länk till en riktig pressrelease.

Just när jag trodde att jag hade sett alla Mac vs. PC-filmer. Lite ny var den i alla fall, men den är visst redan två månader gammal på Youtube.

Update : I was going to write a post about the changes I made to acts_as_taggable to get user support, but I just switched to has_many_polymorphs (HMP). I wanted self-referencing tags (being able to tag tags) and HMP provided that with little work. HMP also seems to work directly with will_paginate, which is great. The per user tags weren’t harder to get in HMP than in acts_as_taggable_on_steroids.

Oh the title, I’m so funny! I have to be the first one to ever think of that. Right…

This became another text in English, mainly because the follow up (if I write it) could possibly be useful to more people. We’ll see what happens.

Anyway, about a month ago, I decided to learn a bit of Ruby on Rails. I hadn’t tried Ruby before either, so learning Ruby was/is part of the process, but you can come a long way without having to study the language very deep. Most stuff works as you think they would, after learning the basics. In general I think it’s a nice language, but my knowledge isn’t very good yet.

Rails is wonderful to work with in general. I haven’t really done any web development in many years now (except for some minor WordPress hacking to modify it for my needs, but even that was more than a year ago, and a simple summer course two years ago). Back then I knew a lot less (doh!) and most stuff I wrote was quite poorly written, I realize now, in terms of flexibility and security (Hello SQL injection!). I sure as hell wrote all my SQL statements by hand, though they were quite simple, and in general it usually became quite a mess quickly. I’m sure there existed some projects that the same idea as Rails, but I didn’t know about them then.

Something that is a bit annoying now, is that for my project I wanted two things; tags and pagination (split up something over several pages, to give the user a better overview. Nothing fancy really). As it turns out, the built-in paginate module is deprecated and will be removed in the next version (it’s already gone from Edge Rails) and both the gem and plugin named acts_as_taggable are old and bad, in different ways (they aren’t the same).

The pagination wasn’t hard to solve. I found the plugin will_paginate, which works great. All good. For now…

The tagging wasn’t quite as easy. There are quite a few plugins that tries to (and does) fix what acts_as_taggable did, but better. One is has_many_polymorphs, which is a fair bit more complex and flexible, but I didn’t really need that. The guide he has, on his blog, to use the plugin for tagging is about converting from acts_as_taggable to has_many_polymorphs, which includes a bit more work than it felt worth it for me. I ended up using acts_as_taggable_on_steroids (puh, long name) which is quite simple. It has (or had, I haven’t checked the last version yet) a bug with migrations, but in general it was easy to work with and to work around the bug.

I also wanted to tie my tags to users, because the project isn’t about a community and all user data is private to each user. There’s also a third plugin for tagging, acts_as_taggable_redux, and it has user support already, but it turns out that he ties the tagging (the connection between the tag and the item) to the user instead of the tag. That’s great for community like sites, like last.fm, where all tags are global, but that wasn’t what I wanted. I also found a post about adding user support to acts_as_taggable, but it had the same user connections. Instead I decided that it was easy enough to do myself. I’m not saying that it’s hard, it’s not, but if someone else had done it already and had working plugin, I would rather use that).

It turned out to be even easier than I imagined at first. Rails has some really great tools. After adding a simple user_id column to the tag model, I could do things like

user.tags.find_by_name(tag_name)

which looks great in terms of readability. I might post a summary later on what I changed to get this working.

Now to the real problem: get them to work together. It wasn’t quite as easy to get will_paginate to work with acts_as_taggable_on_steroids. Find_tagged_with works directly on the type you want to tag, but will_paginate does that too. There might be easier ways than how I solved it, I don’t claim to be an expert after just a week (when I did this) with RoR. My solution wasn’t very nice either. I basically runs find_tagged_with, but returns the database request, instead of executing it and returning the result, modify the SQL statement a bit and then use paginate_by_sql to turn it into a paginatable (cute word) object. The correct solution is probably to modify how acts_as_taggable_on… works and extend it with the things needed to paginate the results. If I understand the comments on the acts_as_taggable_on_steroid page, someone might have done that now. I have to read up on that.