Интерресный заказик (3)

На оф. сайте сообщества modx (http://modxcms.com/forums) задал вопрос по поводу использования modx api во внешнем php-файле. Оказалось, что имеются кардинальные различия в вызове api в EVO и REVO. В MODx Revolution подключение API осуществляется так:



define('MODX_CORE_PATH', 'full/path/to/your/modx/core/');
define('MODX_CONFIG_KEY', 'config');
require_once MODX_CORE_PATH . 'model/modx/modx.class.php';
$modx= new modX();
$modx->initialize('mgr');

Интерресный заказик (2)

Итак, касательно парсера: все оказалось достаточно просто. В качестве инструмента решил использовать SimpleXML. Учитывая то, что не будучи с ним знаком вообще, разобрался с его использованием за пол-дня - он полностью оправдывает свое название:

<?
$doc="http://example.com/catalog.xml";
$res=simplexml_load_file($doc);
?>


Таким образом получаем массив $nodes, содержащий все корневые элементы каталога. Последующий доступ к ним до неприличия прост:


//доступ к 1-му элементу каталога (тэг class), и получение значения аттрибута 'name' его первого дочернего элемента (тэг art):
echo $res->class[0]->art[0]->attributes()->name;


То есть можно получить доступ к элементу любого уровня или его аттрибуту. Вывод осуществляется в формате SimpleXML, в конечном итоге представляющем формат String. Для указания надценки придется преобразовывать String в Double, а затем обратно в String для сохранения значения в TV MODx на конечной стадии работы парсера. Но - глаза боятся, руки делают!)) Итак - осталось сформировать цикл для прохода по всем позициям каталога. Единственный момент... Придется учесть такой момент, что практически невозможно отследить удаленные позиции каталога. Так что придется придерживаться следующего алгоритма:

1. Полное удаление каталога (скрипт)
2. Сброс счетчика (скрипт)
3. Обработка каталога (скрипт)
4. Сортировка пунктов (вручную? - пока да...)

Различия в синтаксисе внутренних тэгов EVO и REVO

Сегодня попробовал использовать новую версию MODx - Revolution. Устанавливаю на DENWER. Все идет как по маслу - без сучка и задоринки. Верстаю шаблон. Вставляю привычные для себя тэги [*pagetitle*], [(site_url)]... И вот тут-то и попался! Не работают. Давай проверять, - не работают, и все тут. Начинаю искать информацию на оф. сайте. И вот тут-то и выплывают "расписные":

Content Elements	Evolution (Old)	Revolution (New)
Templates	no tag representation	no tag representation
Template Variables	[*templatevar*]	[[*templatevar]]
Chunks	{{chunk }}	[[$chunk]]
Snippets	[[snippet]]	[[snippet]]
Plugins	no tag representation	no tag representation
Modules	no tag representation	does not exist in Revolution
Content Tags
Placeholders	[+placeholder+]	[[+placeholder]]
Links	[~link~]	[[~link]]
System Settings	[(system_setting)]	[[++system_setting]]
Language	no tag representation	[[%language_string_key]]

Оригинал - здесь.

Так что подстроился, и все заработало. Теперь вопрос в том, что нужно найти Shopkeeper для REVO... Ушел искать))

Интерресный заказик

Поступил заказ на создание сайта на основе каталога поставщиков, предоставленного  в формате XML, на платформе MODx. Очень интересная тема. Хочу задействовать движок ShopKeeper. Единственная загвоздка на данный момент - с XML я на "вы". Точнее как - разобрать, что и где лежит я-то смогу, но обработать эти данные программно... Нужен XML-парсер. Пока присматриваюсь к XPath. Чем дальше, тем интереснее - в MODx обнаружил функционал для... FLASH CMS!!! MODx - золотая находка - воистину мощная платформа для сайтов любой сложности... Если так, то может быть станет возможным интернет-магазин, реализованный во Flash ?! Мечты, мечты...))). Структура XML-файла очень грамотная. Теперь осталось отпарсить ее. Если все получится, можно будет поделиться реализацией и платформой с поставщиком)). Принимаюсь за работу.

Валидность и стили в кроссбраузерном коде

Ну вот выдалась свободная минутка, решил сделать про запас несколько заметок по части веб-верстки. На данный момент в Интернете наиболее распространены 4 движка: Gecko (FireFox, SeaMonkey), Internet Explorer (Internet Explorer, Maxthon), WebKit (Google Chrome, Safari) и NetScape (NetScape Navigator, Opera). Все они по разному реагируют на таблицы стилей. Увы, Internet Explorer бьет все рекорды по некорректному отображению страниц, если быть точным, то по отображению не того, что задумывал веб-верстальщик. В связи с этим появились CSS "хаки" - куски кода, которые встраиваются либо в код, либо непосредственно в файл CSS, и все бы хорошо, если бы не... валидность. С одной стороны можно просто наплевать на нее, но, справедливости ради скажу, что валидность кода радует глаз не только заказчику, но и мне, как человеку, сдающему работу, кроме того валидность дает относительные гарантии по поводу отображения кода в разных браузерах. Выход для себя я нашел достаточно простой - php-сниппет, определяющий тип браузера, и подключающий нужный стиль в зависимости от движка:

<?

$browser=$_SERVER['HTTP_USER_AGENT'];
if(ereg('MSIE',$browser)){
    echo "/link href="[(site_url)]styles/styles_ie.css" media="all" rel="stylesheet" type="text/css"/\r\n";
}else{
    echo "/link href="[(site_url)]styles/styles.css" media="all" rel="stylesheet" type="text/css"/\r\n";
}

?>


Сниппет заточен для использования в среде MODx, и является более иллюстрацией, чем материалом для копи-паста. Итак, немного разберемся в коде: сначала получаем значение суперглобального массива $_SERVER, и значение его параметра HTTP_USER_AGENT  в частности, в котором хранится тип браузера. Далее - идет проверка на наличие в этом значении слова MSIE (MicroSoft Internet Explorer). Далее все просто - если есть, - вставляем линк на стиль styles_ie.css, если нет - соответственно. Во внутреннем тэге MODx [(site_url)] хранится корневой URL сайта (к примеру - http://example.com), и к нему приставляется остальная часть пути к CSS-файлу, в итоге получаем строку:

Для IE

<link href="http://example.com/styles/styles_ie.css" media="all" rel="stylesheet" type="text/css" />

Для других браузеров:

<link href="http://example.com/styles/styles.css" media="all" rel="stylesheet" type="text/css" />

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