Спасибо ребят, столько офигенных фич. Отдельное спасибо за датагрип — от pgAdmin глаза болят )) Осталось запилить нормальный рестор кастомных бекапов для постгреса, и про pgAdmin можно забыть. Может не я один такой, вдруг кому еще надо, vote pls https://youtrack.jetbrains.com/issue/DBE-4293
Вдруг кому пригодится — используем Goose Parser, очень довольны. Работает с фантомом, позволяет декларативно описать действия пользователя и хранить их в обычном JSON. Расширяемый, если надо добавить своих фишек.
Код, про который идет речь в статье, используется в нескольких проектах, где есть сотни вьюшек. Каждый раз думать о том свойство где-то или метод реально напрягает.
Каждый волен организовывать архитектуру приложения как ему угодно. Autodafe не мешает отдавать ответом параметры, а шаблон компоновать на клиенте. В этом случае должна быть довольно развитая клиентская часть, а Autodafe — серверный фреймворк, поэтому такие вопросы я не освещаю.
Просто в действии контроллера фокус на то, чтобы скомпоновать правильный ответ. А запрос уже вторичен, он свое дело сделал и использует чаще все только для взятия параметров.
ADWiki задумана как нечто более легкое, без такого нагромаждения скриптов. Документация extjs на некоторых страницах подвешивает у меня браузер на пару секунд. Хотя безусловно по функционалу jsduck сейчас куда круче.
Там не просто свойства, а как раз гетткры и сеттеры, которые выглядят как задание свойств. Реализуются при помощи родного Object.defineProperty
Задать сеттер на лету можно вот так:
user._.name.set = function(value, descriptor){ descriptor.value = do_something_with( value ); }
и использовать соответственно просто как свойство:
user.name = 'Vasya';
Ну или можно в самом классе переопределить метод set_attribute и задавать атрибуты вобще как душе угодно, при этом использоваться они все равно будут как свойства.
В статье описывается базовый класс для моделей. Для моделей, хранящихся в БД, есть специальный класс ActiveRecord, для которого несправедливы ваши пункты 3, 5, 7, 8 Для ActiveRecord статья еще готовится, поэтому примерно посмотреть что это можно только в неполной документации к нему
По поводу геттеров сеттеров: для атрибутов можно легко их задать таким образом:
model._.attr_name.get = function( descriptor ){}
подробнее описано здесь AutodafePart._ А чаще всего атрибутам достаточно фильтров, которые записываются в их описании (об этом написано в статье)
Понятия коллекций пока действительно нет.
Поясните, пожалуйста, что мешает создать пустой экземпляр?
Пожалуй модели — это самое безобидное. Они собирают информацию о всех полях из базы при запуске, так что описать надо только отношения моделей с другими моделями и правила валидации.
Пожалуй модели — это самое безобидное. Они собирают информацию о всех полях из базы при запуске, так что описать надо только отношения моделей с другими моделями и правила валидации.
Управление пользователями включается только при подключении определенного модуля, и никоем образом не накладывает ограничение на структуру базы данных.
Подробнее в этой статье: goo.gl/dTbgH ( статья в заготовке и может содержать неточности )
Не надо только забывать, что этот известный капитан и на «беде» добрался первым, а также что и аутодафе во всех значения этого слово было достаточно популярным явлением.
Просто иногда решения выглядящие хорошо для миниатюрного приложения не всегда также хороши для больших проектов.
Пара десятков контроллеров наследующихся друг отдруга с кучей действий, больше сотни правил маршрутизации — обычное дело для среднего сайта, в одном месте это не опишешь так, чтобы можно было быстро редактировать. Поэтому аутодафе изначально предлагает масштабируемую архитектуру.
а потом в коде
Например, вполне может встретиться вот такой код:
Там не просто свойства, а как раз гетткры и сеттеры, которые выглядят как задание свойств. Реализуются при помощи родного Object.defineProperty
Задать сеттер на лету можно вот так:
user._.name.set = function(value, descriptor){ descriptor.value = do_something_with( value ); }
и использовать соответственно просто как свойство:
user.name = 'Vasya';
Ну или можно в самом классе переопределить метод set_attribute и задавать атрибуты вобще как душе угодно, при этом использоваться они все равно будут как свойства.
В статье описывается базовый класс для моделей. Для моделей, хранящихся в БД, есть специальный класс ActiveRecord, для которого несправедливы ваши пункты 3, 5, 7, 8 Для ActiveRecord статья еще готовится, поэтому примерно посмотреть что это можно только в неполной документации к нему
По поводу геттеров сеттеров: для атрибутов можно легко их задать таким образом:
model._.attr_name.get = function( descriptor ){}
подробнее описано здесь AutodafePart._ А чаще всего атрибутам достаточно фильтров, которые записываются в их описании (об этом написано в статье)
Понятия коллекций пока действительно нет.
Поясните, пожалуйста, что мешает создать пустой экземпляр?
(промахнулся ответом)
Подробнее в этой статье: goo.gl/dTbgH ( статья в заготовке и может содержать неточности )
Пара десятков контроллеров наследующихся друг отдруга с кучей действий, больше сотни правил маршрутизации — обычное дело для среднего сайта, в одном месте это не опишешь так, чтобы можно было быстро редактировать. Поэтому аутодафе изначально предлагает масштабируемую архитектуру.