Если вы внимательно посмотрите мой коммент, можете заметить, что я как раз не считаю, что дело в «хорошести» шаблонизатора. И вполне согласен с отделением логики и шаблонов. Но это ни коим образом не противоречит идее шаблонизаторов. Просто не нужно все толкать в один шаблон.
Ну, например, у вас есть таблица, строки которой зависят от прав пользователя, исходных данных, выбранного пользователем скина и еще кучи проверок. Если эти проверки толкать в один шаблон — согласен, получится лапша.
Но почему бы не сделать несколько «шаблонов для строки» и (анализируя все условия) не отрендерить эти строки по отдельности? Потом в итоговый шаблон можно подать просто список готовых строк и там не будет никакой логики.
С этой точки зрения я, для себя лично, «хорошими» считаю наиболее простые и понятные шаблонизаторы без всякого навернутого функцинала. Что-нибудь типа handlebarsjs.com/ Но кому-то может нравиться что-то другое — не принципиально.
я предпочитаю писать куски XHTML отдельно, а в логике строить сколько угодно сложный DOM
Что мешает вынести «куски» в отдельные небольшие шаблончики, а потом подставлять в шаблон верхнего уровня, как готовые строки? Ровно тот же подход получится.
Не согласен на счет «не дает отдачи». Она сразу показывает где узкие места. Классически, как по канбановской методике и должно быть.
Например: в колонке «к разработке» появилась большая прокрутка (и не нужно прокручивать, важно, что там много), а в колонке «на тестировании» — почти пусто. Ясно — разработчики зашиваются.
Либо наоборот, в «к разработке» осталась пара задач… идешь выяснять, о чем думает постановка?
Причем это не только для руководителя, а вся команда видит. В Асане же специально смотреть надо, и два против одного, что те же разработчики смотреть не станут.
Смотрели сейчас Асану именно в контексте возможности перехода с trello.
Но видимо переходить не будем, хотя Асана гибкая и уложить можно практически любой процесс. Но в сравнении с trello очень не хватает обзорности. Чтобы любой член команды мог видеть всю ситуацию просто окинув экран одним взглядом.
А с этапами — удивлен. У нас на одну доску не влезло. Пришлось разделять на разработческую и постановочную.
На разработческой доске вот:
— к разработке
— в работе
— к выкладке на тестовый (в репозитории, но не задеплоено)
— на тестировании
— к выкладке на продакшен (оттестировано)
Александр, я верю, что это не ваш случай. В том смысле, что сделай вы макет, ошибки «1a» вы бы не допустили. Но я имел возможность наблюдать несколько случаев, когда стартапы «начинали все по науке», с макетом… но вот интерпретировали отсутствие интереса к макету неверно.
Александр, при «дешевом старте» есть еще один риск. Риск ошибки «1a»: «У нас не взлетает потому, что не достаточно круто сделано...» В эту ошибку влипают многие, догадавшиеся начать с дешевого прототипа. Кажется, добавить юзабильности да фич и взлетит. Из моего опыта и наблюдений за другими командами юзабильность может добавить от 2 до 8 раз, фичи (не меняющие принципиально концепцию) от 2 до 6. Если это именно та добавка, которой не хватает — можно с этим играть. Но если не хватает пары порядков…
По-моему, вы ломитесь в открытую дверь. Подобные подходы давно уже мейнстрим.
— Все веб-приложения написанные на фреймворках, подобных backbone.js работают в этой (или близкой) архитектуре.
— Большинство веб-приложений использующих couchDB работают в близкой архитектуре (порой вообще без написания чего-либо на серверной стороне).
— Да просто «большинство веб-приложений»… НО! «Приложений», а не «сайтов». «Сайтам» с минимальной прикладной логикой удобнее обходиться «классической» вебовской архитектурой.
Из моего опыта, есть два времени для которых оценка возможна.
До двух недель и от трех месяцев. В первом случае есть достаточно информации для рациональной оценки, во втором — работает интуиция и усреднение ошибок.
А вот в промежуточном интервале — действительно труба…
Не все!
Только то, что связано с целостностью данных. Проверка того, что пользователь ввел именно то, что хотел ввести (например — повтор пароля), это задача уровня представления.
Думаю, здесь путаются понятия валидации, как целостности данных, и валидации, как корректности ввода.
И если целостность данных должна относиться к уровню модели, то корректность ввода — это уровень представления… или в крайнем случае — контроллер, поскольку view-уровень в рельсах тупой. Но по MVC он и должен быть тупым. А потому, IMHO, тут стоит говорить не о косяках модельной валидации, а о недостаточности MVC. То есть просится или «презентер» или ViewModel.
У нас это решилось просто. Мы отказались от рельсовского View-уровня, ограничив рельсы выдачей json, а все остальное — на backbone.js При этом бекбоновские вьюшки как занимают соответствующий слой, валидируя корректность ввода.
Ну, например, у вас есть таблица, строки которой зависят от прав пользователя, исходных данных, выбранного пользователем скина и еще кучи проверок. Если эти проверки толкать в один шаблон — согласен, получится лапша.
Но почему бы не сделать несколько «шаблонов для строки» и (анализируя все условия) не отрендерить эти строки по отдельности? Потом в итоговый шаблон можно подать просто список готовых строк и там не будет никакой логики.
С этой точки зрения я, для себя лично, «хорошими» считаю наиболее простые и понятные шаблонизаторы без всякого навернутого функцинала. Что-нибудь типа handlebarsjs.com/ Но кому-то может нравиться что-то другое — не принципиально.
(Впрочем, у меня это рельсы делают. И за сборкой в один упакованный файл в продакене следят они же...)
Что мешает вынести «куски» в отдельные небольшие шаблончики, а потом подставлять в шаблон верхнего уровня, как готовые строки? Ровно тот же подход получится.
Тот же github.com/marionettejs/backbone.marionette
Например: в колонке «к разработке» появилась большая прокрутка (и не нужно прокручивать, важно, что там много), а в колонке «на тестировании» — почти пусто. Ясно — разработчики зашиваются.
Либо наоборот, в «к разработке» осталась пара задач… идешь выяснять, о чем думает постановка?
Причем это не только для руководителя, а вся команда видит. В Асане же специально смотреть надо, и два против одного, что те же разработчики смотреть не станут.
Но видимо переходить не будем, хотя Асана гибкая и уложить можно практически любой процесс. Но в сравнении с trello очень не хватает обзорности. Чтобы любой член команды мог видеть всю ситуацию просто окинув экран одним взглядом.
А с этапами — удивлен. У нас на одну доску не влезло. Пришлось разделять на разработческую и постановочную.
На разработческой доске вот:
— к разработке
— в работе
— к выкладке на тестовый (в репозитории, но не задеплоено)
— на тестировании
— к выкладке на продакшен (оттестировано)
— Все веб-приложения написанные на фреймворках, подобных backbone.js работают в этой (или близкой) архитектуре.
— Большинство веб-приложений использующих couchDB работают в близкой архитектуре (порой вообще без написания чего-либо на серверной стороне).
— Да просто «большинство веб-приложений»… НО! «Приложений», а не «сайтов». «Сайтам» с минимальной прикладной логикой удобнее обходиться «классической» вебовской архитектурой.
До двух недель и от трех месяцев. В первом случае есть достаточно информации для рациональной оценки, во втором — работает интуиция и усреднение ошибок.
А вот в промежуточном интервале — действительно труба…
Только то, что связано с целостностью данных. Проверка того, что пользователь ввел именно то, что хотел ввести (например — повтор пароля), это задача уровня представления.
И если целостность данных должна относиться к уровню модели, то корректность ввода — это уровень представления… или в крайнем случае — контроллер, поскольку view-уровень в рельсах тупой. Но по MVC он и должен быть тупым. А потому, IMHO, тут стоит говорить не о косяках модельной валидации, а о недостаточности MVC. То есть просится или «презентер» или ViewModel.
У нас это решилось просто. Мы отказались от рельсовского View-уровня, ограничив рельсы выдачей json, а все остальное — на backbone.js При этом бекбоновские вьюшки как занимают соответствующий слой, валидируя корректность ввода.
К сожалению, менеджеры зачастую боятся таких экспериментов… типа «потеря управляемости», «ужас — ужас».