sv2109

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

99 сообщений в этой теме

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

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

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

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

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

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

0

Поделиться этим сообщением


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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Итак, 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. У меня есть сомнения насчет того как это все будет работать при нескольких десятках разных модификаций..

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

2

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Итог:

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

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

2

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 десятка а на каждый из примерно того, же набора, что и для ОС. И ни чего. Все прекрасно работает.

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

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

2

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Привет 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') и т.д. которыми можно управлять. Легко работать с базой, контроллером, вьхами и пр. делами. Есть средства по определению проперти в классе, но не катит.

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

2

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

оффтоп

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

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Друпал и Опенкарт это 2 крайности. А истина она всегда где-то посередине. Тут нужно выбрать эту золотую середину. Например, следуя правилу Паретто - 20% хуков покроет 80% потребностей, а для остальных 20% нужно будет написать еще 80% хуков. Если реализовать все то получится Друпал, супер гибкий но и очень сложный. А можно добавить всего несколько хуков и получить достаточно гибкую систему не сильно ее усложняя.

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

Симфони диспатчер подключается с помощью нескольких строк кода, новое событие добавляется с помощью 1-2 строк кода.. все. Зачем для 10 строк кода создавать новый движок?..
1

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, я давно понял, что нету ничего универсального, гибкого и простого... к сожалению...

Симфони диспатчер подключается с помощью нескольких строк кода, новое событие добавляется с помощью 1-2 строк кода.. все. Зачем для 10 строк кода создавать новый движок?..

Безусловно, моя ошибка в том, что не опробовал на практике симфони + опенкарт, но я увидел пример про сокрытие статьи из списка через хук и ,опираясь на него, увидел проблему - это обычный костыль if (information['id'] == 3) пропустим статью и не отображаем. Только вот у симфони надо написать целый обработчик как себя вести в той или иной ситуации, с какими переменными работать и так далее, что, на мой взгляд, труднее, чем написать модуль для статей и определить для него параметры под свои нужды.

Может я не понял пример, но я понял вот его так - у меня есть модуль статей и я хочу выводить на каждой странице ленту статей по-своему: 1. в заданном мною порядке. 2. удаляя некоторые статьи из списка, 3. добавляя описание к статье(ко всем или конкретной), 4. делать ссылку или нет, 5. рейтинг статьи и т.д. Получается мне надо написать 5 хуков? Правильно?

Ладно, вернемся к проблеме и прекратим демагогию. Идея с симфони мне нравится, потому что это будет однозначно лучше, чем просто костыли в коде для реализации той или иной задачи.

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может я не понял пример, но я понял вот его так - у меня есть модуль статей и я хочу выводить на каждой странице ленту статей по-своему: 1. в заданном мною порядке. 2. удаляя некоторые статьи из списка, 3. добавляя описание к статье(ко всем или конкретной), 4. делать ссылку или нет, 5. рейтинг статьи и т.д. Получается мне надо написать 5 хуков? Правильно?

Тут как раз OpenCart нормально работает, когда надо на страницу прилепить какой-нибудь виджет, не сильно завязанный на контент самой страницы. Пишешь модуль и добавляешь его на страницы через админку, редактируя свойства этого модуля. Так добавляются всякие меню, карусели, баннеры, формы "заказать звонок".

Проблема начинается, когда надо сделать, чтобы готовый интерфейс (тот же заказ товаров) работал как-то иначе.

Ну и бесспорно, не хватает нормальных моделей, инструментов для конструирования форм.

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ладно, вернемся к проблеме и прекратим демагогию.

И что вы с проблемой собираетесь делать? Дальше обсуждать? Получится все та же демагогия :-). Она уже образуется. Все опять складывается в стиле "хотим как лучше, а получается как всегда".

1

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я начало сделал. Дальше это все нужно развивать, вперед! Я пока не имею достаточно времени, смогу поддержать минимум через неделю-полторы.

Что нужно сделать:

1. Допилить модуль :

- нужно добавить поддерку админки,

- сделать возможность установки через vqmod (чтобы упростить тестирование другим разработчикам)

- добавить несколько событий через vqmod (подумать где еще кроме рендера они будут полезны), на каждое событие отдельный vqmod (чтобы проще было потом добавлять другие события другим разработчикам)

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

- написать документацию (рус, анг)

2. Протестировать все

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

Вперед, кому интересно развивать тему!

1

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Думаю все "1.5 человека" заняты в коммерческих проектах, поэтому не паникуем, просто подписываемся на тему и ждем развития.

Я планирую в конце месяца заняться вопросом. Все что тут пишут читаю.

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Думаю все "1.5 человека" заняты в коммерческих проектах, поэтому не паникуем, просто подписываемся на тему и ждем развития.

Я планирую в конце месяца заняться вопросом. Все что тут пишут читаю.

Тут все читают и пишут. А нужна стратегия и согласованность действия, а значит грамотная координация. А пока получается "кто в лес, кто по дрова". Например шаблон наблюдатель хороший шаблон ООП, но о имеет определенную область ЭФФЕКТИВНОГО использования (системы построенные на событиях, пользовательские или межсистемные интерфейсы например ну лили как здесь предлагают http://habrahabr.ru/post/136766/), которая в OC практически мало имеет места. Притянуть и пристроить его конечно можно, в научных целях, но практического применения это будет мало иметь. Тем более что опять возвращаемся к тому, от чего хотели уйти, а именно от модификации кода ядра и vQmod. То есть топчемся на месте. Так что паники на какой, пока все идет "как всегда" :-).

1

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, если кому интересно, решением для введения шаблона ООП Event-Observer может быть создание оберток для всех основных классов ОС с перехватом вызовов методов, и таким образом можно будет подцеплять вызовы функций до и после вызова методов, практически без модификации кода ОС (поменять можно только index.php для подключения wrapper).

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, если кому интересно, решением для введения шаблона ООП Event-Observer может быть создание оберток для всех основных классов ОС с перехватом вызовов методов, и таким образом можно будет подцеплять вызовы функций до и после вызова методов, практически без модификации кода ОС (поменять можно только index.php для подключения wrapper).

 

Люблю заниматься архитектурой приложений :)

Это как стратегическая игра. Увлекательно и интересно!

 

Уже пользуюсь (есть своя реализация)...

...

function __call($method, array $params)

...

:)

"Слушать" классы - самый лучший вариант избавиться от vqmod, при этом не "мешая" его работе

И index.php не зачем менять, лучше дописать (можно автоматом, в конец файла, даже пользователь не заметит) в конец controller/common/maintenance.php свой роутер обвертку  классов. И потом просто "слушать" классы и что надо менять до или после его работы.

Сейчас я пока  руками прописываю какие мне надо классы "слушать", меняю всё что захочу, там возможности изменения работы безграничны. Такой себе hook универсальный для opencart

 

Надо полноценный модуль такой сделать :) В настройках просто прописывать какой класс и метод слушать и как, до или после, и каким классом "менять" результаты или параметры. (связи). Тогда вообще просто свои модули будет подключать не изменяя файлов системы и без vqmod, при этом не "мешая" его работе.

 

P.S. А шаблон Event-Observer - предполагает на начальном этапе разработки ядра так делать, что в нашем случае не походит. Это шаблон проектирования ядра, а не обвертка уже готового

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, если кому интересно, решением для введения шаблона ООП Event-Observer может быть создание оберток для всех основных классов ОС с перехватом вызовов методов, и таким образом можно будет подцеплять вызовы функций до и после вызова методов, практически без модификации кода ОС (поменять можно только index.php для подключения wrapper).

 

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

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Для шаблонизации оберточный вариант конечно не подходит. Если только не подменять вывод своим шаблонизатором :-).

0

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!


Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.


Войти

  • Недавно просматривали   0 пользователей

    Ни один зарегистрированный пользователь не просматривает эту страницу.