1. про «продвинутый автолоад» интересно былобы почитать. я например сколько не экспериментировал, а быстрее __autoload() ничего придумать не смог, и чтото типа вашего делал. так что пишите — поспорим )
забавно.
>мы не можем себе позволить обращаться к области данных из шаблона
и далее
>в шаблоне через статический метод происходит обращение к одноименному контроллеру
)
дело вкуса конечно.
а что если не рожать контроллер заново? а для таких случаев использовать статические методы соответствующего контроллера.
а то получается что для отрендеривания одного контроллера, рождаются другие, которые при отрисовке, в шаблонах могут вызывать третьи и т.д. Понимаю что привел частный случай, но ведь нет никакого контроля, кто кого откуда вызывает, и вероятны растраты ресурсов а в худшем случае и рекурсивные вызовы.
поэтому я все таки отказался от такой практики. у меня контроллер решает что и где показать, и какие данные подготовить.
скорость работы с массивами больше чем с объектами. я подобные эксперименты делал сам и видел обзоры других исследователей. так что у вас гдето погрешность есть)
помимо этого. замерьте еще потребление памяти, в простейшем случае функцией memory_get_usage();
это вам покажет, что одни и те же данные, занимают больше памяти если лежат внутри объекта и меньше если в виде простой переменной или как элемент массива. это вполне логично кстати.
поверьте. я не хочу переубеждать вас.
если вы считаете что вы придумали чтото выдающееся, то продолжайте дальше )
мы все через это прошли
подобный мета-язык позволяет скрыть особенности реализации самого шаблона. и верстальщику не нужно знать на чем написан сайт.
ну и некоторые конструкции выглядет меньше.
хотите критики? )
просто сразу появились вопросы. часть проблем сразу всплывает из за выбранной вами архитектуры решения.
1) как удалить все переменные шаблонизатора? например для того чтобы повторно его использовать для отрисовки другого блока данных.
2) как получить отрендеренный блок или страницу в переменную? это часто бывает нужно. для формирования рассылки пользователям например…
3) кеширования нет! кешировать данные хорошо, но иногда и готовые блоки кешировать бывает очень полезно.
4) несогласен насчет полного отсутствия логики. Просто нужно понимать. есть логика приложения, а есть логика отображения. хотябы в минимальном объеме она должна быть доступна. на одних блоках далеко не уедешь.
ваш подход медленнее и менее гибкий.
1) быстрее будет присваивать переменные внутреннему массиву private $vars, например. работа с переменными объекта всегда медленнее, и в данном случае непонятно почему вы остановились именно на таком варианте.
2) правильнее работать через функцию set, так как получается единая точка обработки переменных, и там всегда можно добавить дополнительные проверки, преобразования или что еще понадобится в дальнейшем. например в функцию можно передать массив-масивов и разложить автоматом переменные из внутреннего массива по отдельным переменным. а в вашем случае для этого придется переопределять методы __get и __set. это магия. и она тоже скоростью не блещет…
>так что для вас, такой подход будет «не гибким
Идея слабо зависит от реализации.
Если решение неуниверсально, то её не спасет ни ООП ни АОП ни чтото другое.
ведь это всего лишь методики программирования, они не делают алгоритм лучше.
конечно, в вашем подходе я вижу рациональное зерно. но у него есть очевидные ограничения.
просто задумайтесь над этим, и может вы поймете как сделать его лучше )
>вы не используете ООП
я раньше тоже строил приложения на основе «многоэтажных» классов и интерфейсов, все это было жутко взаимозависимо, громоздко и ресурсоемко. но мне тогда казалось что это и есть true ООП)
Но, по настоящему стало легко и свободно кодить когда я упростил все что можно, заменил часть объектов массивами, оставшиеся классы сделал максимально независимыми и т.д.
Удивительно, но скорость и удобство разработки даже возросло)
а теперь представьте,
что нужно в зависимости от mode join-нить разные таблицы с разными атрибутами товаров например
и в каждой из этих таблиц еще куча условий в Where
незнаю как у вас внутри реализованы Data_Fields и контексты, но думаю что даже тут уже вы столкнетесь с ограничениями. в которые вы сами себя загоняете таким подходом.
imho ваш подход решает достаточно частный случай. и с большой натяжкой можно считать его очень гибким и универсальным
вы не с той стороны подходите к проблеме. список товаров в каталоге, в результате поиска или списке новых товаров — одинаковые или очень похожи. карточка товара — это уже НЕ СПИСОК товаров а экземпляр. Для него правильнее сделать отдельный запрос, а не пытаться получить его через регресс интерфейса получения списков. ведь очевидно что ваш подход плодит кучу лишних запросов к БД и лишает гибкости кстати.
поэтому я обычно делаю один метод который генерирует запрос, учитывая структуру таблицы товаров и специфику вывода в шаблон, и далее через общие интерфейсы генерится нужный вид отображения… тогда можно выбирать ОДНИм запросом, который сразу вытаскивает все что нужно, для данной сущности и контекста использования
честно говоря, я не понял зачем вы так усложнили — простую, по сути, логику формирования списка и экземпляра данных.
и гибкости в вашем решении я не вижу. ведь оно заставляет вас плодить сущности и усложнять структуру классов.
приведите пожалуйста реальный пример, в вашем приложении, когда ваш подход реально чтото упрощает или унифицирует.
а если все равно писать самому придется…
еще учитывая:
> Страница «меню» — 108 запросов
то для себя я выбор сделан. и не в пользу drupal
и не надо мне говорить что кеш и оптимизация может помочь.
если система даже для ЭЛЕМЕНТАРНЫХ задач требует мощного сервера и кеша, то проблема именно в системе.
я понимаю что эта Плата за универсальность и гибкость. Этим страдают почти все CMF-ки. И такие системы всегда будут популярны, ни смотря ни на что.
главное чтобы у новичков не было эйфории. и они изначально понимали и видели и обратную сторону использования подобных инструментов.
НЕ могу себе даже представить такого диалога, с моими заказчиками
Заказчик: твой сайт тормозит
Программер: купите сервер помощнее )
Заказчик: твой сайт еще кладет нашу БД
Программер: ну купите больше памяти на серв
Заказчик: o_O но щас на сайте только пару человек ходит, что же будет дальше
Программер: может кластер замутим…
я тоже об этом подумал)
зачем автору стока модулей, если он входную переменную вручную вытаскивает
> if (preg_match('#^user/(\d+)$#', $_GET['q'], $m)) {
пришел в голову такой вариант:
1) добавляем в таблицу еще одно поле типа bigint, например RandKey
2) создаем по полю RandKey индекс
2) в RandKey храним просто случайные числа, в диапазоне от 1 до MAX(BIGINT)
3) Чтоб выбрать 10 случайных записей: (это псевдо-SQL, для простоты объяснения)
SELECT * FROM table WHERE RandKey>( SELECT RAND(10,MAX(RandKey)-10) FROM table ) LIMIT 10
надо только ввести поправки, для случаев когда RAND() будет слишком близким к краям диапазона поля RandKey.
как думаете?
>мы не можем себе позволить обращаться к области данных из шаблона
и далее
>в шаблоне через статический метод происходит обращение к одноименному контроллеру
)
дело вкуса конечно.
а что если не рожать контроллер заново? а для таких случаев использовать статические методы соответствующего контроллера.
а то получается что для отрендеривания одного контроллера, рождаются другие, которые при отрисовке, в шаблонах могут вызывать третьи и т.д. Понимаю что привел частный случай, но ведь нет никакого контроля, кто кого откуда вызывает, и вероятны растраты ресурсов а в худшем случае и рекурсивные вызовы.
поэтому я все таки отказался от такой практики. у меня контроллер решает что и где показать, и какие данные подготовить.
2,3,4 — удачи.
приведу пример моего простейшего шаблонизатора
class myView { protected $_path; public $_var = array(); public function __construct($path) { $this->_path = $path; } public function assign($name, $value='') { if (is_array($name)) foreach($name as $k=>$v) $this->_var[$k] = $v; else $this->_var[$name] = $value; } public function fetch($template, $params=array()) { if (is_array($params) && sizeof($params)>0) { $this->assign($params); } $this->_template = $this->_path . $template; if (!file_exists($this->_template)) { return 'Template not found: ' . $this->_template.'<br />'; } else { ob_start(); extract($this->_var); include($this->_template); return ob_get_clean(); } } public function display($template,$p=array() ) { echo $this->fetch($template, $p); } }для нативных шаблонов большего и не надо)
кеширование добавить и уже можно пользоваться)
помимо этого. замерьте еще потребление памяти, в простейшем случае функцией memory_get_usage();
это вам покажет, что одни и те же данные, занимают больше памяти если лежат внутри объекта и меньше если в виде простой переменной или как элемент массива. это вполне логично кстати.
поверьте. я не хочу переубеждать вас.
если вы считаете что вы придумали чтото выдающееся, то продолжайте дальше )
мы все через это прошли
ну и некоторые конструкции выглядет меньше.
ИМХО, на этом польза заканчивается.
просто сразу появились вопросы. часть проблем сразу всплывает из за выбранной вами архитектуры решения.
1) как удалить все переменные шаблонизатора? например для того чтобы повторно его использовать для отрисовки другого блока данных.
2) как получить отрендеренный блок или страницу в переменную? это часто бывает нужно. для формирования рассылки пользователям например…
3) кеширования нет! кешировать данные хорошо, но иногда и готовые блоки кешировать бывает очень полезно.
4) несогласен насчет полного отсутствия логики. Просто нужно понимать. есть логика приложения, а есть логика отображения. хотябы в минимальном объеме она должна быть доступна. на одних блоках далеко не уедешь.
1) быстрее будет присваивать переменные внутреннему массиву private $vars, например. работа с переменными объекта всегда медленнее, и в данном случае непонятно почему вы остановились именно на таком варианте.
2) правильнее работать через функцию set, так как получается единая точка обработки переменных, и там всегда можно добавить дополнительные проверки, преобразования или что еще понадобится в дальнейшем. например в функцию можно передать массив-масивов и разложить автоматом переменные из внутреннего массива по отдельным переменным. а в вашем случае для этого придется переопределять методы __get и __set. это магия. и она тоже скоростью не блещет…
насколько я знаю:
Класс — это описание объекта
Объекст — это экземпляр класса
поэтому отвечу
Классы — храню в файлах ))
Объекты — в ОЗУ, иногда в БД а иногда в файлах ))
чем это поможет топикстартеру — непонимаю)
Идея слабо зависит от реализации.
Если решение неуниверсально, то её не спасет ни ООП ни АОП ни чтото другое.
ведь это всего лишь методики программирования, они не делают алгоритм лучше.
конечно, в вашем подходе я вижу рациональное зерно. но у него есть очевидные ограничения.
просто задумайтесь над этим, и может вы поймете как сделать его лучше )
>вы не используете ООП
я раньше тоже строил приложения на основе «многоэтажных» классов и интерфейсов, все это было жутко взаимозависимо, громоздко и ресурсоемко. но мне тогда казалось что это и есть true ООП)
Но, по настоящему стало легко и свободно кодить когда я упростил все что можно, заменил часть объектов массивами, оставшиеся классы сделал максимально независимыми и т.д.
Удивительно, но скорость и удобство разработки даже возросло)
что нужно в зависимости от mode join-нить разные таблицы с разными атрибутами товаров например
и в каждой из этих таблиц еще куча условий в Where
незнаю как у вас внутри реализованы Data_Fields и контексты, но думаю что даже тут уже вы столкнетесь с ограничениями. в которые вы сами себя загоняете таким подходом.
imho ваш подход решает достаточно частный случай. и с большой натяжкой можно считать его очень гибким и универсальным
поэтому я обычно делаю один метод который генерирует запрос, учитывая структуру таблицы товаров и специфику вывода в шаблон, и далее через общие интерфейсы генерится нужный вид отображения… тогда можно выбирать ОДНИм запросом, который сразу вытаскивает все что нужно, для данной сущности и контекста использования
и гибкости в вашем решении я не вижу. ведь оно заставляет вас плодить сущности и усложнять структуру классов.
приведите пожалуйста реальный пример, в вашем приложении, когда ваш подход реально чтото упрощает или унифицирует.
еще учитывая:
> Страница «меню» — 108 запросов
то для себя я выбор сделан. и не в пользу drupal
и не надо мне говорить что кеш и оптимизация может помочь.
если система даже для ЭЛЕМЕНТАРНЫХ задач требует мощного сервера и кеша, то проблема именно в системе.
я понимаю что эта Плата за универсальность и гибкость. Этим страдают почти все CMF-ки. И такие системы всегда будут популярны, ни смотря ни на что.
главное чтобы у новичков не было эйфории. и они изначально понимали и видели и обратную сторону использования подобных инструментов.
Заказчик: твой сайт тормозит
Программер: купите сервер помощнее )
Заказчик: твой сайт еще кладет нашу БД
Программер: ну купите больше памяти на серв
Заказчик: o_O но щас на сайте только пару человек ходит, что же будет дальше
Программер: может кластер замутим…
зачем автору стока модулей, если он входную переменную вручную вытаскивает
> if (preg_match('#^user/(\d+)$#', $_GET['q'], $m)) {
«Программирование» мышкой — не в моей вкусе )
1) добавляем в таблицу еще одно поле типа bigint, например RandKey
2) создаем по полю RandKey индекс
2) в RandKey храним просто случайные числа, в диапазоне от 1 до MAX(BIGINT)
3) Чтоб выбрать 10 случайных записей: (это псевдо-SQL, для простоты объяснения)
SELECT * FROM table WHERE RandKey>( SELECT RAND(10,MAX(RandKey)-10) FROM table ) LIMIT 10
надо только ввести поправки, для случаев когда RAND() будет слишком близким к краям диапазона поля RandKey.
как думаете?
)))