-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
ENVOS - MVC Framework
- Автор темы _RVK_
- Дата начала
syfisher
TDD infected!!
Полностью согласен с ForJest: процедурный стиль программирования загнан в объектный синтаксис. Для тренировки - пойдет 
Но такий проекты уже не модно делать http://www.phpwact.org/php/mvc_frameworks
Но такий проекты уже не модно делать http://www.phpwact.org/php/mvc_frameworks 
_RVK_
Новичок
syfisher
Видел:
Limb - показался очень тормозным, кажется так и не удалось добится скорости генерации страницы ниже 1 сек. Правда это было почти год назад. Уверен что много с той поры воды утекло.
WACT - просто недоделанный. Да неплохой шаблнизатор, но остальное через одно место. Пытался даже писать что-то, но получалость только после обработки напильником. Бросил когда участились случаи возникновения трудноуловимых или вообще неуловимых ошибок.
Mojavi - хорош, но недоделан. Более года был в версии 3.0.0dev. а сейчас вообще сразу в 4.0.0 и тоже не закончен.
PRADO - лучшее из того что видел. Хорошая документация, примеры.
Смотрел еще несколько, но они даже упоминания не стоят.
-~{}~ 09.01.06 21:36:
Нда. посмотрел CakePHP. C виду неплохо, подробная документация и все такое... но когда посмотрел код, понял что после такой вони, запахи ENVOS это просто Шанель#5
Можно поконкретней? Кроме перечисленных запахов, от которых легко избавится при дальнейшем рефакторинге.
Можешь посоветовать что из этого стоит посмотреть?
Видел:
Limb - показался очень тормозным, кажется так и не удалось добится скорости генерации страницы ниже 1 сек. Правда это было почти год назад. Уверен что много с той поры воды утекло.
WACT - просто недоделанный. Да неплохой шаблнизатор, но остальное через одно место. Пытался даже писать что-то, но получалость только после обработки напильником. Бросил когда участились случаи возникновения трудноуловимых или вообще неуловимых ошибок.
Mojavi - хорош, но недоделан. Более года был в версии 3.0.0dev. а сейчас вообще сразу в 4.0.0 и тоже не закончен.
PRADO - лучшее из того что видел. Хорошая документация, примеры.
Смотрел еще несколько, но они даже упоминания не стоят.
-~{}~ 09.01.06 21:36:
Нда. посмотрел CakePHP. C виду неплохо, подробная документация и все такое... но когда посмотрел код, понял что после такой вони, запахи ENVOS это просто Шанель#5
texrdcom
Новичок
Я больше чем уверен если критикующие стороны выложили бы свои фреемворки мы с них стибались также
А идея хороша - написать вместе фреемворк.
Просто чтоб не получилась лебедь...
Надо подойти к вопросу серьезно, поймите то что мы пишем в одиночку не когда не сравниться с написанным целой групой
(хотя конечно возможно есть гении...) Но если возьмете любой серьезный проэкт не важно web local и посмотрите то него потраченно в общей сложности не сколько человеко лет программирования! Остальное все самопал
Хотя если посмотреть на не которые комерчиские cms которые популярны на рынка снг - и случайно прочитать пример - давайте напишем простой модуль для обучения то можно охренеть не иза сложности php а иза сложности cms чтобы с ее помощью что то написать кроме php нужно еще знать кучу функции тойже cms - это для модуля тествого который вписываеться в общею конфигурацию cms .
p/s
Давайте подумаем возможно действительно есть смысл, собраться да и написать фреемворк общими усилиями!
А идея хороша - написать вместе фреемворк.
Просто чтоб не получилась лебедь...
Надо подойти к вопросу серьезно, поймите то что мы пишем в одиночку не когда не сравниться с написанным целой групой
(хотя конечно возможно есть гении...) Но если возьмете любой серьезный проэкт не важно web local и посмотрите то него потраченно в общей сложности не сколько человеко лет программирования! Остальное все самопал
Хотя если посмотреть на не которые комерчиские cms которые популярны на рынка снг - и случайно прочитать пример - давайте напишем простой модуль для обучения то можно охренеть не иза сложности php а иза сложности cms чтобы с ее помощью что то написать кроме php нужно еще знать кучу функции тойже cms
- это для модуля тествого который вписываеться в общею конфигурацию cms .p/s
Давайте подумаем возможно действительно есть смысл, собраться да и написать фреемворк общими усилиями!
.des.
Поставил пиво кому надо ;-)
собственно syfisher уже выложил
limb cmf.Хотя конечно критика в этом топике, что ForJesta, что syfishera "забавная"
Процедурный стиль завернутый в объектный синтаксис с дурным запахом и методы с длинным списком параметров вот и вся критика. _RVK_ она очень помогла.
texrdcom
Новичок
Я вот дописываю свой фрейворк сначало тоже был глобал.
Сделал покрутил прикинул что через месяц буду писать модуль и буду на грабли ставать ...
Решил к стати просто через одиночку паттерн.
К стати вот читаю доку по limb
.И смотрю их форум конечно limb сделан круто но я бы в жизни серьезно его не использовал по той причине что писал выше !
Вкратце сколько файлов надо создать в нем чтобы написать новый модуль ? Сколько внутриних функций я обязан знать?
Таким проэктам присущая сложность которую может понять только автор и его команда!.
syfisher
TDD infected!!
Ответ свой хочу поделить на две части: первая - пара слов насчет прочих framework-ов (в частности Limb/WACT), другая - насчет ENVOS. Я постараюсь не вдаваться в подробности, но высказать свое мнение насчет того, что такое "идеальный" framework.
Limb более года назад разделился на 2 ветки - первая из них - это прежняя CMS, которую все знают как не слишком удобный, быстрый, но этот инструмент нас устраивает, вторая - это фреймворк. С тех пор CMS изменилась очень незначительно (только внешний вид), но фреймворк - очень сильно. Причем изменения велись в основном под воздействием проектов, которые на его базе реализовывались. Постоянный рефактринг, модульное тестирование, иногда TDD, выделение пакетов. CMS - это не больше, чем пакет сейчас. Я просто хочу сказать, что сделать хороший фреймворк без практики и использования продукта в рабочих целях, просто нельзя. Большинство решений, которые мы делали up-front (продумывались, затем реализовывались), оказались или не нужными, или кардинально изменились под влиянием реальных проектов. Мелкие проекты типа "демки" - не в счет: они ничего не показывают.
Что касается WACT - согласен, что его трудно использовать, так как он редко релизится, нередко месяцами вообще висит в подвешенном состоянии, многое в этом плане зависит от project-lead-а, который то более по 4 месяца, по 2 месяца на кояке плавает и т.д. Но у WACT нужно учиться. Как писать классный код, писать хорошие тесты, черпать идеи. Многие концепции WACT понять неопытному разработчику непросто, это да. По приглядеться стоит. Limb, например, сейчас спокойно использует 60% кода WACT (валидаторы, шаблонизатор, итераторы, свойства, callback-и, DBAL, утилиты) без каких-либо проблем.
Что касается остальных фреймворков, которые я недавно смотрел - это symfony (клон Mojavi 4.0) и Cake. Symfony весьма понравился, аккуратно, продолжение хорошо зарекомендовавшей себя идеи. Хорошая библиотека кода, которую скорее всего удобно использовать для типичных задач. Вопрос, как обычно, в изучении этой библиотеки. Cake пока еще слишком молод. Но посмотреть его реализацию ActiveRecord, наверное, стоит.
Для меня интересно, как в том или ином MVC-фреймворке решены вопросы взаимодействия всех компонентов. Как реализован контроллер, что знает View о модели, как обрабатываются ошибки с форм, как они передаются в шаблоны, можно ли менять View по ходу работы действия. Также важно можно ли сменить механизм построения URL-ов, сколько процентов работы выносится в файлы конфигурации, какая модель встраивания пакетов, насколько легко обеспечить повторное использование кода, шаблонов, запросов, насколько легко тестировать мои новые классы, например, действия и т.д. Конечно, для меня признаком качества системы является наличие модульных тестов. По-моему это первый признак того, что система легко расширяема, сделана исходя из реальных требований, что над ней работают опытные разработчики.
Теперь попробую покритиковать Envos
Насчет с модели. Признаюсь, что мне показалось странным, что интерфейс Model содержит метод getView(). В моем понимании MCV Model2 модель ничего не знает о существовании отображения. По идее контроллер передает необходимые данные во View. Часто непосредственную передачу данных в щаблоны осуществляют специальные View-helper-ы (я могу ошибаться в данном термине, так как иногда под view-helper-ами понимают классы, которые используются в непосредственно в шаблонах для вытягивания данных).
Такой класс, как BaseDBModel, наверное было бы правильнее назвать как Query, а еще лучше SelectQuery. Из схожего класса у нас выделились подсистемы Query, Criteria и QueryModifier, небольшие классы с очень четкими интерфейсами. Кстати, в onPHP тоже есть такие классы.
Я не понял, почему Auth класс наследуется от BaseDBModel, а не делегирует ему. Ведь очевидно, что при помощи Auth классы просто некорректно выполнять операции, характерные BaseDBModel.
Вообще называть какой-либо класс Model, просто некорректно. Обычно модель - это множество классов, которые играют порой очень различные роли в рамках одной системы. DBAL - это тоже часть модели, доменные классы, Finder-ы, ORM и т.д. Грести всех под одну гребенку - нельзя.
Теперь насчет цепочки фильтров. Насколько я понимаю, цепочка фильтров, это форма паттерна Chain-of-Responsibility, и теоретически должна быть возможность эту цепочку прервать. У тебя этой возможности нет. FilterManager спрашивает App насчет текущего модуля, действия и далее запускает фильтры. А не бывает ситуации, когда еще для того, чтобы работал сам App нужно выполнить некоторые действия, которые также подходят к цепочке. Лично я бы сделал так: FilterManager просто запускает фильтры, а ту часть, которая находится в верхей части метода execFilters переместил бы еще в один фильтр, который бы создавал еще один экземпляр FilterManager и передавал бы ему нужные фильтры.
Насчет такого частого использования одиночек я уже как-то высказывался здесь на форуме. Одиночки резко снижают тестируемость системы и ее расширяемость. Как минимум нужно иметь возможность заменять любую одиночку другим объектом. Ведь когда ты используешь одиночку, то одижаешь не какую-либо функциональность, а ожидаешь, что одиночка просто поддерживает какой-либо интерфейс. Нужен фильтру название модуля, ему по-барабану, как определяется этот модуль. Используя статические методы, ты связываешь два класса намертво. А раз всем по-барабану как определяется иодуль, значит APP должен обеспечивать возможность замены определения модуля, а это можно сделать только заменив инстанс одиночки на другой. Вообще отношение к одиночкам у всех разное, но большинство тех, кто использует модульное тестирование признают, что их использование нецелесообразно и затрудняет развитие систем. В большинстве случаев от них можно отказаться, например, используя Registry или DI.
Не могу что-то определенного сказать насчет контроллера. Все логично - определили текущий модуль, действие, создали Action, запустили. По действию сформировали шаблон, получили с модели данные, отправили в шаблон. Вроди нормально, все это мы уже видели, например, в Mojavi 1.0. Странновато, правда, было видеть методы методов BaseController :: hasRights(), MainController :: getTemplate() - это вводит слишком много зависимостей в систему. Насчет остального см. мой список вопросов к любому фреймворку выше Будут ответы?
Мои 2 копейки...
Limb более года назад разделился на 2 ветки - первая из них - это прежняя CMS, которую все знают как не слишком удобный, быстрый, но этот инструмент нас устраивает, вторая - это фреймворк. С тех пор CMS изменилась очень незначительно (только внешний вид), но фреймворк - очень сильно. Причем изменения велись в основном под воздействием проектов, которые на его базе реализовывались. Постоянный рефактринг, модульное тестирование, иногда TDD, выделение пакетов. CMS - это не больше, чем пакет сейчас. Я просто хочу сказать, что сделать хороший фреймворк без практики и использования продукта в рабочих целях, просто нельзя. Большинство решений, которые мы делали up-front (продумывались, затем реализовывались), оказались или не нужными, или кардинально изменились под влиянием реальных проектов. Мелкие проекты типа "демки" - не в счет: они ничего не показывают.
Что касается WACT - согласен, что его трудно использовать, так как он редко релизится, нередко месяцами вообще висит в подвешенном состоянии, многое в этом плане зависит от project-lead-а, который то более по 4 месяца, по 2 месяца на кояке плавает и т.д. Но у WACT нужно учиться. Как писать классный код, писать хорошие тесты, черпать идеи. Многие концепции WACT понять неопытному разработчику непросто, это да. По приглядеться стоит. Limb, например, сейчас спокойно использует 60% кода WACT (валидаторы, шаблонизатор, итераторы, свойства, callback-и, DBAL, утилиты) без каких-либо проблем.
Что касается остальных фреймворков, которые я недавно смотрел - это symfony (клон Mojavi 4.0) и Cake. Symfony весьма понравился, аккуратно, продолжение хорошо зарекомендовавшей себя идеи. Хорошая библиотека кода, которую скорее всего удобно использовать для типичных задач. Вопрос, как обычно, в изучении этой библиотеки. Cake пока еще слишком молод. Но посмотреть его реализацию ActiveRecord, наверное, стоит.
Для меня интересно, как в том или ином MVC-фреймворке решены вопросы взаимодействия всех компонентов. Как реализован контроллер, что знает View о модели, как обрабатываются ошибки с форм, как они передаются в шаблоны, можно ли менять View по ходу работы действия. Также важно можно ли сменить механизм построения URL-ов, сколько процентов работы выносится в файлы конфигурации, какая модель встраивания пакетов, насколько легко обеспечить повторное использование кода, шаблонов, запросов, насколько легко тестировать мои новые классы, например, действия и т.д. Конечно, для меня признаком качества системы является наличие модульных тестов. По-моему это первый признак того, что система легко расширяема, сделана исходя из реальных требований, что над ней работают опытные разработчики.
Теперь попробую покритиковать Envos
Насчет с модели. Признаюсь, что мне показалось странным, что интерфейс Model содержит метод getView(). В моем понимании MCV Model2 модель ничего не знает о существовании отображения. По идее контроллер передает необходимые данные во View. Часто непосредственную передачу данных в щаблоны осуществляют специальные View-helper-ы (я могу ошибаться в данном термине, так как иногда под view-helper-ами понимают классы, которые используются в непосредственно в шаблонах для вытягивания данных).
Такой класс, как BaseDBModel, наверное было бы правильнее назвать как Query, а еще лучше SelectQuery. Из схожего класса у нас выделились подсистемы Query, Criteria и QueryModifier, небольшие классы с очень четкими интерфейсами. Кстати, в onPHP тоже есть такие классы.
Я не понял, почему Auth класс наследуется от BaseDBModel, а не делегирует ему. Ведь очевидно, что при помощи Auth классы просто некорректно выполнять операции, характерные BaseDBModel.
Вообще называть какой-либо класс Model, просто некорректно. Обычно модель - это множество классов, которые играют порой очень различные роли в рамках одной системы. DBAL - это тоже часть модели, доменные классы, Finder-ы, ORM и т.д. Грести всех под одну гребенку - нельзя.
Теперь насчет цепочки фильтров. Насколько я понимаю, цепочка фильтров, это форма паттерна Chain-of-Responsibility, и теоретически должна быть возможность эту цепочку прервать. У тебя этой возможности нет. FilterManager спрашивает App насчет текущего модуля, действия и далее запускает фильтры. А не бывает ситуации, когда еще для того, чтобы работал сам App нужно выполнить некоторые действия, которые также подходят к цепочке. Лично я бы сделал так: FilterManager просто запускает фильтры, а ту часть, которая находится в верхей части метода execFilters переместил бы еще в один фильтр, который бы создавал еще один экземпляр FilterManager и передавал бы ему нужные фильтры.
Насчет такого частого использования одиночек я уже как-то высказывался здесь на форуме. Одиночки резко снижают тестируемость системы и ее расширяемость. Как минимум нужно иметь возможность заменять любую одиночку другим объектом. Ведь когда ты используешь одиночку, то одижаешь не какую-либо функциональность, а ожидаешь, что одиночка просто поддерживает какой-либо интерфейс. Нужен фильтру название модуля, ему по-барабану, как определяется этот модуль. Используя статические методы, ты связываешь два класса намертво. А раз всем по-барабану как определяется иодуль, значит APP должен обеспечивать возможность замены определения модуля, а это можно сделать только заменив инстанс одиночки на другой. Вообще отношение к одиночкам у всех разное, но большинство тех, кто использует модульное тестирование признают, что их использование нецелесообразно и затрудняет развитие систем. В большинстве случаев от них можно отказаться, например, используя Registry или DI.
Не могу что-то определенного сказать насчет контроллера. Все логично - определили текущий модуль, действие, создали Action, запустили. По действию сформировали шаблон, получили с модели данные, отправили в шаблон. Вроди нормально, все это мы уже видели, например, в Mojavi 1.0. Странновато, правда, было видеть методы методов BaseController :: hasRights(), MainController :: getTemplate() - это вводит слишком много зависимостей в систему. Насчет остального см. мой список вопросов к любому фреймворку выше
Будут ответы?Мои 2 копейки...
_RVK_
Новичок
syfisher
Вот это уже конструктивно! Спасибо за такой четкий обзор. Отвечу обязательно, но чуть позже. Сейчас занят
-~{}~ 10.01.06 17:36:
Одной из основных идеологий при разработке ENVOS явлется простота движка. Я не хочу что бы ENVOS был похож на onPHP или Limb где в облили класов черт ногу сломит. Конечно я не хочу сказать что сучествующая объектная модель идиальна и достаточна. Нет конечно. Будут появляться новые классы. Будут дробится старые, но по мере необходимости.
Отвечу на твои вопросы
Данные из модели получает Action. MainController выполняет первый, которые, в своб очередь могут выполнять свои... Получается этакое дерево. Каддый узел дерева получает из модели свои данные, и они, в конечном итоге собираются в MainController, который передает их во View. Конечно можно пропагандировать активные шаблоны, но ИМХО это лишь размазывает логику по всей системе. У меня же в любой момент можно однозначно сказать откуда данные. В крайнем случае пройдясь по иерархии вызовов Actions.
Я осознаю что существующий механизм еще несовершенен. Но в целом он прост и неплохо работает.
Нет времени начать. Нет я понимаю что это время вернется сторицей, но мне оно нужно сейчас. Думаю в течении пары следующих недель я напишу первые тесты для Envos. Сам вижу что проблемма назрела. Думаю в мастер-классе по TDD на конфе я тоже буду учавствовать
Чуть позже продолжу.
Вот это уже конструктивно! Спасибо за такой четкий обзор. Отвечу обязательно, но чуть позже. Сейчас занят
-~{}~ 10.01.06 17:36:
Одной из основных идеологий при разработке ENVOS явлется простота движка. Я не хочу что бы ENVOS был похож на onPHP или Limb где в облили класов черт ногу сломит. Конечно я не хочу сказать что сучествующая объектная модель идиальна и достаточна. Нет конечно. Будут появляться новые классы. Будут дробится старые, но по мере необходимости.
Отвечу на твои вопросы
У меня это реализовано так:
Данные из модели получает Action. MainController выполняет первый, которые, в своб очередь могут выполнять свои... Получается этакое дерево. Каддый узел дерева получает из модели свои данные, и они, в конечном итоге собираются в MainController, который передает их во View. Конечно можно пропагандировать активные шаблоны, но ИМХО это лишь размазывает логику по всей системе. У меня же в любой момент можно однозначно сказать откуда данные. В крайнем случае пройдясь по иерархии вызовов Actions.
Только то что передал ей контроллер.
Валидация реализована на основе правил. Правила - классы, объекты которых реализуют протые проверки. Из выполнением занимается BaseValidator. Для каждой формы создется один потомок, запускающий правила по описанной в его методе exec логике. Для возврата сообщений об ошибках используются сессии(была тут тема Фаната, где обсуждаля миханизм). Далее данные поступают во View где и выводятся.
Я осознаю что существующий механизм еще несовершенен. Но в целом он прост и неплохо работает.
Нет. Это можно делать только в фильтрах. Actions ничего не знают и не должны знать о View, кроме тога как туда передать данные. Это опять таки исключает "размазываение" логики.
Да, для этого есть плагин Smarty.
В смысле. Файлы конфигурации это файлы конфигурации. Логики там быть не должно.
Я думал об этом. Этот механизм будет прорабатываться. Думаю для этого будет специальная утилита. Причем сам framework будет разделен на пакеты, как в Rails и части envos можно будет как обновлять так и использовать отдельно от вего движка.
Вот здесь нет абсолютной оценки. Я считаю что достаточно легко.
Я в шаге от этого
Нет времени начать. Нет я понимаю что это время вернется сторицей, но мне оно нужно сейчас. Думаю в течении пары следующих недель я напишу первые тесты для Envos. Сам вижу что проблемма назрела. Думаю в мастер-классе по TDD на конфе я тоже буду учавствовать Чуть позже продолжу.
Rammstein
PHPClub::News
По мне так, нужно что-то коренным образом менять... Всмысле понимания и реализации framework-а. То что уже измучено на сто раз - смысла делать не вижу... Но это как знать...
P.S> Имхо, нужно сделать всем сообществом нормальный фреймворк и не поднимать более эту тему.
P.P.S> Возможно, не хватает на рынке коммерческой компании, которая этим реально занилась бы. (к примеру, Microsoft и Borland двигают свои "фреймворки", но не для PHP )
P.S> Имхо, нужно сделать всем сообществом нормальный фреймворк и не поднимать более эту тему.
P.P.S> Возможно, не хватает на рынке коммерческой компании, которая этим реально занилась бы. (к примеру, Microsoft и Borland двигают свои "фреймворки", но не для PHP
)
_RVK_
Новичок
Не спорю. Но ENVOS не для сложнейших промышленных систем, а для обычных сайтов среднего уровня. Он должен быть прост.
Посмотрим конечно. Нет придела совершенству
Итак продолжу комментари к твоему посту.
Моя ошибка. Неверное название метода. Как ты сам заметил, некоторые классы называются по компанентам MVC, другие по имена паттернов, третьи вообще так называются по истрическим причинам (SuperAction, например). версия пока 0.2.0 потмоу до первой версии есть время исправить. Да и выложил я Envos отчасти из за этого. Что бы посмотрели со стороны, предложили решения...
Да, согласен. Я думаю над этим вопросом. Ясно что аутентификацией должен заниматься контроллер. Но не сам, а используя функционал других классов. Не хочется создавать под это отдельную иерархию. Пока идея - применить миксинг. Думаю так и поступлю, и не только с аутентификацией, но и пейджиг и аплоад, и другие сервисные функции.
-~{}~ 10.01.06 22:44:
Далее...
Не совсем так. Насколько я понимаю этот паттерн используется когда получатель запроса неизвесен. У меня же он известен зарание. Во вторых есть еще Post фильтры. Они не обрабатывают запросы, и прерывать цепочку не должны, ибо это бы означало крах запроса. Пользоваель не получит ответа, потому как возможностей изменить что-то в действиях контроллера у них нет(он уже отработал). Все же это скорее реализация Decorator.
Я пока такой ситуации не встречал. Фильтры это как бы оболочка контроллера. А App - класс со статическими методами, потому как должен быть досупен отовсюду. То есть, до выполнения первого филтра, не создаются объекты (кроме некоторых вспомогательных). Да и вообще, мне пока нравится реализация. Может быть небольшая гибкость, кторая далеко не всегда нужна, принесена в жертву простоте. Возможно что-то изменится в дальнейшем.
Их там на самом деле не так много, как кажется. Loger и Pager там вообще по случайности. Кто-то из них, кажется, вообще не работает
опять, же все решит механизм mixin, который я собираюсь реализовать. Кто хочет использовать функционал того же пейджера, пусть его подмешивает себе, и использует как свой. Мне там например жутко не нравится функция Redirect. Ну не нужна она большенству Actions. А плодить одиночек, я не хочу. Или есть там UploaderAction. Да он умеет уплоадить файлы. Теперь созаем PagerAction который умеет выводить данные постранично. Но Action который умеет делать и то, и другое не получится. Так что я тоже противник одиночек, но это пока самое простое решение.
Блин. Вроде же удалил старый метод определения доступа. А про hasRights() забыл
Он там просто не нужен. Второй... а что в этом плохого? Этот метод возвращает имя шаблона. Чаще всего он определяется по имени action. Конечно можно View передавать имя Action, а он уж пусть сам выбирает представление, но в чем смысл?Ну вот и все. Надеюсь все понятно разьяснил?