Комментарии 21
Оформляйте в source и уберите упоминание о code. Код нечитаем
Вообще метод немного странный. То есть, вместо того, чтобы полностью сменить контекст, мы используем другой контекст чисто как хранилище настроек для поддомена, но без полной его перезагрузки, чтобы формально оставаться в web-контексте?
А чем смена контекста мешала как раз? До чего именно было сложно добраться? (примерчик небольшой юз кейса) Спрашиваю поскольку сам собираюсь делать мультидоменный сайт.
А чем смена контекста мешала как раз? До чего именно было сложно добраться? (примерчик небольшой юз кейса) Спрашиваю поскольку сам собираюсь делать мультидоменный сайт.
Объясню.
Прежде всего давайте обратим внимание на структуру документов. У нас все документы (в данном случае в том числе и документы акций, которые фактически разбиты по городам) все находятся в одном контексте 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. Вот в мобильной версии мне необходимо было несколько изменить базовые классы, но редактировать код движка — совсем не круто, по-этому мы создаем свой класс и расширяем базовый.
Шаг 2. Мобильная версия (пока не доделана) m.pro-cent.ru/. Все тоже самое: документы контекста те же, а выводимая структура, шаблоны и т.п. другие.
Можно по подробнее, как с помощью подмены контекстов вы заменили шаблоны у страниц…
Вопрос хороший…
У меня шаблонизация немного через костыли. Я не храню 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. Даже начиная с более старших версий, когда пошли статические шаблоны, эта проблема не решилась. Потому и приходится такие костыли лепить.
Про шаблонизатор соглашусь с вами частично. Есть модификаторы, возможность вызвать сниппет в сниппете (тот же самый php код). Да и в конце концов, если вам так нужно использовать в html CSS, то замените parseChunk на runSnippet и будет вам счастье:-)
Там только сниппет а-ля [[!diz?file=`inc.partnerActions.php`]]таким образом все документы у вас на сайте не кешируемые?
html в php
Про шаблонизатор соглашусь с вами частично. Есть модификаторы, возможность вызвать сниппет в сниппете (тот же самый php код). Да и в конце концов, если вам так нужно использовать в html CSS, то замените parseChunk на runSnippet и будет вам счастье:-)
Извините, вы думаете за 3,5 года работы с MODx я не научился пользоваться модификаторами? :-)
Дело не в том, что я хочу использовать CSS или еще что-то, а дело в том, что parseChunk и runSnippet в принципе нельзя напрямую использовать в шаблоне (как и в чанке), потому что там только HTML-код. Если у вас проект простой, то конечно можно воткнуть HTML сразу в шаблон и где надо натыкать [[!Wayfinder]] [[*pagetitle]] и т.п. Для меня в моем проекте этого мало, и когда работает так, как я сделал, тогда для разных контекстов мы имеем возможность не просто часть када заменить, или CSS другой подгрузить, а в принципе абсолютно разный код выполнять.
таким образом все документы у вас на сайте не кешируемые?
Полностью документ закешировать все равно нельзя, когда есть авторизация и есть индивидуальная информация для пользователей.
А $modx->cacheManager никто не отменял, так что если что-то вам надо закешировать дальше по ходу, это всегда можно сделать. Плюс к этому кэш Smarty.
Не проще ли было создать наборы параметров для этого? А потом плагином делать нечно подобное
$propSet = $modx->getObject('modPropertySet',array('name'=>$city));
$config = $propSet->getProperties();
Ответил выше. На MODx пишу с версии 0.9.6.3 и никто меня не переубедит, что надо было по другому делать. У меня сейчас 130 контекстов, с разными правами доступов, адресами, исполняемыми классами и т.п. Этого вы не сможете обеспечить только наборами параметров.
Я понимаю, что в MODX можно сделать можно что угодно и как угодно. Но мой комментарий не случаен. Ведь вы же сами в посте написали
Ни слова о том, что вам нужны различные права, адреса, исполняемые классы и т.д. и т.п. Именно поэтому я и предложил вариант немного проще — предназначеный именно для того, чтобы быстро загрузить некоторые настройки.
а контексты по городам а-ля krasnodar нужны только для того, чтобы перегрузить некоторые настройки (каждый контекст имеем свои настройки типа базовый домен, город, код Я.Метрики и т.п.)Ни слова о том, что вам нужны различные права, адреса, исполняемые классы и т.д. и т.п. Именно поэтому я и предложил вариант немного проще — предназначеный именно для того, чтобы быстро загрузить некоторые настройки.
Всего сразу и не рассказать. Об этом я позже упомянул:
Плюс ко всему я всегда смотрю на перед, и не стану себя ограничивать набором параметров. В дальнейшем совершенно не исключено, что у меня появятся представители в других городах, которым надо будет обеспечить определенные права исключительно по их городам и средствами MODx. Это как один из вариантов.
Нет, конечно же, если кому-то нужно наипростейшее решение локальной задачи для сайта визитки, тому может и подойдет предложенный вами вариант, но я воспринял вопрос человека примерно как «а как у вас это реализовано?», потому и рассказываю как это реализовано у меня. Но буду стоять на своем — я не мало мультидоменных проектов сделал, и лучше этого решения не знаю. Реализуйте что-то лучше и можем обсудить плюсы-минусы.
И еще один очень весомый аргумент: в настройках MODx помимо всего прочего содержатся имена исполняемых классов и т.п., к примеру modRequest и modResponse. Вот в мобильной версии мне необходимо было несколько изменить базовые классы, но редактировать код движка — совсем не круто, по-этому мы создаем свой класс и расширяем базовый.
Плюс ко всему я всегда смотрю на перед, и не стану себя ограничивать набором параметров. В дальнейшем совершенно не исключено, что у меня появятся представители в других городах, которым надо будет обеспечить определенные права исключительно по их городам и средствами MODx. Это как один из вариантов.
Нет, конечно же, если кому-то нужно наипростейшее решение локальной задачи для сайта визитки, тому может и подойдет предложенный вами вариант, но я воспринял вопрос человека примерно как «а как у вас это реализовано?», потому и рассказываю как это реализовано у меня. Но буду стоять на своем — я не мало мультидоменных проектов сделал, и лучше этого решения не знаю. Реализуйте что-то лучше и можем обсудить плюсы-минусы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с поддоменами в MODx