Создание своего модуля и избавление от vqmod

[RGB]

У меня вопрос к опытным разработчикам - надоело ставить костыли в шаблоны и решил приобщиться к таинствам разработки человеческих модулей для перенесения настроек шаблона в админку. Я взял болванку готового модуля, очистил ее от лишнего и получилось нечто, что имеет в настройках лишь переключатель yes/no, соответственно если выбран yes, то значение единственного свойства модуля (mymoduleproperty) равно 1. Потом я добавил в контроллер product.php такой кусок

$this->data['mymodule_settings'] = $this->config->get('mymodule_settings');
if ($this->config->get('mymodule_mymoduleproperty')) {		
  $this->data['mymoduleproperty'] = $this->config->get('mymodule_mymoduleproperty');
} else {
 $this->data['mymoduleproperty'] = false;
}

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

 

Поэтому вопрос - как правильно это сделать БЕЗ vqmod и перезаписи, если мне модуль нужен лишь как место хранения и изменения настроек шаблона? 

[sv2109]

какого-то простого способа это сделать я не знаю.. потому что в опенкарте к огромному сожалению просто нету нормального апи с помощью которого можно программно из своего модуля изменить код какого-то другого контроллера.. 

 

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

[RGB]

А почему нельзя вот так?

<?php
    $mymoduleproperty = $this->config->get('mymodule_mymoduleproperty'); 
    echo $mymoduleproperty;
?>

Без внесения изменений в контроллер, у меня вроде бы сработало и в шаблоне главной, и на странице товара (этот кусок кода внутри шаблона)

[sv2109]

А почему нельзя вот так?

<?php
    $mymoduleproperty = $this->config->get('mymodule_mymoduleproperty'); 
    echo $mymoduleproperty;
?>

Без внесения изменений в контроллер, у меня вроде бы сработало и в шаблоне главной, и на странице товара (этот кусок кода внутри шаблона)

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

[Einshtein]

контроллер нужен для нормальной совместимости дополнений и тех же шаблонов. Все привыкли что переменные в целом всегда одинаковые и ими стало проще манипулировать. 
 

у меня уже недели две вертится в голове интересная идея по написанию одного модуля который будет  предлагать вносить коррективы в магазине. Но ввиду того что этих изменений будет очень много и в основном они касаются пользовательской части - я в панике, так как столько vqmod'ов писать бред, еще и сохранив 90% хотябы совместимость с большинством шаблонов. 

Предлагаю коллективно подумать над  альтернативой vqmod

[RGB]

контроллер нужен для нормальной совместимости дополнений и тех же шаблонов. Все привыкли что переменные в целом всегда одинаковые и ими стало проще манипулировать. 

 

у меня уже недели две вертится в голове интересная идея по написанию одного модуля который будет  предлагать вносить коррективы в магазине. Но ввиду того что этих изменений будет очень много и в основном они касаются пользовательской части - я в панике, так как столько vqmod'ов писать бред, еще и сохранив 90% хотябы совместимость с большинством шаблонов. 

Предлагаю коллективно подумать над  альтернативой vqmod

Насколько я понимаю, вышеприведенный пример с $this->config->get позволяет не думать о совместимости, если речь идет о настройках пользовательской части, потому что не трогает существующие контроллеры, а значения того, что юзер настроит в админке, будут доступны в любом месте любого tpl-файла, хотя это и не правильно с точки зрения mvc. sv2109 еще выше написал способ с яваскриптом и аяксом, но сомневаюсь, что реализовать его будет просто  :-)

 

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

 

[Einshtein]

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

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

[Baco]

Попробую скорректировать, $this->config->get('tvoj_config'); - это лишь конфиг, который значение (не только булево) вносит в БД, можно переполнять таблицу setting но достигнуть того эффекта, что имеет vQmod нельзя, так как виртуальный модификатор, парсит сам код, и вносит изменения (в вашем примере это ваш же $this->config->get('tvoj_config'); в нужное место, программно же реализовать такое, будет сложновато, тоесть написание модуля - это написание модуля с его конфигами, а использование vQmod-а - это отдельная тема для разговора, вот есть темка, где раньше поднимался вопрос об отказе от виртуального модификатора.

 

P.S. Использование же вызовов конфига непосредственно в TPL - даже не рассматриваю, и называю такой стандарт кодирования по определению, фекалиеподобным... мягкоговоря.

[RGB]

P.S. Использование же вызовов конфига непосредственно в TPL - даже не рассматриваю, и называю такой стандарт кодирования по определению, фекалиеподобным... мягкоговоря.

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

[sv2109]

Попробую скорректировать, $this->config->get('tvoj_config'); - это лишь конфиг, который значение (не только булево) вносит в БД

 

тут один момент:  все данные в $this->config заружаются при загрузке системы, а потом просто считываются готовые данные из массива, поэтому 

 

P.S. Использование же вызовов конфига непосредственно в TPL - даже не рассматриваю, и называю такой стандарт кодирования по определению, фекалиеподобным... мягкоговоря.

да, я тоже склоняюсь к строгому mvc но если есть варианты:

1. сложный: создать отдельный контроллер, яваскрипт файл, сделать какие-то аякс запросы итд. короче очень сильно усложнить код + это не всегда поможет

2. использовать vqmod со всеми последствиями

3. использовать в шаблоне $this->config->get('tvoj_config'); 

то я бы использовал 3 вариант, тем более что kiss + учитывая то что данные берутся из готового массива то конструкция 

echo $this->config->get('tvoj_config'); 

почти ничем не отличается от 

echo $my_array['var'];

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

 

[Baco]

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

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

Практический пример №1:

catalog\controller\module\moj_config.php

<?php
class ControllerModuleMoj_config extends Controller {
	private $error = array();	
	
	public function index() {

        $config_data = array(
			'config_page_1',
			'config_page_2',
			'config_page_3',
			'config_page_4',				
			'config_page_5',		
			'config_page_6',	
			'config_page_7',
			'config_page_8',
			'config_page_9',
			'config_page_10',
			'config_page_11',
			'config_page_12',
			'config_page_13',
			'config_page_14',
			'config_page_15'
        );


     foreach ($config_data as $conf) {
        $config = $this->cache->get('config.my_page' . (int) $this->config->get('config_language_id'));
		
		if (!$config) {
			$this->data[$conf] = $this->config->get($conf);
			$this->cache->set('config.my_page' . (int) $this->config->get('config_language_id'),$conf);
		} else {		
			$this->data[$conf] = $config[$conf];
		}
            
    }
...

в самом ТПЛ файле уже выводим по типу <?php echo $config_page_12; ?> в нужном месте...

 

P.S. Валидность кода не проверял, писал из головы логику...

[RGB]

А зачем кешировать настройки шаблона? Вы представляете, сколько раз юзер может "играться" с цветами или отступами, пока подберет подходящую комбинацию и настроит шаблон так, как ему нравится, и что - ему придется каждый раз чистить кеш? Но фиг с ним, с кешем, я все равно не понимаю другой момент:

 

в самом же модуле, разобрать сам массив из кеша, присвоив значения переменных соотвественным значениям view файла

модуля в пользовательской части ведь нет как такового

[Baco]

А зачем кешировать настройки шаблона? Вы представляете, сколько раз юзер может "играться" с цветами или отступами, пока подберет подходящую комбинацию и настроит шаблон так, как ему нравится, и что - ему придется каждый раз чистить кеш? Но фиг с ним, с кешем, я все равно не понимаю другой момент:

 

модуля в пользовательской части ведь нет как такового

согласен, с кешированием - перегнул... а вот по поводу пользовательского, то ничего не мешает создать вам пустой тпл, где в качестве кода, распишите стили своего конфига, будет а-ля "модуль-стайлшит" (©) где в клас подгружаються <?php echo $config_page_12; ?>, по крайней мере хоть кодеру проще будет ориентироваться в вашем шабе, с таким модулем, чем читать между строк 

<?php

$mymoduleproperty = $this->config->get('mymodule_mymoduleproperty');

echo $mymoduleproperty;

?>

P.S. Если что, могу подсобить с конструкцией.

[RGB]

Я приблизительно понял идею - в catalog/controller этого пустого модуля передаются настройки шаблона, соответственно я смогу их использовать в tpl-файле этого модуля, но как мне получить к ним доступ в других файлах шаблона, в том же header.tpl например? Разве для этого не нужно будет модифицировать контроллер header.php?

[Baco]

Здесь есть несколько путей, можно просто в контроллере header.php подключить тут:

$this->children = array(
			'module/language',
			'module/currency',
			'module/cart',
                        'module/mine_conf'
		);

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

<style>
. body {
background: #<?php echo $config_page_14; ?>;
}
</style>

[RGB]

Здесь есть несколько путей, можно просто в контроллере header.php подключить тут

 

..и в результате сделать именно то, от чего я предлагаю избавиться в первом сообщении этой темы :)

 

вам надо поприсваивать всего навсего классы

А вот отсюда можно подробнее? Где и как это сделать?

[sv2109]

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

 

файл конфига должен лежать в /system/config

подгрузить можно через $this->load->config('filename');

или через $this->config->load('filename');

после чего все данные из этого файла будут доступны в массиве конфига через $this->config->get('foo');

 

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

[Baco]

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

 

файл конфига должен лежать в /system/config

подгрузить можно через $this->load->config('filename');

или через $this->config->load('filename');

после чего все данные из этого файла будут доступны в массиве конфига через $this->config->get('foo');

 

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

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

 

..и в результате сделать именно то, от чего я предлагаю избавиться в первом сообщении этой темы :)

 

А вот отсюда можно подробнее? Где и как это сделать?

catalog\controller\module\moj_config.php

вставляем что то типа этого:

<?php
class ControllerModuleMoj_config extends Controller {
	private $error = array();	
	
	public function index() {

        $config_data = array(
			'config_page_1',
			'config_page_2',
			'config_page_3',
			'config_page_4',				
			'config_page_5',		
			'config_page_6',	
			'config_page_7',
			'config_page_8',
			'config_page_9',
			'config_page_10',
			'config_page_11',
			'config_page_12',
			'config_page_13',
			'config_page_14',
			'config_page_15'
        );


		 foreach ($config_data as $conf) {
					
			$this->data[$conf] = $config[$conf];
			  
		}
		
		if (file_exists(DIR_TEMPLATE . $this->config->get('config_template') . '/template/module/moj_config.tpl')) {
			$this->template = $this->config->get('config_template') . '/template/module/moj_config.tpl';
		} else {
			$this->template = 'default/template/module/moj_config.tpl';
		}
		$this->render();
	}
?>

а уже в самом catalog/view/theme/default/template/module/moj_config.tpl

Пишем что то типа этого:

<style type="text/css">
#id-form {display:<?php echo $config_page_5; ?>;}
#id-form_2 {background-color:#<?php echo $config_page_11; ?>; cursor:wait;}
#id-content {height:
<?php if ($theme_config == 1 && $config_page_10 == 1) {?>
450
<?php } elseif ($theme_config == 1 && $config_page_10 == 0) { ?>
330
<?php } elseif ($theme_config == 0 && $config_page_10 == 1) { ?>
370
<?php } else { ?>
250
<?php } ?>px; width:560px;
.class-header {background: #<?php echo $config_page_14; ?>;}
</style>

ну а сами классы - по шаблону стандартно, например <div class="box-heading"> заменить на <div class="class-header">

[RGB]

...

ну а сами классы - по шаблону стандартно, например <div class="box-heading"> заменить на <div class="class-header">

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

 

Скажем, в админке в настройках шаблона может быть переключатель colorbox или fancybox или cloudzoom, соответственно для каждого случая в product.tpl код вывода изображений будет разным, будут разные атрибуты rel и т.п., соответственно понадобится ставить условие внутрь шаблона, что мол если юзер в админке выбрал colorbox, то вывести все так и так, а если fancybox, то иначе. И для вывода значений для проверки этого условия использовать контроллер модуля (даже скрытого) не получится, потому что он будет действовать лишь в пределах нашего файла шаблона moj_config.tpl, понимаете?

 

Или вот пример настроек из демки шаблона sellegance, там даже тип слайдшоу есть:

 

 

 

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

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

[Baco]

Вопрос более глобальный...

Для переключалки библиотек, использовать те же конфиги через модуль, но с помощью функции:

$this->document->addScript

и стилей (прямо в хедер) с помощью:

$this->document->addLink

Так как в каждом header.tpl есть код типа:

<?php foreach ($links as $link) { ?>
<link href="<?php echo $link['href']; ?>" rel="<?php echo $link['rel']; ?>" />
<?php } ?>

и 

<?php foreach ($scripts as $script) { ?>
<script type="text/javascript" src="<?php echo $script; ?>"></script>
<?php } ?>

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

[markimax]

У меня вопрос к опытным разработчикам - надоело ставить костыли в шаблоны и решил приобщиться к таинствам разработки человеческих модулей для перенесения настроек шаблона в админку. Я взял болванку готового модуля, очистил ее от лишнего и получилось нечто, что имеет в настройках лишь переключатель yes/no, соответственно если выбран yes, то значение единственного свойства модуля (mymoduleproperty) равно 1. Потом я добавил в контроллер product.php такой кусок

$this->data['mymodule_settings'] = $this->config->get('mymodule_settings');if ($this->config->get('mymodule_mymoduleproperty')) {		  $this->data['mymoduleproperty'] = $this->config->get('mymodule_mymoduleproperty');} else { $this->data['mymoduleproperty'] = false;}

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

 

Поэтому вопрос - как правильно это сделать БЕЗ vqmod и перезаписи, если мне модуль нужен лишь как место хранения и изменения настроек шаблона? 

 

Можно вообще ничего не перезаписывать. Главное иметь управление над registry (именно слушать класс) (там отслеживаются все вызовы, в принципе, это как "семафор").

Вообще можно, через библиотеки и модели "прослушивать", - перехватить вначале registry управление, для того чтобы потом отслеживать передачу управления всем кто затребует стандартную "библиотеку". А контроллеры не обязательно перехватывать, можно через модели подсовывать нужные данные а если не хватает, то досчитывать через перехват registry engine. Задача далеко не тривиальная правда, надо много моментов и нюансов иметь ввиду.

 

P.S. ... дело в том что даже когда вы вызываете $this->model_catalog_category->getCategory

То метод get в классе Registry - получает параметр model_catalog_category, а как подменить или прослушать уже дело техники

Самая большая задача стояла как перехватить без изменений файлов системы class Registry - он то ведь final и его параметр private ($data), но данную задачу решил.

Змінено 17 лютого 2014 користувачем markimax

[RGB]

Чтобы не плодить темы, спрошу здесь - продолжая "строительные" работы, столкнулся с еще одним препятствием. Хочу в шаблоне вывести текст "Рейтинг", но беда в том, что в самом ОС такой текст в любой локализации (именно одно слово) хранится лишь в языковом файле сравнения, соответственно чтобы вывести это слово в нужном месте на странице категорий например, нужно подгрузить в контроллере категорий значение этой языковой переменной (через вкмод или напрямую в шаблоне) 

$this->language->load('product/compare');

Но в каждом из 5 контроллеров категорий, поиска, акций и т.п. мне кажется избыточным делать это, ради одного лишь слова. Поэтому вопрос - создавать в своем языковом файле то, что уже есть в родных файлах? Или еще появилась идея - может создать глобальную переменную $GLOBALS['supertemplate_text_rating'], которой сразу в контроллере header например присваивать нужный мне текст, чтобы потом эту глобальную переменную с уже присвоенным текстом использовать во всех нужных местах - т.е. на страницах каталога, поиска, акций, брендов?

[RGB]

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

[freelancer]

вы можете добавить свой текст в файл языка /language/russian/rissian.php например, а в шаблоне использовать так

<?php echo $this->language->get('supertemplate_text_rating')?>

в модуле всплывающей корзины загрузка всех текстовых констант реализована одной строкой

$this->data += $this->load->language('module/cartpopup');

для простоты разработки я бы добавил аналогичный код в system/engine/front.php перед вызовом index

Змінено 18 квітня 2014 користувачем freelancer

[RGB]

Спасибо, думал насчет этого (использовать основной файл языка), но очень хочется обойтись вообще без изменения файлов движка (не считая шаблона) и без vqmod. У вас в модуле интересно все сделано, и все таки его текстовые константы ведь нельзя вывести в произвольном месте шаблона, а значит придется все равно в каждом из контроллеров (или шаблонов, если не трогать контроллеры) загружать его язык.