Don't use #to_s to display models in Administrate.

[rikkipitt]

Just a minor note to request the documentation of the use of the to_s method for better representing objects across the various Administrate dashboards. E.g. has_many select lists and belongs_to on index lists. This might catch out some newer Rails/Ruby users if not explicitly mentioned...

Something along the lines of:

to_s is the standard Ruby method for converting an object to a string. You can define to_s on your model class when you want a custom string representation.

Example:

class Tag < ActiveRecord::Base
  def to_s
    name
  end
end

Thus instead of displaying #<Tag:0x007fad07b7ad98>, we can display the actual name of the tag.

Thoughts?

[c-lliope]

@rikkipitt good call. We've gone back and forth on to_s a little bit (see #5 and #70), but you're right that it should absolutely be documented.

Where would you expect to see it? I'm thinking of adding a note to the README and to https://administrate-docs.herokuapp.com/getting_started.

[rikkipitt]

@Graysonwright thanks for the quick reply. I missed those pull requests, cheers for referencing them.

Albeit a short page, could it warrant its own section under something like "Customising Fields"? It might get lost in the Getting started page...

I've used RailsAdmin extensively and I believe they try :name or :title before falling back to a default with the object id... Looks like this has been mulled over by you guys too.

[c-lliope]

Yeah, it's hard to get a decent solution without getting too "magical". 😄

[jcutrell]

I think I'd like to see something like a method to override in the model - administrate_title, possibly - rather than to_s, since other things (like loggers) may rely on to_s.

[c-lliope]

@jcutrell I like that idea - it might make it easier to fallback to a sensible default.

It might work well in a helper method, like:

def display_record(record)
  record.try(:administrate_title) || "#{record.class} ##{record.id}"
end

[marisawallace]

I agree with @jcutrell 's suggestion. Using to_s for Administrate's representation of the model makes me a bit nervous, because there's no way to isolate admin-specific display logic from how the Model is represented elsewhere in the app (in the console, etc.).

I would consider even going a step further, and have users put their administrate_title methods in Administrate-specific views, rather in the Models themselves. This might make it clearer that the display logic is admin-specific.

[rikkipitt]

Agreed. We need to make sure things don't get too DSL'ly as that's the first guideline principle of the whole project...

[jcutrell]

Perhaps it's best placed in the dashboard class somehow? Or maybe some kind of presentational class can be generated to accompany the dashboard?

I agree - having an extra method on the model just for display doesn't seem right to me. I think something like a ViewModel (or whatever term you want to use) should wrap the model instance and decorate it with administrate-specific methods that delegate to underlying fallback methods when not defined by the end user.

On Nov 6, 2015, at 10:33 AM, Max Wallace notifications@github.com wrote:

I agree with @jcutrell 's suggestion. Using to_s for Administrate's representation of the model makes me a bit nervous, because there's no way to isolate admin-specific display logic from how the Model is represented elsewhere in the app (in the console, etc.).

I would consider even going a step further, and have users put their administrate_title methods in Administrate-specific views, rather in the Models themselves. This might make it clearer that the display logic is admin-specific.

—
Reply to this email directly or view it on GitHub.

[c-lliope]

@jcutrell I think at the moment the Dashboard class is the best place for this. If we find ourselves adding a lot of view-specific methods in there, we can consider extracting a decorator layer.

I'm working on a PR now.

[c-lliope]

#191 introduces a fix for this issue - please give feedback there!

[lucianosousa]

Why are you guys not using the to_param rails method?
http://api.rubyonrails.org/classes/ActiveModel/Conversion.html#method-i-to_param

[marisawallace]

@lucianosousa I think the difference here is that we're looking to customize how the model identifier is displayed for the sake of an admin user (who may be non-technical), rather than display a serialized form of the model's primary key.

Admins (or at least the ones I'm developing for) don't care about IDs-- they want to see something more descriptive, and what that means changes based on the domain.

[lucianosousa]

@maxkwallace I always - or most of the cases - assume the same URL in admin and regular pages.
I - most of the times - override the to_param just using the name/title variable, using ID's just un rescue cases.
eg:

class User < ActiveRecord::Model

  def to_param
    if name
      name.parameterize
    else
      id
    end
  end

end

I mean, there is none complex stuff in this issue. It's better use some default method to to this than generate a lot of complex code for different models/types

[c-lliope]

@lucianosousa - I think we're talking about different things. This PR isn't related to URLs at all. We're changing how labels like these get generated in the app:

I think you might be talking about the URLs, which are being generated by the to_param method (see this code).

[lucianosousa]

hum, I see.

my fault