Полиморфные связи

[coldFlame]

А зачем в статье про полиморфные связи описывать script/generate и элементарные контроллеры?

[ognevsky]

На данный момент статья висит на главной (на самом верху!) около 30 минут. За это время появился 1 комментарий.
Это, видимо, говорит о том, что никто ничего не понял. Если убрать отсюда половину «лишнего», для большинства вся статья превратится в непонятный поток слов.
Не настолько сложно знающему человеку пролистать тривиальный код вниз, сколь сложно незнающему этот код выдумать.

[Davert]

ну мне, как программисту на пэхапэ, пллиморфные связи понятны, и юзаю их достаточно часто. Вопрос стоит ли перечитывть ради этого статью напичканную руби-кодом и вызовом генераторов…

[ognevsky]

Было бы глупо помещать в блог «Ruby on Rails» статью, руби-кодом и вызовом генераторов не напичканную :)

[Davert]

Ага, с вещами, которы и так каждый руби-реилс-программист знает ) Я на рельсах тоже писал, потому Америку статья про полиморфные связи мне не откроет. Но могла б заинтересоватьлюдей, которые пишут н адругих языках. Концепт ведь не зависит от языка программирования…

[ognevsky]

Ваши комментарии напоминают по стилю: «у меня был мак, но макос говно, поэтому я теперь опять на винду перешел».
Писать на рельсах, знать (и понимать) все, о чем написано выше и после этого писать на пхп? Что-то вы явно недоговариваете :)

[VolCh]

руби для души, пхп для денег — такой вариант даже не рассматриваете?

[ognevsky]

год—полтора назад рассматривал бы. сейчас на руби можно найти (практически без труда) хорошую работу.

[v1z]

автор писал статью для тех, кто изучает Ruby и (возможно) веб-программирование в целом.

лично мне было интересно прочитать ее, она написана понятным языком и с хорошими примерами, и правильно ответила на изначальный вопрос «что такое полиморфные связи и как их использовать в rails»

[victorI]

поддерживаю

иногда, чтобы понять, что как работает, важно создать рабочий пример, погонять его, попробовать что-то поменять, подебажить. В статье есть всё для этого необходимое. Если бы этого тривиального кода не было, часть желающих попробовать просто отсеялась

[veevtam]

Полезная статья. У меня по-поводу этого примера есть только один вопрос: как элегантно избавиться от работы с моделью определенного типа контента в контроллере?

Насколько я понимаю идеологию рельсы (я в ней новичок) — один контроллер должен работать с одной моделью, а основная модель в данном случае — Post.

[ognevsky]

Не всегда получается так, как задумано в рельсах. Ведь если мне на определенной странице нужно показать одновременно и новости, и статьи, то мне и придется из контроллера обратиться к двум моделям (если не использовать новомодные презентеры/ячейки, но до этого я еще не дорос)

[ptzn]

Отлично!

[rwz]

Некрасиво получается, что для создания модели надо трогать два класса — саму модель и Post. В этом ключе техника STI выглядит намного привлекательнее и удобнее.

[ognevsky]

Много раз уже слышал про STI, так никогда и не читал. Теперь обязательно посмотрю повнимательнее в эту сторону, спасибо

[ptzn]

Там все просто как два пальца :) В таблицу добавляется поле type, а для моделей используется обычное наследование.

[zed_0xff]

поддерживаю. как раз данный пример выглядел бы более элегантно с использованием STI.
а в качестве примера для полиморфизма можно придумать, например, приложение для комплектации компа для сборщиков.
Начать ее с «Computer has_many :parts», ну и т.д. :)
полиморфизм будет в том что Parts это могут быть CPU, MemoryModule, VideoCard и т.п.

[ognevsky]

Хорошая идея, будет время — обязательно узнаю, что же это за STI такой, да может и напишу такую статью:)

[ptzn]

Так тут уже дело не в красиво/некрасиво, а что больше подходит для конкретной задачи. STI хорошо ложиться на логику, в случае когда модели совершенно не различаются, либо различаются незначительно. Ну и, конечно же, если есть желание за счет избыточности увеличить скорость работы, но это совсем другая история.

[aokolovich]

Статья хорошая, довольно просто получилось рассказать о непростом для понимания вопросе. Мне как начинающему рельсовику подобных статей не хватает.
P.S. Можно было даже фото с рубином в титьках вставить.

[ognevsky]

Спасибо, скоро будет еще несколько статей (я надеюсь)

[v1z]

А еще можно в дополнение к статье добавить про nested attributes, которые появились в Rails 2.3

Они упрощают работу с формами, в которых используются несколько моделей.

И код можно будет оптимизировать, сначала хотел привести примеры, но потом посмотрел что комментарий уже начинает тянуть на мини-статью

Хоть это и не совсем касается полиморфных связей, но также будет полезно тем кого интересуют связи между моделями

[ognevsky]

Я думаю, что никто не будет против примеров, каким бы ни был размер коммнтария:)

[feligz]

Можно было бы сделать скринкаст ну и картинки добавить, для наглядности, для новичков. Получилось бы более компактней и опять же наглядней.

[ognevsky]

Из всех скринкастов, которые я когда-либо видел, только railscasts от Ryan Bates я могу смотреть. Остальные — неперевариваемый бред (долгие паузы, мэ'кание постоянное). Я не спешу пополнять список говно-скринкастеров:)

А картинки… Ну, разве что код вместо текста картинками выложить, но за это меня возненавидят высшие силы:)

[OmeZ]

а можно еще указать получившуюся структуру базы данных после миграций?

[ognevsky]

Файл schema.rb получился такой:

create_table "posts", :force => true do |t|
  t.string "title"
  t.boolean "published"
  t.integer "content_id"
  t.string "content_type"
  t.datetime "created_at"
  t.datetime "updated_at"
end
 
create_table "topics", :force => true do |t|
  t.text "body"
end
 
create_table "links", :force => true do |t|
  t.string "link"
  t.text "description"
end
 
create_table "podcasts", :force => true do |t|
  t.string "link"
  t.text "description"
end


Собственно, в бд структура такая же.

[Alexander_N]

Возможно, здесь было бы удобно использовать accepts_nested_attributes_for(*attr_names).
Подробности и примеры здесь: api.rubyonrails.org/classes/ActiveRecord/NestedAttributes/ClassMethods.html.

[ognevsky]

спасибо, посмотрю

[ognevsky]

я так понял, что представление остается таким же, меняется только контроллер?

[Alexander_N]

Если вы про формы, и действия по созданию, то наоборот.
Контроллер останется прежним, а во вью можно использовать api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#M001605, — есть примеры для данных случаев Nested Attributes Examples.

[ognevsky]

а, блин, запутался:)
спасибо большое!

[v1z]

я это уже предложил на несколько постов выше -)

Вот даже написал статью: vizakenjack.habrahabr.ru/blog/79595/

только кармы не хватает опубликовать, подожду немного)

[ognevsky]

мы тут щас дружно поднапряжемся, да попробуем поднять, ради такой-то статьи!

[alexandrov]

Ваши методы posts_smth_path(post) и posts_smths_path(post) можно заменить вот такими методами в хелпере:

def edit_posts_content_path(content)
    eval("edit_posts_#{content.class.to_s.downcase}_path(content)")
end

Это метод возвращающий путь для edit. Так, если content это, например, Topic, то будет возвращено значение edit_posts_topic_path(content).

Методы для show и index пишутся аналогично.