rails if object.nil ? then magic '' in views ?

Question

C'est l'une de ces choses qui sont peut-être si simples que je ne la trouverai jamais parce que tout le monde la connaît déjà.

J'ai des objets dont je dois vérifier la présence de nil dans mes vues pour ne pas déréférencer un nil :

<%= if tax_payment.user; tax_payment.user.name; end %>

Ou je pourrais faire cette variante :

<%= tax_payment.user ? tax_payment.user.name : '' %>

C'est donc correct ... pour la plupart des langues. Mais j'ai l'impression qu'il doit y avoir un peu de ruby ou de railness brillant qui me manque encore si c'est le mieux que je puisse faire.

Answer 1

Qu'en est-il :

<%= tax_payment.user.name if tax_payment.user %>

Answer 2

Vous pouvez également essayer la nouvelle syntaxe Object.try, excusez le jeu de mots.

C'est dans le tout nouveau Rails 2.3 :

tax_payment.try(:user).try(:name)

Answer 3

J'ai toujours préféré cette approche :

modèle :

class TaxPayment < ActiveRecord::Base
  belongs_to :user
  delegate :name, :to=>:user, :prefix=>true, :allow_nil=>true
end

vue :

<%= tax_payment.user_name %>

http://apidock.com/rails/Module/delegate

Answer 4

La communauté Ruby a porté une attention toute particulière à l'automatisation de cet idiome. Voici les solutions que je connais :

• essayez en Ruby on Rails
• Un autre essayez
• etet
• Une sécurité accrue etet
• Noyau::ergo
• send-with-default
• peut-être
• _ ?
• if-not-nil
• des tortues !
• méthode_ dans le style Groovy
• à faire ou à ne pas faire

Le plus connu est probablement le méthode d'essai dans Rails. Cependant, il a reçu un peu de critique .

En tout cas, je pense que la solution de Ben est parfaitement suffisante.

Answer 5

Pour une solution un peu plus complète, vous pouvez consulter l'outil Introduire l'objet Null Refactoring . La mécanique de base de ce remaniement est qu'au lieu de vérifier que les éléments suivants sont présents nil dans le client vous devez plutôt vous assurer que le code fournisseur ne produit jamais un nil en premier lieu, en introduisant un contexte spécifique objet nul et de le renvoyer.

Donc, renvoyer une chaîne vide, un tableau vide, un hachage vide ou un client vide spécial ou un utilisateur vide ou quelque chose d'autre au lieu de juste nil et vous n'aurez jamais besoin de vérifier si nil en premier lieu.

Donc, dans votre cas, vous auriez quelque chose comme

class NullUser < User
    def name
        return ''
    end
end

Cependant, en Ruby, il existe en fait une autre manière, assez élégante, de mettre en œuvre le "Introduce Null Object Refactoring" : vous n'avez pas besoin de introduire un objet nul, car nil es déjà un objet ! Donc, vous pourriez faire du singe-patching nil pour qu'il se comporte comme un NullUser - cependant, tous les avertissements et pièges habituels concernant monkey-Parcheando s'appliquent encore plus fortement dans ce cas, puisque faire de nil avaler silencieusement NoMethodError ou quelque chose comme ça peut totalement perturber votre expérience de débogage et rendre realmente difficile de retrouver les cas où il y a un nil qui ne devrait pas être là (par opposition à une nil qui sert d'objet nul).