Hey, Adrian here.

Sure, please send that patch in! With Norman we’ve discussed adding multiple strategies to friendly_id a couple of times in the past. Recently, we’ve been playing with top level path names used as ids (a la GitHub) so we’re also considering extending friendly_id in that direction (for even friendlier ids).

Regards

Would you consider a patch for supporting multiple methods instead of one?

So has_friendly_id would support the following two formats:
has_friendly_id [:multiple, :methods, :work] and
has_friendly_id :one_method

Thanks.

-Nash

But I do understand what you’re saying and yes it will happen more often on your example (which is exactly my situation) but I don’t know how we can circumvent the Rails situation, I need to understand why it is that they do (or appear to) that

meanwhile, that makes sure you can do Person.find(’slug’), Employee.find(’slug-slug’) and Supervisor.find(’slugy-slugy’)

For example, suppose you want to have something like

class Person < ActiveRecord::Base
end

class Employee < Person
end

class Supervisor < Person
end

@employee = Employee.new(:name => “John Doe”)
@supervisor = Supervisor.new(:name => “John Doe”)

In this case since it uses the base class for the slug, it would not allow you to use “john-doe” for both; the second one is going to be “john-doe-2.”

For some people this would be the desired behavior, for others, I think it would be the opposite. I think ideally friendly_id would provide a way for you to choose the strategy.

I think the best long-term solution is something Adrian Mugnolo proposed to me, which is to make it possible to write your own slug generator class that makes the slugs the way you want them to.

I’ve edited the following lines on lib/friendly_id.rb and added “base_class” to the arguments …

139: slugs = Slug.find_by_name_and_sluggable_type(args.first, self.base_class.to_s)

141: slugs = Slug.find_all_by_name_and_sluggable_type(args.first, self.base_class.to_s)

now, how far did you and Keith Pitty go on the STI problem ? I’ll look at the code now, but wanted to know if I was repeating any work being currently done

again, great work, thanks

We ran into the problem of Eager Loading not workin on on the project I work on (http://www.feistypiranha.com) so we decided to fix it up.

I posted the solution that we came up with on our blog (http://www.feistypiranha.com/getting-friendly_id-to-work/). I have only done limited testing with it, but in theory all parameters should work now… So you can do :conditions => “1 = 2″, and it will correctly fail (Not return any results. Since, as far as I know, 1 != 2)

The method we changed was “find_using_friendly_id” in the SluggableClassMethods module. (Line 127)
And the updated code goes as follows:

# Finds the record using only the friendly id. If it can’t be found
# using the friendly id, then it returns false. If you pass in any
# argument other than an instance of String, then it also returns false.
def find_using_friendly_id(*args)
return false unless args.first.kind_of?(String)
slug = Slug.find_by_name_and_sluggable_type(args.first, self.to_s)
begin
# Get the class and pass our options
object_class = Module.const_get(slug.sluggable_type)
options = args.extract_options!
return object_class.find(slug.sluggable_id, options)
rescue # The class was bad, use the old slug way
return false if !slug
return false if !slug.sluggable
slug.sluggable.send(:finder_slug=, slug)
slug.sluggable
end
end

Take care everyone, hope this helps!
Robert

You can use any method to generate the friendly id, it doesn’t just have to be a column. So you coud do something like this:

has_friendly_id :title_and_username, :use_slug => true

def title_and_username
“#{user.name}-#{title}”
end