RoR и размышления о собственном frameworkе
После того, как закончил со сборкой ядра, вернулся к изучению Ruby on Rails. Наконец-то перешел от теории к практике — стал писать Интернет-магазин. Впечатления довольно противоречивые: с одной стороны, за несколько дней весьма ленивого программирования получил почти работающий прототип (осталось только оформление заказов доделать), причем с правильной структурой URL.
С другой — серверная часть разрабатывается быстро, а вот в плане верстки плюсов практически никаких. Даже то, что генерируется автоматически, выглядит так ужасно, что если делать серьезный проект, то пришлось бы переверстывать.
Еще двоякое впечатление вызвала такая штука как migrations. С одной стороны, они решают проблему обновления структуры БД, с которой я сталкивался при разработке IntB, с другой — делают это совершенно иначе, чем у меня. Я-то исходил из того, что есть структура база такая, какая должна быть, и есть текущая, и нужно увидеть разницу и добавить/убрать недостающие столбцы через какой-нибудь sqlt_diff или mysql_diff, при этом база может редактироваться через сторонний визуальный редактор, и это делается часто. И еще удивлялся, почему так мало подходящих для этой цели инструментов, хотя с проблемой сталкиваются почти все разработчики. А в Ruby on Rails нужно документировать каждое изменение БД в виде отдельной migration, и задавать изменения либо в командной строке, либо в коде файла migration. С одной стороны, много лишних трудозатрат, с другой — они гарантировано фиксируются.
А вообще, все описанное выше заставило меня вспомнить о моих давних идеях data driven framework, где разработка приложения начинается именно с того, что в визуальном редакторе описываются данные. Причем делается это не как сейчас в RoR, где в командной строке указываются только типы данных, а задается то, может ли это поле вводиться через форму, сохраняться в базу или являться вычислимым, а также нужны ли пре- и пост- обработчики поля при сохранении/загрузке. Если оно отображается в форме, то указывается способ отображения (input, radio, checkbox или вообще целый компонент) для редактирования и просмотра, краткое описание, длинное описание и справка. Потом с учетом всего этого генерируется файл и два класса модели: абстрактный, который только сохраняет и фильтрует поля и может многократно перегенерироваться, и его наследник, где реализуются всякие функции расчета и валидации. В общем, вместо того, чтобы максимально разделять frontend и backend, как сейчас делает большинство frameworkов, наоборот, максимально управлять и тем, и другим через единый интерфейс, и делать упор на минимизацию верстки, которую я терпеть не могу, ибо это трата ресурсов на то, что в моем представлении является второстепенным — интерфейсы и внешний вид.
С другой — серверная часть разрабатывается быстро, а вот в плане верстки плюсов практически никаких. Даже то, что генерируется автоматически, выглядит так ужасно, что если делать серьезный проект, то пришлось бы переверстывать.
Еще двоякое впечатление вызвала такая штука как migrations. С одной стороны, они решают проблему обновления структуры БД, с которой я сталкивался при разработке IntB, с другой — делают это совершенно иначе, чем у меня. Я-то исходил из того, что есть структура база такая, какая должна быть, и есть текущая, и нужно увидеть разницу и добавить/убрать недостающие столбцы через какой-нибудь sqlt_diff или mysql_diff, при этом база может редактироваться через сторонний визуальный редактор, и это делается часто. И еще удивлялся, почему так мало подходящих для этой цели инструментов, хотя с проблемой сталкиваются почти все разработчики. А в Ruby on Rails нужно документировать каждое изменение БД в виде отдельной migration, и задавать изменения либо в командной строке, либо в коде файла migration. С одной стороны, много лишних трудозатрат, с другой — они гарантировано фиксируются.
А вообще, все описанное выше заставило меня вспомнить о моих давних идеях data driven framework, где разработка приложения начинается именно с того, что в визуальном редакторе описываются данные. Причем делается это не как сейчас в RoR, где в командной строке указываются только типы данных, а задается то, может ли это поле вводиться через форму, сохраняться в базу или являться вычислимым, а также нужны ли пре- и пост- обработчики поля при сохранении/загрузке. Если оно отображается в форме, то указывается способ отображения (input, radio, checkbox или вообще целый компонент) для редактирования и просмотра, краткое описание, длинное описание и справка. Потом с учетом всего этого генерируется файл и два класса модели: абстрактный, который только сохраняет и фильтрует поля и может многократно перегенерироваться, и его наследник, где реализуются всякие функции расчета и валидации. В общем, вместо того, чтобы максимально разделять frontend и backend, как сейчас делает большинство frameworkов, наоборот, максимально управлять и тем, и другим через единый интерфейс, и делать упор на минимизацию верстки, которую я терпеть не могу, ибо это трата ресурсов на то, что в моем представлении является второстепенным — интерфейсы и внешний вид.