Comments 21
0
Оформляйте в source и уберите упоминание о code. Код нечитаем
+1
Вообще метод немного странный. То есть, вместо того, чтобы полностью сменить контекст, мы используем другой контекст чисто как хранилище настроек для поддомена, но без полной его перезагрузки, чтобы формально оставаться в web-контексте?
А чем смена контекста мешала как раз? До чего именно было сложно добраться? (примерчик небольшой юз кейса) Спрашиваю поскольку сам собираюсь делать мультидоменный сайт.
А чем смена контекста мешала как раз? До чего именно было сложно добраться? (примерчик небольшой юз кейса) Спрашиваю поскольку сам собираюсь делать мультидоменный сайт.
0
Объясню.
Прежде всего давайте обратим внимание на структуру документов. У нас все документы (в данном случае в том числе и документы акций, которые фактически разбиты по городам) все находятся в одном контексте web. Вообще изначально сайт работал только по Москве, соответственно даже акции из других городов все равно были в одном контексте.
Шаг первый (точнее глобальные перемены): у нас появился партнер, для кого был создан клон сайта pro-cent.pro. По факту, это тот же сайт, то есть вообще тот же, только у нас новый контекст, который имеет свои индивидуальные настройки, которые перетирают то, что надо. Если бы мы переключались полностью в другой контекст, нам надо было бы обеспечить и наличие всех остальных документов для этого же контекста. То есть плодить копии документов? Нафига? Нет, у нас все едино, только небольшие изменения (смотрим копирайты в нижнем левом углу и страничку о компании http://pro-cent.ru/about.html и http://pro-cent.pro/about.html).
Шаг 2. Мобильная версия (пока не доделана) http://m.pro-cent.ru/. Все тоже самое: документы контекста те же, а выводимая структура, шаблоны и т.п. другие.
И еще один очень весомый аргумент: в настройках MODx помимо всего прочего содержатся имена исполняемых классов и т.п., к примеру modRequest и modResponse. Вот в мобильной версии мне необходимо было несколько изменить базовые классы, но редактировать код движка — совсем не круто, по-этому мы создаем свой класс и расширяем базовый.
Прежде всего давайте обратим внимание на структуру документов. У нас все документы (в данном случае в том числе и документы акций, которые фактически разбиты по городам) все находятся в одном контексте web. Вообще изначально сайт работал только по Москве, соответственно даже акции из других городов все равно были в одном контексте.
Шаг первый (точнее глобальные перемены): у нас появился партнер, для кого был создан клон сайта pro-cent.pro. По факту, это тот же сайт, то есть вообще тот же, только у нас новый контекст, который имеет свои индивидуальные настройки, которые перетирают то, что надо. Если бы мы переключались полностью в другой контекст, нам надо было бы обеспечить и наличие всех остальных документов для этого же контекста. То есть плодить копии документов? Нафига? Нет, у нас все едино, только небольшие изменения (смотрим копирайты в нижнем левом углу и страничку о компании http://pro-cent.ru/about.html и http://pro-cent.pro/about.html).
Шаг 2. Мобильная версия (пока не доделана) http://m.pro-cent.ru/. Все тоже самое: документы контекста те же, а выводимая структура, шаблоны и т.п. другие.
И еще один очень весомый аргумент: в настройках MODx помимо всего прочего содержатся имена исполняемых классов и т.п., к примеру modRequest и modResponse. Вот в мобильной версии мне необходимо было несколько изменить базовые классы, но редактировать код движка — совсем не круто, по-этому мы создаем свой класс и расширяем базовый.
0
Шаг 2. Мобильная версия (пока не доделана) m.pro-cent.ru/. Все тоже самое: документы контекста те же, а выводимая структура, шаблоны и т.п. другие.
Можно по подробнее, как с помощью подмены контекстов вы заменили шаблоны у страниц…
0
Вопрос хороший…
У меня шаблонизация немного через костыли. Я не храню HTML в шаблоне. Там только сниппет а-ля [[!diz?file=`inc.partnerActions.php`]]
А сниппет подгружает PHP-файл.
Формируемый путь до файла строится с учетом настройки, которая и перегружается при смене контекста.
А дальше или смарти или чанки.
Вообще минус шаблонов MODx в том, что нельзя в них писать чистый PHP. Даже начиная с более старших версий, когда пошли статические шаблоны, эта проблема не решилась. Потому и приходится такие костыли лепить.
У меня шаблонизация немного через костыли. Я не храню HTML в шаблоне. Там только сниппет а-ля [[!diz?file=`inc.partnerActions.php`]]
А сниппет подгружает PHP-файл.
<?php
!$dir ? $dir = 'site_template' : "";
require_once MODX_BASE_PATH.$modx->getOption($dir, null, '')."{$file}";
Формируемый путь до файла строится с учетом настройки, которая и перегружается при смене контекста.
А дальше или смарти или чанки.
Вообще минус шаблонов MODx в том, что нельзя в них писать чистый PHP. Даже начиная с более старших версий, когда пошли статические шаблоны, эта проблема не решилась. Потому и приходится такие костыли лепить.
0
Про шаблонизатор соглашусь с вами частично. Есть модификаторы, возможность вызвать сниппет в сниппете (тот же самый php код). Да и в конце концов, если вам так нужно использовать в html CSS, то замените parseChunk на runSnippet и будет вам счастье:-)
Там только сниппет а-ля [[!diz?file=`inc.partnerActions.php`]]таким образом все документы у вас на сайте не кешируемые?
0
html в php
0
Про шаблонизатор соглашусь с вами частично. Есть модификаторы, возможность вызвать сниппет в сниппете (тот же самый php код). Да и в конце концов, если вам так нужно использовать в html CSS, то замените parseChunk на runSnippet и будет вам счастье:-)
Извините, вы думаете за 3,5 года работы с MODx я не научился пользоваться модификаторами? :-)
Дело не в том, что я хочу использовать CSS или еще что-то, а дело в том, что parseChunk и runSnippet в принципе нельзя напрямую использовать в шаблоне (как и в чанке), потому что там только HTML-код. Если у вас проект простой, то конечно можно воткнуть HTML сразу в шаблон и где надо натыкать [[!Wayfinder]] [[*pagetitle]] и т.п. Для меня в моем проекте этого мало, и когда работает так, как я сделал, тогда для разных контекстов мы имеем возможность не просто часть када заменить, или CSS другой подгрузить, а в принципе абсолютно разный код выполнять.
таким образом все документы у вас на сайте не кешируемые?
Полностью документ закешировать все равно нельзя, когда есть авторизация и есть индивидуальная информация для пользователей.
А $modx->cacheManager никто не отменял, так что если что-то вам надо закешировать дальше по ходу, это всегда можно сделать. Плюс к этому кэш Smarty.
0
Не проще ли было создать наборы параметров для этого? А потом плагином делать нечно подобное
$propSet = $modx->getObject('modPropertySet',array('name'=>$city));
$config = $propSet->getProperties();
0
Я понимаю, что в MODX можно сделать можно что угодно и как угодно. Но мой комментарий не случаен. Ведь вы же сами в посте написали
Ни слова о том, что вам нужны различные права, адреса, исполняемые классы и т.д. и т.п. Именно поэтому я и предложил вариант немного проще — предназначеный именно для того, чтобы быстро загрузить некоторые настройки.
а контексты по городам а-ля krasnodar нужны только для того, чтобы перегрузить некоторые настройки (каждый контекст имеем свои настройки типа базовый домен, город, код Я.Метрики и т.п.)
Ни слова о том, что вам нужны различные права, адреса, исполняемые классы и т.д. и т.п. Именно поэтому я и предложил вариант немного проще — предназначеный именно для того, чтобы быстро загрузить некоторые настройки.
0
Всего сразу и не рассказать. Об этом я позже упомянул:
Плюс ко всему я всегда смотрю на перед, и не стану себя ограничивать набором параметров. В дальнейшем совершенно не исключено, что у меня появятся представители в других городах, которым надо будет обеспечить определенные права исключительно по их городам и средствами MODx. Это как один из вариантов.
Нет, конечно же, если кому-то нужно наипростейшее решение локальной задачи для сайта визитки, тому может и подойдет предложенный вами вариант, но я воспринял вопрос человека примерно как «а как у вас это реализовано?», потому и рассказываю как это реализовано у меня. Но буду стоять на своем — я не мало мультидоменных проектов сделал, и лучше этого решения не знаю. Реализуйте что-то лучше и можем обсудить плюсы-минусы.
И еще один очень весомый аргумент: в настройках MODx помимо всего прочего содержатся имена исполняемых классов и т.п., к примеру modRequest и modResponse. Вот в мобильной версии мне необходимо было несколько изменить базовые классы, но редактировать код движка — совсем не круто, по-этому мы создаем свой класс и расширяем базовый.
Плюс ко всему я всегда смотрю на перед, и не стану себя ограничивать набором параметров. В дальнейшем совершенно не исключено, что у меня появятся представители в других городах, которым надо будет обеспечить определенные права исключительно по их городам и средствами MODx. Это как один из вариантов.
Нет, конечно же, если кому-то нужно наипростейшее решение локальной задачи для сайта визитки, тому может и подойдет предложенный вами вариант, но я воспринял вопрос человека примерно как «а как у вас это реализовано?», потому и рассказываю как это реализовано у меня. Но буду стоять на своем — я не мало мультидоменных проектов сделал, и лучше этого решения не знаю. Реализуйте что-то лучше и можем обсудить плюсы-минусы.
0
Sign up to leave a comment.
Articles
Change theme settings
Работа с поддоменами в MODx