Pull to refresh

Comments 37

А зачем в статье про полиморфные связи описывать script/generate и элементарные контроллеры?
На данный момент статья висит на главной (на самом верху!) около 30 минут. За это время появился 1 комментарий.
Это, видимо, говорит о том, что никто ничего не понял. Если убрать отсюда половину «лишнего», для большинства вся статья превратится в непонятный поток слов.
Не настолько сложно знающему человеку пролистать тривиальный код вниз, сколь сложно незнающему этот код выдумать.
UFO just landed and posted this here
ну мне, как программисту на пэхапэ, пллиморфные связи понятны, и юзаю их достаточно часто. Вопрос стоит ли перечитывть ради этого статью напичканную руби-кодом и вызовом генераторов…
Было бы глупо помещать в блог «Ruby on Rails» статью, руби-кодом и вызовом генераторов не напичканную :)
Ага, с вещами, которы и так каждый руби-реилс-программист знает ) Я на рельсах тоже писал, потому Америку статья про полиморфные связи мне не откроет. Но могла б заинтересоватьлюдей, которые пишут н адругих языках. Концепт ведь не зависит от языка программирования…
Ваши комментарии напоминают по стилю: «у меня был мак, но макос говно, поэтому я теперь опять на винду перешел».
Писать на рельсах, знать (и понимать) все, о чем написано выше и после этого писать на пхп? Что-то вы явно недоговариваете :)
руби для души, пхп для денег — такой вариант даже не рассматриваете?
год—полтора назад рассматривал бы. сейчас на руби можно найти (практически без труда) хорошую работу.
автор писал статью для тех, кто изучает Ruby и (возможно) веб-программирование в целом.

лично мне было интересно прочитать ее, она написана понятным языком и с хорошими примерами, и правильно ответила на изначальный вопрос «что такое полиморфные связи и как их использовать в rails»
UFO just landed and posted this here
поддерживаю

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

Насколько я понимаю идеологию рельсы (я в ней новичок) — один контроллер должен работать с одной моделью, а основная модель в данном случае — Post.
Не всегда получается так, как задумано в рельсах. Ведь если мне на определенной странице нужно показать одновременно и новости, и статьи, то мне и придется из контроллера обратиться к двум моделям (если не использовать новомодные презентеры/ячейки, но до этого я еще не дорос)
Некрасиво получается, что для создания модели надо трогать два класса — саму модель и Post. В этом ключе техника STI выглядит намного привлекательнее и удобнее.
Много раз уже слышал про STI, так никогда и не читал. Теперь обязательно посмотрю повнимательнее в эту сторону, спасибо
Там все просто как два пальца :) В таблицу добавляется поле type, а для моделей используется обычное наследование.
поддерживаю. как раз данный пример выглядел бы более элегантно с использованием STI.
а в качестве примера для полиморфизма можно придумать, например, приложение для комплектации компа для сборщиков.
Начать ее с «Computer has_many :parts», ну и т.д. :)
полиморфизм будет в том что Parts это могут быть CPU, MemoryModule, VideoCard и т.п.
Хорошая идея, будет время — обязательно узнаю, что же это за STI такой, да может и напишу такую статью:)
Так тут уже дело не в красиво/некрасиво, а что больше подходит для конкретной задачи. STI хорошо ложиться на логику, в случае когда модели совершенно не различаются, либо различаются незначительно. Ну и, конечно же, если есть желание за счет избыточности увеличить скорость работы, но это совсем другая история.
Статья хорошая, довольно просто получилось рассказать о непростом для понимания вопросе. Мне как начинающему рельсовику подобных статей не хватает.
P.S. Можно было даже фото с рубином в титьках вставить.
Спасибо, скоро будет еще несколько статей (я надеюсь)
А еще можно в дополнение к статье добавить про nested attributes, которые появились в Rails 2.3

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

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

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

А картинки… Ну, разве что код вместо текста картинками выложить, но за это меня возненавидят высшие силы:)
а можно еще указать получившуюся структуру базы данных после миграций?
Файл 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
Собственно, в бд структура такая же.
я так понял, что представление остается таким же, меняется только контроллер?
а, блин, запутался:)
спасибо большое!
я это уже предложил на несколько постов выше -)

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

только кармы не хватает опубликовать, подожду немного)
мы тут щас дружно поднапряжемся, да попробуем поднять, ради такой-то статьи!
Ваши методы 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 пишутся аналогично.
Only those users with full accounts are able to leave comments. Log in, please.