Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
"множество отрытых стандартов"
великолепно :)
великолепно :)
Простите, а причём здесь микроформаты? Статья совершенно не вписывается в концепцию этого блога.
OK. Сейчас вынесу в личный блог
Спасибо. Я бы посоветовал вам переместить его в блог http://www.habrahabr.ru/blog/webdev/
Максим - об этом лучше пообщаться на 6-й PHPConf
Тем более что оба участвуете :-)
Тем более что оба участвуете :-)
Описание функциональности сайта с помощью XSLT - весьма трудоемкая задача. Кроме того, XSL-шаблон слишком зависим от XML-документа с данными, что ограничивает гибкость решений на основе данной технологии.
А разве XSLT предназначен для этого? Это же лишь таблицы стилей. Вся функциональность должна быть вынесена в программный код, а XSLT - это ведь не язык программирования. Иначе опять получается смешение функциональности и визуального представления, от чего мы так пытаемся избавиться.
Это не вся правда о XSLT =)
Вы же не ратуете за избавление от javascript в пользу серверного решения?
XSLT может отрабатывать НА СТОРОНЕ КЛИЕНТА. Например можно делать фильтрацию или сортировку таблиц без обращения к серверу и javascript.
С другой стороны даже при использовании XSLT на стороне сервера он великолепно служит для разделения кода и дизайна. Только нормальный дизайн всёже имеет собственную логику — в каком-то дизайне анонс новости должен показывать первые 200 знаков, а в каком-то ограничиваться на краю слова, где-то дату нужно выводить в английском формате, а где-то словами и вместе со временем. Удобно автоматизировать дизайн имея в своём распоряжении циклы и ветвления...
Такой вариант внесения программных фишек в дизайн давно зарекомендовал себя и используется в том же Smarty или Mason, но XSLT имеет ряд серьёзных преимуществ перед ними — может работать не только в php/perl но и с любым xml, сгенерированным хоть на C++. Опять же сама библиотека (например Sablotron) бинарна, что серьёзно увеличивает производительность движка шаблонов даже на php.
Вы же не ратуете за избавление от javascript в пользу серверного решения?
XSLT может отрабатывать НА СТОРОНЕ КЛИЕНТА. Например можно делать фильтрацию или сортировку таблиц без обращения к серверу и javascript.
С другой стороны даже при использовании XSLT на стороне сервера он великолепно служит для разделения кода и дизайна. Только нормальный дизайн всёже имеет собственную логику — в каком-то дизайне анонс новости должен показывать первые 200 знаков, а в каком-то ограничиваться на краю слова, где-то дату нужно выводить в английском формате, а где-то словами и вместе со временем. Удобно автоматизировать дизайн имея в своём распоряжении циклы и ветвления...
Такой вариант внесения программных фишек в дизайн давно зарекомендовал себя и используется в том же Smarty или Mason, но XSLT имеет ряд серьёзных преимуществ перед ними — может работать не только в php/perl но и с любым xml, сгенерированным хоть на C++. Опять же сама библиотека (например Sablotron) бинарна, что серьёзно увеличивает производительность движка шаблонов даже на php.
PS: XSLT это конечно не язык программирования в чистом виде, но его точно не следует путать с CSS. XSLT это язык преобразований из XML во что угодно от HTML и RSS до TeX и PDF. Главное ведь не возможность слепой конвертации, а управляемая конвертация — один и тот же xml документа может быть преобразован через XSLT как в семантический XHTML так и в жутко запутанный табличный HTML 3.1 — вам решать.
Это все понятно. И, честно говоря, из этой статьи я так и не понял, чем XML Sapiens лучше XSLT. Простая "автоматизация дизайна" выполняется с помощью XSLT, более сложные вещи лучше перекладывать на сервер. Зачем здесь изобретать еще один велосипед, который лишь повторяет уже имеющиеся инструменты? Причем делает это, как мне на первый взгляд показалось, несколько запутанно.
Я полностью согласен с вами: "Схема XML + XSLT мой процесс устраивает больше как минимум из-за большей простоты понимания".
А на счет клиентской стороны... Opera не поддерживает XML+XSLT (или последние версии уже поддерживают?), что значительно ограничивает область применения такого подхода.
Я полностью согласен с вами: "Схема XML + XSLT мой процесс устраивает больше как минимум из-за большей простоты понимания".
А на счет клиентской стороны... Opera не поддерживает XML+XSLT (или последние версии уже поддерживают?), что значительно ограничивает область применения такого подхода.
честно говоря, из этой статьи я так и не понял, чем XML Sapiens лучше XSLT
Тем же, чем фреймворк лучше библиотеки. (так оно и есть)
С моей стороны было некорректно сравнивать подход "XML + XSLT" с XML Sapiens, поскольку это не равнозначные вещи. XML Sapiens позволяет ускорить разработку сайтов за счёт унификации логики и представления, а "XML + XSLT" лишь конечная обработка данных выданных каким-то движком.
Простая "автоматизация дизайна" выполняется с помощью XSLT, более сложные вещи лучше перекладывать на сервер.
Все известные мне примеры выгрузки XSL к клиенту связаны с автоматизацией, а не с www. Врядли кто-то из разработчиков web рискует парсить XSLT на стороне клиента (моя команда в частности делает XSL-преобразование именно на стороне сервера с помощью библиотеки Sablotron)
Зачем здесь изобретать еще один велосипед, который лишь повторяет уже имеющиеся инструменты?
Поверьте, этот фреймворк имеет определённые преимущества перед многими известными, так что он не зря "коптит небо". =)
А на счет клиентской стороны... Opera не поддерживает XML+XSLT (или последние версии уже поддерживают?), что значительно ограничивает область применения такого подхода.
IE поддерживает и этого пока достаточно. =) Но, как я уже сказал, пока мало кто рискует делать столь революционные шаги — отдавать контент в настоящем, семантическом XML (а жаль).
уже поддерживает
язык логической разметки, так сказать. полностью поддерживаю.
Сталкивался с CMS Sapid (бесплатной на основе XML Sapiens). Очень понравилось, но пока схема XML + XSLT мой процесс устраивает больше как минимум из-за большей простоты понимания.
Извините за назойливость, а "движка" который бы генерил XML и ХSL файлы с одинаковым названием (любые) в HTML с возможностью создания кэша, хотя бы на базе того же саблотрона не встречали?
ну дык, Sapid делает. вплоть до полной статической модели сайта.
я его поковырял немного, но было много нареканий на то что Sapid не держит высокий траф..
В статике — держит, а в динамическом режиме нет и это не удивительно — бесплатная версия основывается на файлах а не на sql и потому не годится для больших нагрузок. Там конечно несложно перевести транзакции на базу, но в том числе и благодаря этому решили с ним не связываться — стоимость доработки показалась не очень удобной.
Ну вот. Чего-либо подобного больше не проскакивало?
Я у себя в конторе все верстаю через XML/XSL и очень доволен, но движок в бэкграунде у нас самописный, его не поюзаешь, вот и ищу платформу.
По большому счету можно конечно описать трансформацию и аутпут в PHP но хотелось бы иметь готовую платформу, чтобы не заморачиваться...
Я у себя в конторе все верстаю через XML/XSL и очень доволен, но движок в бэкграунде у нас самописный, его не поюзаешь, вот и ищу платформу.
По большому счету можно конечно описать трансформацию и аутпут в PHP но хотелось бы иметь готовую платформу, чтобы не заморачиваться...
Возможно вам подойдёт наш комплексный подход к автоматизации
1. наши сервлеты/cgi обрабатывают запросы if-modified-since (и прочие заголовки связанные с кешированием) максимально раньше любой другой работы по построению страницы.
2. между веб-сервером и клиентом стоит squid в режиме акселерации, который обсуживает из кеша иногда и до 90% всех запросов.
Эта схема опробована на ~100тыс запросов в сутки.
Если вы ещё не определились в платформе программирования, то присмотритесь к Parser — весьма неплохая альтернатива php
PS разумеется всё это реализуемо лишь при наличии собственного (dedicated/vds) сервера, поскольку мало кто из провайдеров вобще даёт использовать java, parser или ставят кеширующие акселераторы.
1. наши сервлеты/cgi обрабатывают запросы if-modified-since (и прочие заголовки связанные с кешированием) максимально раньше любой другой работы по построению страницы.
2. между веб-сервером и клиентом стоит squid в режиме акселерации, который обсуживает из кеша иногда и до 90% всех запросов.
Эта схема опробована на ~100тыс запросов в сутки.
Если вы ещё не определились в платформе программирования, то присмотритесь к Parser — весьма неплохая альтернатива php
PS разумеется всё это реализуемо лишь при наличии собственного (dedicated/vds) сервера, поскольку мало кто из провайдеров вобще даёт использовать java, parser или ставят кеширующие акселераторы.
Ах, да, там же Sapiens... Вот что значит писать посредь ночи — голова уже туго соображает. =(
Сейчас используем собственную разработку такого плана, но до коммерческого уровня она ещё не доведена (и пока этого нет в планах).
Сейчас используем собственную разработку такого плана, но до коммерческого уровня она ещё не доведена (и пока этого нет в планах).
опечатался. из XML + XSL в HTML
В принципе добавить особо нечего. Здесь упоминался SAPID. Когда мы его делали было огромное желание поделится идеей использования XML Sapiens и некоторыми наработками по решению задач контент менеджмента, а время для достойной реализации не было, что типично для некоммерческих проектов. Тем не менее мы планируем решение всех недоработок SAPID (расширяемость, масштабируемость, производительность,RIA-интерфейсы, API доступное из веб-сервисов) в двух готовящихся к старту линиях SAPID 2.0 (занимается Максим Барышников) и SAPID CMF (занимаюсь я, Дмитрий Шейко). Обе используют процессор XML Sapiens 2.0. Первая ориентированна преимущественно на сайтостроительство и конечных пользователей. Второй ориентирован на развитие, разработку на его базе веб-приложений. Я планирую привезти наработки по обоим проектам на PHPConf в мае в Москву. Если будут желающие – покажу в перерывах.
SAPID 2.0 мне Максим Барышников показывал почти год тому назад, вполне живой надо сказать проект. Но с тех пор ни слуху ни духу. Сейчас попрошу его прокомментировать
Этот зверь пока спит у меня в svn. Версия вполне рабочая, не хватает мелких вещей вроде документации и описания изменений в шаблонизаторе. Дима прав, несколько месяцев по нему я ничего не делал - занят очень. Надо будет все-таки собраться и подшлифовать остатки.
Если вкратце про 2.0, то:
- работает только под php5
- в качестве хранилища данных может использовать MySQL и sqlite. Остальные мне пока были без надобности, но дописать легко.
- Появился демон, написанный опять же на php, который раотает как ftp-сервер. Но через него можно управлять структурой и содержимым сайта. Для клиента это все выглядит как файловые операции (создать/удалить/отредактировать папку/файл).
- появился настраиваемый анализатор логов веб сервера.
- поддержка различных методов кеширования (это в смысле, если установлен memcached, то изобретать велосипед в виде импользования файлового кеша не нужно)
- протестирован и нормально рабоатет в FastCGI (тестировал nginx + (php-fpm или spawn-fcgi от lighthttpd))
- есть возможность настроить шаблонизатор в режим, когда каждый помеченный блок отдается на обработку отдельному fcgi-процессу через отдельный запрос. Это позволяет параллельно обрабатывать части одной и той же страницы или выносить различный функционал на разные хосты. В некоторых случаях имеет глубокий смысл :)
- вся эта красота стала работать быстрее.
Вкратце, вот такие пироги. Кроме, собственно, полностью переписанного кода появились сервисные утилитки в виде того же анализатора логов и ftp-сервера для управления сайтом хоть из консоли...
В общем, не могу сказать, что весь этот функционал можно будет использовать на shared хостинге, скорее наоборот. Но базовый функционал можно спокойно использовать на большинстве среднестатистических php+MySQL хостингов.
Если вкратце про 2.0, то:
- работает только под php5
- в качестве хранилища данных может использовать MySQL и sqlite. Остальные мне пока были без надобности, но дописать легко.
- Появился демон, написанный опять же на php, который раотает как ftp-сервер. Но через него можно управлять структурой и содержимым сайта. Для клиента это все выглядит как файловые операции (создать/удалить/отредактировать папку/файл).
- появился настраиваемый анализатор логов веб сервера.
- поддержка различных методов кеширования (это в смысле, если установлен memcached, то изобретать велосипед в виде импользования файлового кеша не нужно)
- протестирован и нормально рабоатет в FastCGI (тестировал nginx + (php-fpm или spawn-fcgi от lighthttpd))
- есть возможность настроить шаблонизатор в режим, когда каждый помеченный блок отдается на обработку отдельному fcgi-процессу через отдельный запрос. Это позволяет параллельно обрабатывать части одной и той же страницы или выносить различный функционал на разные хосты. В некоторых случаях имеет глубокий смысл :)
- вся эта красота стала работать быстрее.
Вкратце, вот такие пироги. Кроме, собственно, полностью переписанного кода появились сервисные утилитки в виде того же анализатора логов и ftp-сервера для управления сайтом хоть из консоли...
В общем, не могу сказать, что весь этот функционал можно будет использовать на shared хостинге, скорее наоборот. Но базовый функционал можно спокойно использовать на большинстве среднестатистических php+MySQL хостингов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что такое XML Sapiens