0

friendly_idスラッグを使用して、適切にセットアップし、すべてが機能します。

私が抱えている問題は、Tagモデル (FriendlyId がアタッチされているモデル) の名前の一部を HTML エスケープする必要があることです。

c++またはのような名前.net

を実行するとTag.find_each(:&save)、すべてのスラッグが生成されました....しかし、これらの名前のタグでは、次のことが起こりました。

> c = Tag.where(:name => "c++")
  Tag Load (0.9ms)  SELECT "tags".* FROM "tags" WHERE "tags"."name" = 'c++'
 => [#<Tag id: 2, name: "c++", num_questions: 187598, created_at: "2013-03-23 07:02:09", updated_at: "2013-03-29 15:34:09", questions_count: 87, slug: "c">] 
> Tag.where(:name => ".net")
  Tag Load (0.9ms)  SELECT "tags".* FROM "tags" WHERE "tags"."name" = '.net'
 => [#<Tag id: 142, name: ".net", num_questions: 149074, created_at: "2013-03-23 07:09:47", updated_at: "2013-03-29 15:34:10", questions_count: 85, slug: "net">] 
1.9.3p392 :012 > Tag.where(:name => "c#")
  Tag Load (1.0ms)  SELECT "tags".* FROM "tags" WHERE "tags"."name" = 'c#'
 => [#<Tag id: 38, name: "c#", num_questions: 435620, created_at: "2013-03-23 07:03:27", updated_at: "2013-03-29 15:34:10", questions_count: 130, slug: "c--3">] 

nameそれらのそれぞれのスラッグに注意してください - そしてそれらがどのように各レコードの に適切に対応していないか.

これを修正するにはどうすればよいですか?

4

1 に答える 1

1

Friendly_id (少なくとも で呼び出す場合:use => :slugged) は、URL で見栄えがよくなるように、フィールド値を「クリーンアップ」しようとします。その動作を変更したい場合は、normalize_friendly_idをオーバーライドできます。ただし、その場合は、スラッグを URL エンコードする必要があり#ます。これは、URL のようなものはすでに特別な意味を持っているためです。

後でこれに出くわした人にとって、有効な解決策は:use_slugged、タグの生の名前を使用し、Rails のリンク ヘルパーによって自動的にエスケープされる代わりに、 Friendly_id の使用を避けることでした。resources :tags, :constraints => { :id => /.*/ }「.net」タグの場合、 Rails がドットをパス区切りとして解釈しないようにするために、ルートを変更する必要もありました。

于 2013-03-29T17:13:26.860 に答える