hook pre render Идея и примерная реализация

[sv2109]

Коллеги, для удобства совместной работы сделал такую доку http://smartceo.ru/o.../annotated.html. Если полезно - дайте, знать.

Вы бы это вынесли в отдельную тему. Так и эта тема была бы чище и отклик получили бы больший.

По доке. Спорный вопрос. Пользы с нее было бы больше если бы в коде использовались правильные комментарии с использование @param, @return, @var, @todo итд. Подобные док креаторы их вроде подхватывают. А так.. посмотреть, что все контроллеры наследуются от главного контроллера, это и так известно. Та и работать со структурой приходится редко, в основном нужен какой-то конкретный класс, который мне например удобнее открыть в редакторе (у меня NetBeans IDE 7.2), который во вкладке Навигатор покажет список всех методов и свойств этого класса, а по клику можно перейти к конкретному методу и посмотреть его код.

Это мое мнение. Но в любом случае за проделанную работу плюсую.

[cmd]

С шаблонами там оказывается предлагается через переопределение функции preRender загружать файл шаблона, править его командами типа pred_replace на лету и потом передавать на рендеринг.

Э-э... нет. Потом в коде одно, в html другое, а ты смотришь на 5 регулярок и думаешь: какого хера?

Коллеги, для удобства совместной работы сделал такую доку http://smartceo.ru/o.../annotated.html.

В общем-то пока не надо на самом деле - рано, нечего ещё смотреть.

sv2109, создавай ещё 2 темы

[sv2109]

С шаблонами там оказывается предлагается через переопределение функции preRender загружать файл шаблона, править его командами типа pred_replace на лету и потом передавать на рендеринг. Такой аналог vQmod. Но при желании можно вносить таким образом изменения и в шаблоны без их физической в правки.

Это категорически не правильно! Вся эта тема и создалась для того, чтобы найти некий аналог vqmod-а, который бы дал возможность на программном уровне без правки кода вносить изменения. А тут предлагается полный аналог vqmod-a, мало того имели 1 vqmod, а теперь получим целых 2..

[EVMedvedev]

Вы бы это вынесли в отдельную тему. Так и эта тема была бы чище и отклик получили бы больший.

По доке. Спорный вопрос. Пользы с нее было бы больше если бы в коде использовались правильные комментарии с использование @param, @return, @var, @todo итд. Подобные док креаторы их вроде подхватывают. А так.. посмотреть, что все контроллеры наследуются от главного контроллера, это и так известно. Та и работать со структурой приходится редко, в основном нужен какой-то конкретный класс, который мне например удобнее открыть в редакторе (у меня NetBeans IDE 7.2), который во вкладке Навигатор покажет список всех методов и свойств этого класса, а по клику можно перейти к конкретному методу и посмотреть его код.

Это мое мнение. Но в любом случае за проделанную работу плюсую.

Да не вопрос, если бесполезно, то я зачищу. Мне не долго :-). А докгенератор действительно подхватывает разметку JavaDoc если она в коде есть :-). А если нет, то ...

Кстати даже из доки видна слабость развития структуры классов. Например берешь код многих контроллеров и видишь одни и те же строки вроде формирования хлебных крошек и т.п. Понятно, что можно было вынести это в класс предок, как во многих движках и делается. А на схемах видна убогая одноуровневость. Второй уровень там появился из-за установки движка оверрайд.

[EVMedvedev]

По поводу способа правки шаблонов через preRender в этом движке тоже голосую против. Идиотизм. Но там это предлагалось как возможность, как вариант решения, не обязательная к использованию. Так что сухой остаток пока сам движок оверайда.

[EVMedvedev]

NetBeans хорошая вещь, но я ее в основном использую для работы с JS кодом. Для PHP ZendStudio 7.1 + ZendDebbuger.

[EVMedvedev]

Еще, я считаю нужно, сделать формирование шаблона двух-трехуровневым, т.е. чтобы из одних вьюх можно было инклудить другие.

Да это и сейчас ни кто не мешает делать. Или предлагается сделать специальную дефолтную тему?

Кстати этих <?php без меры натыкано не от большого ума. Когда учть ли не каждый IF в собственные php тэги закрыт. Ну это же бред

<?php if ($categories) { ?>

<?php foreach ($categories as $category) { ?>

<tr>

<td style="text-align: center;"><?php if ($category['selected']) { ?>

<input type="checkbox" name="selected[]" value="<?php echo $category['category_id']; ?>" checked="checked" />

<?php } else { ?>

<input type="checkbox" name="selected[]" value="<?php echo $category['category_id']; ?>" />

<?php } ?></td>

<?php if ($category['href']) { ?>

<td class="left"><?php echo $category['indent']; ?><a href="<?php echo $category['href']; ?>"><?php echo $category['name']; ?></a></td>

<?php } else { ?>

<td class="left"><?php echo $category['indent']; ?><?php echo $category['name']; ?></td>

<?php } ?>

<td class="right"><?php echo $category['sort_order']; ?></td>

<td class="right"><?php foreach ($category['action'] as $action) { ?>

[ <a href=<?php echo $action['href]; ?>"><?php echo $action['text']; ?></a> ]

<?php } ?></td>

</tr>

<?php } ?>

<?php } else { ?>

<tr>

<td class="center" colspan="4"><?php echo $text_no_results; ?></td>

</tr>

<?php } ?>

Ну зачем так

<?php if ($categories) { ?>

<?php foreach ($categories as $category) { ?>

каждую строку в свой тэг.

Неужто так <?php if ($categories) {

foreach ($categories as $category) { ?>

нельзя было хотя бы.

Да тут в половину кож ужать можно.

В конце концов можно перенастроить php в htaccess и использовать короткие phph тэги и исключить использование echo.

[cmd]

toporchillo, не совсем понял. Ты сейчас говоришь про плейсхолдеры (типа, позиций в Joomla и виджетов в WP) в шаблонах? Есть Layouts, но они слишком неповоротливые. Было бы не плохо упростить до одной строчки кода регистрацию нового Layout'a, да.

[cmd]

JS вообще по делу должен быть только в <head> причем не все подряд, а только нужное генерируется динамически...

[cmd]

JS должен быть в файлах .js

... или *.php

<?php header("Content-type: text/javascript"); ?>

Личном мне динамическая генерация нравится.

[EVMedvedev]

А шаблонизаторы типа Smarty попробовать не хотите? Они ограничивают возможности построения сложной логики в шаблонах и тем дисциплинируют.

[EVMedvedev]

Кстати как вариант проблемы с шаблоном - делать как в Magento, там есть так называемая тема blank, то есть без всякого стилевого оформления. Выдается только голый HTML код, на который CSS делается с нуля.

[EVMedvedev]

Smarty хорош, но его сила в эскейпах, форматировании дат и т.л. когда можно {$str|escape:html} делать. Но OpenCart все это делает на уровне контроллера-шаблонизатора. Так же смарти позволяет делать {php}...{/php}, а это уже не очень.

Есть еще шаблонизатор mustache. Плюс в том, что его синтаксис минимальный, но все что надо есть. Вот он точно дисциплинирует.

А еще есть blitz. Минус в том, что нужно ставить отдельный php-модуль, но летает.

Ну сейчас включение PHP тэгов в последней версии Smarty еще настроит надо :-). По умолчанию эта фича отключена. Что касается модификаторов, так в том и смысл, что за счет этого и Smarty плагинов можно снять нагрузку с контроллеров. Например в шаблоны можно было бы перенести переводы, а то сейчас чуть ли не половина кода контроллеров это $бла-бла-бла = $this->language->get('бла-бла').

Но я собственно на самрти не настаиваю, просто предлагаю вариант решения проблемы с шаблонами в ОС. Смарти конечно шаблонизатор тяжелый.

Но тут собственно вопрос не о выборе шаблонизатора, а о том, как подключить какой-то из продвинутых шаблонизаторов к OC с минимальными переделками кода, чтобы эту связку можно было с версии на версию в дальнейшем переносить. Кто возьмется попробовать?

[ingenerks]

http://www.opencart.com/index.php?route=extension/extension/info&extension_id=8588&filter_license=0&filter_download_id=29

[sv2109]

http://www.opencart...._download_id=29

Я уже второй день изучаю этот модуль.. ближайшим временем отпишу что я о нем думаю..

[sv2109]

Итак, Override Engine.

Более-менее разобрался з этим кодом. Задачу очень усложнило то, что там используется собственный стрим врапер.. а я с ними вообще никогда не работал, начал искать что это и зачем оно тут надо, на это ушло немало времени. Плюс много времени забрали другие изощренные методы..

Ну во-первых, как уже писали выше, для изменения шаблонов используется или str_replace или preg_replace или свой хелпер модификатор, который с помощью позиций: before, after, replace и строчных функций на лету изменяет код шаблонов. Ничего не напоминает? Правильно, тот же vqmod только без возможности кеширования и с другой реализацией..

Дальше. Расширение классов. Для этого используется свой класс Factory, в функции которого входит поиск всех модификаций, загрузка всех классов с проверкой есть ли модификация для данного класса, если нету то загружается этот класс, если есть и она одна то загружается класс наследник (эта модификация), а если таких модификаций несколько, несколько модификаций расширяют один и тот же класс.. то ту начинается самое интересное. Загружается первый наследник с помощью require_once. А для всех следующих сначала получают их код с помощью file_get_contents потом с помощью строковых функций изменяют этот код (меняют класс родитель с базового на последнего наследника), после чего загружают это все с помощью потока, получается аналог ф-ции eval (тут более подробно)

Сам процесс замены класса родителя реализован крайне криво. Для этого в цикле по одной букве проверяется каждый символ с помощью методов isWhiteSpace, isLetterOrUnderscore, isLetterOrNumberOrUnderscore итд.. Долго не мог понять что делает этот код пока не запустил его через отладчик. Зачем писать гору запутанного кода там где можно использовать 1 регулярное выражение..

Итог:

1. Для именения шаблонов используется аналог vqmod-а, тот же шарик только в профиль.

2. Для изменения классов используется очень сомнительный подход с кривой реализацией.

3. Добавляется еще один уровень абстракции - Фабрика, которая пропускает через себя все загрузки классов тем самый сильно все усложняет

4. У меня есть большие сомнения насчет скорости работы всего этого

5. Отладка. Не понятно как это все отлаживать, если несколько разных модификаторов переопределят один класс после чего что-то будет работать не так как надо, если все хранится в потоках. Мой отладчик на конструкции require_once( "var://".$var_id ); вообще вырубился..

6. У меня есть сомнения насчет того как это все будет работать при нескольких десятках разных модификаций..

Мне намного бульше нравится идея с хуками и событиями. Она намного проще, прозрачнее, использует общепринятые подходы, не использует стрим врапперов, не модифицирует код строковыми функциями, намного проще в работе и отладке.

[EVMedvedev]

Итог:

1. Для именения шаблонов используется аналог vqmod-а, тот же шарик только в профиль.

2. Для изменения классов используется очень сомнительный подход с кривой реализацией.

3. Добавляется еще один уровень абстракции - Фабрика, которая пропускает через себя все загрузки классов тем самый сильно все усложняет

4. У меня есть большие сомнения насчет скорости работы всего этого

5. Отладка. Не понятно как это все отлаживать, если несколько разных модификаторов переопределят один класс после чего что-то будет работать не так как надо, если все хранится в потоках. Мой отладчик на конструкции require_once( "var://".$var_id ); вообще вырубился..

6. У меня есть сомнения насчет того как это все будет работать при нескольких десятках разных модификаций..

Мне намного бульше нравится идея с хуками и событиями. Она намного проще, прозрачнее, использует общепринятые подходы, не использует стрим врапперов, не модифицирует код строковыми функциями, намного проще в работе и отладке.

По некоторым утверждениям и выводам вынужден не согласиться.

Во первых ни чего сложного в загрузке нет. Используется классическая иерархия классов. А Factory это просто альтернативный автозагрузчик, который грузит классы потомки к базовому классу, взятому из ядра. Не более.

Стримовая загрузка используется не постоянно, а в определенных условиях и сама по себе мало отличается от стандартных методов загрузки PHP-файлов.

Проблемы с отладчиком возникли скорее всего из-за того,что использовался не Zenddebugger а Xdebug. Первый просто с NetBeans не работает по определению.

Задержек в скорости работы не будет. Механизмы загрузки наследуемых классов отработаны практически во всех приличных фрэймворках и используются сегодня повсеместно почти во всех движках (возможно не считая ОС и Друпал). В той же Престе такой механизм используется уже не менее 2- лет. В мадженто соответственно тоже т.к. он на ZF написан.

Отладка работает отлично, если использовать именно наследование классов и надежный отладчик.

При наследовании можно управлять вызовом методов классов предков из классов потомков, что позволяет менять алгоритмы работы кода без потерь производительности.

Механизм оверайда на самом деле единственный надежный механизм развития ОС без модификации исходного кода. Например для подключения развитых шаблонизаторов.

Итого, у меня с IDE ZendStudio 7.1 и Zenddebugger на установку, чтение инструкции и освоение с отладчиком этого движка ушло примерно 2 часа. На загрузки из потоков не заморачивался.

У меня мнение однозначное. Нужно встраивать в базовый конмплект.

В аттаче простейший пример использования.

override.zip

[EVMedvedev]

Кстати я бы vqmod совсем списывать бы не стал. На его основе можно сделать неплохой сборщик кода проекта (по аналогии с Apache Ant), который может пригодиться для сборки версий движка из исходного кода и сделанных нами изменений. Ну естественно это тогда и если мы от слов перейдем к делу :-).

[sv2109]

..Механизмы загрузки наследуемых классов отработаны практически во всех приличных фрэймворках и используются сегодня повсеместно почти во всех движках ..

Если бы там использовалось классическое наследование то я был бы обеими руками ЗА такой механизм. Покажите мне хоть один фреймворк или движок в котором код класса загружается в глобальную переменную с помощью file_get_contents после чего изменяется с помощью строковых функций после чего загружается с помощью потока. Это не решение, это костыль. Чем-то лучше vqmod-а, чем-то хуже то такой-же костыль. И менять один костыль на другой у меня нету вообще никакого желания. Мало того, заменить полностью один на другой скорее всего не получиться так как кто-то будет продолжать использовать vqmod, кому-то больше понравится это решение.. и придется держать на одном сайте их 2.. потому что одни модули будут работать с одним, другие с другим..

[EVMedvedev]

Если бы там использовалось классическое наследование то я был бы обеими руками ЗА такой механизм. Покажите мне хоть один фреймворк или движок в котором код класса загружается в глобальную переменную с помощью file_get_contents после чего изменяется с помощью строковых функций после чего загружается с помощью потока. Это не решение, это костыль. Чем-то лучше vqmod-а, чем-то хуже то такой-же костыль. И менять один костыль на другой у меня нету вообще никакого желания. Мало того, заменить полностью один на другой скорее всего не получиться так как кто-то будет продолжать использовать vqmod, кому-то больше понравится это решение.. и придется держать на одном сайте их 2.. потому что одни модули будут работать с одним, другие с другим..

Подмена имен классов используется в том случае, когда 2 адона наследуют один класс. Если прописано так как в моем примере такой необходимости нет. То о чем вы говорите нужно вкллючать в совокупности с ReflectionClass только для устранения конфликта наследования. Например если в моем примере в адоне 2 в extends вы замените addon_1_ControllerCommonHeader на ControllerCommonHeader. При этом результат работы не изменится.

О замене этим средством полностью vqmod я не говорил, но вообще разработчики всех остальных движков обходятся без vqmod :-).

[sv2109]

..Если прописано так как в моем примере такой необходимости нет.

1. Даже в том варианте, который прописан в вашем примере происходит то, о чем я писал выше - загрузка класса в переменную и последующее изменение его кода с помощью строчных функций. Просто добавьте строчку echo "modFile: " . $modFile . " - parent: " . $parent; в начало метода modifyParent класса Factory, он как раз и отвечает за изменение родительского класса.

2. Даже если бы это работало то это не вариант. Так как этот механизм создается прежде всего для модулей. А один модуль вообще ничего не может знать о других.

но вообще разработчики всех остальных движков обходятся без vqmod :-).

Потому и обходятся что у них есть нормальные механизмы переопределения без правки кода.. vqmod там просто не нужен и другие подобные костыли тоже.

[EVMedvedev]

sv2109. По п. 1 действительно - нашел этот косяк. Не всегда уместная проверка правильности наследования класса его положению и наименованию в структуре адонов. Срабатывает он в случаях когда на один контроллер или модель приходится более одного адона. Да так собственно и в документации написано. Следовательно 2 час на освоении этого движка оказалось маловато. Но если учесть, что для приведенного мной примера на стартовой странице сайта на данный меречень классов

Config

Db

Url

Log

Request

Response

Cache

Session

Language

ModelLocalisationLanguage

Document

Customer

Affiliate

Currency

Tax

Weight

Length

Cart

Encryption

ControllerCommonMaintenance

ControllerCommonSeoUrl

meta_keywords_ControllerCommonHome

ControllerCommonColumnLeft

ModelDesignLayout

ModelCatalogCategory

ModelCatalogProduct

ModelCatalogInformation

ModelSettingExtension

ControllerCommonColumnRight

ModelDesignLayout

ModelCatalogCategory

ModelCatalogProduct

ModelCatalogInformation

ModelSettingExtension

ControllerCommonContentTop

ModelDesignLayout

ModelCatalogCategory

ModelCatalogProduct

ModelCatalogInformation

ModelSettingExtension

ControllerModuleSlideshow

ModelDesignBanner

ModelToolImage

ControllerModuleFeatured

ModelCatalogProduct

ModelToolImage

ControllerCommonContentBottom

ModelDesignLayout

ModelCatalogCategory

ModelCatalogProduct

ModelCatalogInformation

ModelSettingExtension

ControllerModuleCarousel

ModelDesignBanner

ModelToolImage

ControllerCommonFooter

ModelCatalogInformation

Загрузка через поток с проверкой имен адонов запускалась всего 1 раз, потери времени будут, очевидно, не существенными. Наибольшая потеря возможна при многократной модификации ModelCatalogCategory, которая загрузка которого проводится многократно. Тут они точно напороли, потому что не трудно проверить на входе наличие класса в памяти а не полагаться на require_once.

По пункту второму, относительно работоспособности тут собственно сомневаться не о чем, так как движок работает. Кроме того, движок создавался не только и не столько для модулей, сколько именно для контроллеров и моделей (для классов ядра пока не пробовал) и именно для того, чтобы их можно было менять не трогая исходного кода движка. Оверайд это единственный способ сделать это. Любые другие варианты, вроде хуков и т.п. либо требуют модификации исходного кода, либо наложения на исходник другого кода. В том же Друпале хуков понапихано немеряно и чтобы использовать их в OC придется тоже напихать их столько же, а значит либо редактировать исходный код, либо накладывать свой через оверайд. Третьего не дано, как говорится.

Все кто обходится без vqmod работают через оверрайд и очень часто используют модификации наименований классов. Опять же если рассмотреть Prestashop как одного из ближайших и весьма успешных конкурентов OC там механизм сделан примерно так же. Есть базовый класс, например ProductCore и в каталоге override может лежать класс Product extends ProductCore. Если если есть оверрайд, то все грузится обычным порядком, а вот если оверрайда нет (то есть штатный режим), то ProductCore грузится в память, а потом теми же методами ProductCore переводится в Product. Все это делается соответствующим автолоадером при создании объекта заданного класса то есть в нашем случае при запуске new Product (). И там это работает не для 1 класса на 2 десятка а на каждый из примерно того, же набора, что и для ОС. И ни чего. Все прекрасно работает.

Так что я уверен, что минусов у предлагаемого решения меньше всех по сравнению с другими вариантами, а вот возможности для решения нашей целевой задачи, о которой, я надеюсь, мы еще на забыли окончательно :-), огромные.

[EVMedvedev]

Кстати, пробовал ставить движок на версии 1.5.3 и 1.5.1.3. Работает как часы. Таким образом переносимость наработок под этот движок вполне на высоте.

[Гість]

Привет 1.5 человека.

Я понимаю, что в данной ветке хотели собрать что-то в одном направлении, но...

Прелюдия.

Надо был инет-магазин, а поскольку фриланс - это подработка, то надо был двиг - удобный, с кучей модулей, простой php код, потому что разработка ведется после основной работы. Joomla ненавижу, друпал, зенд и др. посмотрл код и зразу от них отказывался: для знакомства с ними надо время, которого мало. Нашел OpenCart и понеслось.

Из опыта. (может и повторю проблему)

Контролллеры.

Куча ненужного кода. Например при формировании массива товаров. Приходится впихивать поля и значения в массив, тогда как в модели они могли быть уже получены и возвращены массивом (либо через foreach, либо просто как результат запроса). Зачем переливать по сто раз туда сюда данные?

Хлебные крошки, которые уже обсуждались.

Модели

Не структурировано или как обозвать. Если получаешь массив, то надо получать его везде одинаково, а не так, что в одном месте проходить цикл foreach причем еще налету менять что-то, а в другом месте выкинуть результат в контролер.

Не рационально. Получение массива товаров часто сводится к получению id товаров, потом получить каждую запись в отдельности. Маразм...

Редактирование товаров, сначала удаление всего, а потом добавление. Но тут бы реально сделать админку на ajax и налету синхронизировать товар.. удобно...

Вьюхи

я ЗАДОЛБАЛСЯ, да что тут.... затрахался! я исправлять шаблон вывода товара в списке(исправить search, category, потом еще в product секцию с related)! И это не предел. А кто-нить часто пользуется разными шаблонами вывода? кардинально разными...? Может вынести это в один шаблон?

Куча php разметки затрудняющей чтение кода и верстки.

+большое неудобство в разбросе модуля по разным директориям..

Итог.

Легкий двиг для разоработки, но не гибкий: на каждом проекте я много чего меняю в коде...

Почитав про симфони и оверрайды заинтересовался, интерестная идея, НО вам не кажется, что вы напишите столько оверрайдов и диспатчеров, что это будет больше тянуть на новый движок, чем просто дополнение к существующему коду?

Я вижу целесообразность диспатчеров и оверлоадеров для привлечения людей(пользователей) к доработке. С последующим выходом на отдельное концептуальное решение. Но я готов сотрудничать и сейчас.

А теперь фкусняшка.

1. Возьмем ненавистную мне Joomla. У нее плюс я вижу в том, что есть спец классы html. Например делаем класс Select, класс email. Согласитесь, как приятно было бы напихать в select опции а потом в шаблоне вставить OCSelect->render()

2. Опять таки Joomla. У нее есть шаблон, который не надо тягать везде, 1 шаблон на весь сайт - index.php Но вы скажете - что делать, если надо другую схему сделать?

3. А тут приходит santafox. Можно прикручивать свой шаблон для каждой страницы. Opencart? может, но лежат шаблоны в одном месте и они выполняют родь скелета. В opencart есть обобщающий home.tpl - но он слабоват...

4. Модули - опять santafox у руля. Есть модуль, а у модуля есть действия. Инсталлим модуль (как в opencart - и все... что вы еще можете сделать? на разных страницах его использовать - это для пользователя, мне говорили что лэйаутами можно настроить, но мне было тяжко смотреть на эти селекты - я так и не осилил этот вопрос). Дальше создаем действие - настраиваем параметры (кто смотрел мои демки у меня есть модуль Вы смотрели - и там я пользую 2 шаблона, это пришло оттуда) Например, устанавливаю модуль меню. Создаю действие - Древовидное меню, указываю, что оно будет отображать 2 уровень структуры, задаю шаблон1. Создаю еще одно действие и создаю действие - линейное меню с шаблон2. Потом говорю, что мне надо эти действия отобразить там-то и там-то и все. Есть также наследование отображения.

Т.о. Мы можем создать шаблоны для действий, а не для модуля в целом и пользовать их на той или иной странице.

5. Поля. Кто работал с sugarcrm? руку под-нять! Вот там-то и есть тот самый шуга... есть vardef, который описывает поля, да - это доп файл, но это файл, который отображает отчасти структуру БД (например, есть массив филдов - 'name' => 'field1', 'type'=>'int') и т.д. которыми можно управлять. Легко работать с базой, контроллером, вьхами и пр. делами. Есть средства по определению проперти в классе, но не катит.

Не судите строго) это лишь мое видение.

[cmd]

оффтоп

Третью неделю пишу проект на CodeIgniter. Да, не хватает чего-то по мелочам, но какое удовольствие: сидишь, кодишь, не чертыхаешься при виде кода ядра, документация в порядке