Встаю на рельсы

Пробовал. Даже как-то находил там ссылку на linux-версию. Сейчас зашёл, глянул, не нашёл сразу и закрыл. Прокрутка по миниатюре файла очень годное решение, в прошлый раз понравилось.

Я думаю что в большинстве случаев добавление и апдейт модели в базе все таки задача чуть менее тривиальная чем простой инсерт набора полей. Часто требуется как минимум валидация данных, а чаще требуется специфичная логика характерная только для конкретной модели, так что методы create и update всетаки приходится писать руками а read, fetchAll и pager я обычно реализую в абстрактном классе, так что в любом ООП языке можно избежать написания лишнего кода, от фреймфорка это не зависит. А дженерики и скаффолдинг, как я понял, нужны в основном для быстрого прототипирования.

> Часто требуется как минимум валидация данных, а чаще требуется специфичная логика характерная только для конкретной модели, так что методы create и update всетаки приходится писать руками а read


похоже ты не дочитал еще доку по рельсам)
все валидация должна быть в модельке, а не контроллере.
а дополнительная логика - в фильтрах на before_save, опять же в M.

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

речь маленько о другом шла. Я хочу сказать что скаффолдинг и дженерики не очень применимы на реальных проектах, так как подогнать работу со всеми моделями под одну схему вряд ли возможно.

Если метод контроллера будет иметь больше логики, чем должно быть, то логично будет описание этого метода отдельно. Однако, таких методов всегда крайне мало. Крайне! На Rails 90% методов контроллеров являются аналогами того, что генерит скаффолдинг. Они не меняются, оставляя стандартную логику CRUD. Для таких целей логично использовать KISS-концепцию. В Django это дженерики.

Для таких целей логично использовать KISS-концепцию.

С этим не спорят.

В Django это дженерики.

А в Rails - это соответствующие gems.

Изначально утверждалось, что эти дженерики - фишка в Django которая откинула на несколько лет назад RoR с технологической точки зрения. Но это, не так.

>в Rails - это соответствующие gems.
Лол! Как ты можешь говорить на эту тему, если ты считаешь что Django Generics это тоже самое, что и Ruby Gems?
Если же ты говоришь о том, что есть какой-то гем, который делает то, что делают дженерики в рельсах - давай его в студию. Только и это ничего не изменит, ведь все Rails-разработчики пишут с нуля. Да, я знаю достаточно Rails-разработчиков и понимаю что да как.

дженерики - фишка в Django которая откинула на несколько лет назад RoR

Нет, конечно. Это не так. Просто концепция была лучше и додумывала идею Rails, но сам Django не так и далеко ушёл от RoR.

Но это, не так.

Нельзя не признать что дженерики гениальны, что они сильно улучшают разработку и их отсутствие в Rails есть странная тенденция, говорящая только о застое в их развитии.

> Как ты можешь говорить на эту тему, если ты считаешь что Django Generics это тоже самое, что и Ruby Gems?
Где говорил, что это _то же самое_? Я привел пример, когда есть на Rails CRUD варианты при которых на 4 модели не надо 16 методов.

который делает то, что делают дженерики в рельсах - давай его в студию

Ссылка была выше,

Только и это ничего не изменит, ведь все Rails-разработчики пишут с нуля.

ага. Конечно. Только та же статистика http://rubygems.org/gems говорит об обратном.

Да, я знаю достаточно Rails-разработчиков и понимаю что да как.

Любители велосипедостоители есть в любом языке/фреймворке.

Нельзя не признать что дженерики гениальны

:)

и их отсутствие в Rails есть странная тенденция, говорящая только о застое в их развитии.

Есть разные технологии. Есть функциональное и объектно-ориентированное программирование. И это хорошо. Разнообразие дает возможность нормально эволюционировать языкам/фреймворкам.
Не вижу здесь проблем.