sukria.net

I’ve uploaded a new developer release of Coat::Persistent to the CPAN. In this version, the modules Cache::FastMmap and DBD::CSV are made optional (they were mandatory dependencies until then). Moreover, Coat::Persistent now uses DBIx::Sequence for primary keys generation.

After thinking a lot to the future of that tiny ORM (which is actually very small, unfinished and questionable) I came to a conclusion: Class:DBIx is in the place and just rules. That’s an amazing ORM and is really a great module to use. -I’m aware what follows in that blog entry may sound contradictory- I work daily with Ruby on Rails, but I just love Perl and the goodness of CPAN, I love writing Perl code, I love writing Perl modules ; I also find Rails’ORM amaizingly well designed, easy-to-use and scalable. I like the choices made, well, I like how you can feel your database through that object-mapping abstraction layer that ActiveRecord provides.

My point here is not to discuss Class::DBIx, but rather to underline how Rails’ ActiveRecord is something worth looking at, and something - I think - Perl lacks.

I may be wrong, but I feel like some Perl developers around could agree, I hope. I also hope I won’t trigger the anger of someone involved with Class::DBIx, which, let me say it again, is a great module.

My plan here is to take the ActiveRecord API, and try to upgrade Coat::Persistent, piece by piece, in order to get as close as possible to it. That’s an exciting challenge, and could give me enough intellectual food for the next months.

I may be targetting something too large for me, I may be taking the wrong path, but I feel like following the spirit of Perl taking that direction : There’s more than one way to do it, isn’t it?

It’s been a couple of months since I’ve started playing with Rails. I must say (fear the buzz) that it just kicks your ass.

One of the stuff I really like in Rails is the scriptaculous library integration: you have a couple of easy-to-use functions for generating JavaScript voodoo. One of them being draggable_element() which allows you to drag a random object of the DOM and drop it somewhere.

I’m using that function in one of my Rails project and I discovered a bug that occurs with last versions of Mozilla Firefox (does not seem to affect IE). When using draggable_element() on a link item a conflict occurs when dropping the link on the page, making the browser to follow the link. It looks like something went wrong with the overload of the “onMouseDown” event.

As I just had to use draggable_element() on link items and as I found nothing about that issue after Googling a bit, I started writing a fix which led to a new helper called link_to_draggable().

The idea behind the fix is simple (and of course a bit crappy-but-working): a flag is set to tell if the link should be followed or not. That flag will be updated accordingly when a regular click is performed, and when a drag starts.

Here is how to use it.

The first two args are the same as the ones used by link_to(): the name and url of the link. The third argument is a hashtable of options to pass to the link_to() call. The last argument is a hashtable of options to pass to draggable_element().

Now here is the code, if you like to use that helper thingy in your Rails app.

Of course that could be done better, the best thing to do would be to fix draggable_element() itself, if you ask me.
Anyway I had to fix that bug, and in the meantime, that solution just does the job for me, maybe it does also for you.