Небольшой тизер:

services.alphaworks.ibm.com/manyeyes/view/S7ipIHsOtha6i3-ZJvKJH2-

Визуализация XFN; точка входа — сайт Тантека Челика. Глубина обработки — 5. Подглюкивает, где-то 5% страниц ни в какую не обрабатываются. Пишу сюда, но скоро будет большая статья в моём блоге про подобную обработку.

Заодно ещё обрабатывает rel-tag и hCard (на представленной карте не показывается).

Под капотом — 200 строк XSLT и полсотни на Python.

+ Tidy, libxml2.

haque.nfshost.com/blog

(поддерживается только firefox 1.5+)

Практически все делается на клиенте — на сервере только серверная логика. Какое-либо генерирование xhtml на сервере отсутствует.

Клиентский софт представляет из себя единственную xhtml-страницу, генерирует она сама себя с помощью xslt. На сервере — dsl для серверной логики (интерпретатор написан на хаскеле), называется haque.

Поддерживаются пользователи, администрирование, модерирование комментариев, markdown.

Строк кода: xhtml — 262, скрипт на самописном dsl (haque) — 76.

Основной вопрос — имеется ли в таком бреде смысл?

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

Посмотрите на InPlace CMS, возможно, эта система решит большинство проблем. Всё очень просто (питон-оболочка для xslt), но:

* Есть очень большая разница между «легко сделать» и «сделано, с документацией».
* Самое главное: описаны сценарии использования (use cases). Они объясняют, почему остальные 99.99% CMS не подходят мне (и другим oss-разработчикам) ни капли.
* Тоже полезная штука: шаблоны решения простых задач на xslt.

Не так давно, решил подружиться с XML и XSLT языками. Ранее программировав, мне не приходилось его внедрять (значит изучать), так как он был мне совершенно не нужен.
А сейчас куда не посмотри, везде требуется знание XML(XSLT) и AJAX. Да и для себя хочется изучить эту прекрасную технологию.

Посоветовали мне на ru_xml некоторые книги по XML и XSLT:


Книга «Технология XSLT» уважаемого товарища Валикова А. Эта книга хороша (читается легко на диване, попивая пинаколаду). Автор писал разборчиво и доступно. Многим людям эта книга помогла. Но есть у неё один минус: её трудно найти. Т.к. тираж вышел в недалеком 2002-м и переизданий не было, найти её практически невозможно.

Сам автор, рекомендовал книгу: «По XSLT из современного рекомендую Jeni Tennison.» Валиков А.

 
«XML» Курт Кэгл и Ко. Рекомендовали как книгу для начинающих. К сожалению о ней сказать ничего не могу, т.к. сам не видел отзывов о ней.

 
От топик-автора:
Уважаемые хабрачитатели, т.к. книгу «Технология XSLT» Валикова А. и «XML» Курта Кэгла, я не нашел. Помогите кто чем может (ссылками, адресами, может самими книгами, если не нужны). Посоветуйте тогда другие книги, что бы изучить и понять XML&XSLT технологию. (но желательно книги, т.к. читать книгу с монитора — оч трудно). И если кто подскажет хорошую книгу по AJAX, буду весьма признателен.

Благодарю за внимание.

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

Так случилось с XML. Ведь XML — это, в общем-то, ничего нового. XML — это упрощённое подмножество языка SGML, который берет свое начало еще в GML 1960 года выпуска компании IBM. XML, по сути, просто стандартизировал формат обмена информацией и все.

Но случилось чудо, мы получили XML и появился объект для рекламы и производители начали на каждом углу заявлять, что у них уже и базы данных с XML и вообще все пропитано XML.

Собственно, на многих сайтах так или иначе бывает полезно воткнуть сведения о том, какая нынче погода в том или ином месте нашей планеты. Поскольку содержать свою собственную метеослужбу большинству людей по меньшей мере накладно, куда логичнее воспользоваться каким-нибудь из ресурсов, предоставляющих бесплатные погодные информеры на достаточно мягких основаниях (всего лишь надо поставить ссылку на их сайт). Один из самых известных и популярных сервисов — это gismeteo.ru. Но его стандартные информеры подойдут далеко не каждому… а что, если захочется переделать дизайн информера под фирменный стиль компании, или же охватить одним информером сразу несколько городов (по умолчанию там на один информер — один город)? Вот, например, недавний заказчик, туристическая компания, захотела информер со списком мест, в которых они работают. Вот такой (скриншот конечного результата):



Думаете, так сделать нельзя? Ещё как можно, и, более того, я уже облегчила вам работу, сегодня за вечерок написав специальный сниппет для MODx с парой демо-шаблонов!

Здравствуй, Хабр. Некоторое время назад мы внедрили у себя в CMS наряду с уже имевшимся к тому моменту собственным шаблонизатором, еще и XSLT. Поскольку есть в XSLT большие и реальные преимущества и для разработчиков, и для хозяев студий, и даже для владельцев сайтов. Но реакция наших партнеров разделилась на противоположные мнения: одни давно ожидали этого и были рады появлению такой возможности, другие поставили под сомнение востребованность XSLT, приводя в качестве аргумента низкую производительность, которую якобы влечет за собой использование XSLT.
Понятно, что у всего нового всегда есть сторонники и противники, и рассудит их время. Поэтому не было особого смысла развязывать религиозную войну XSLT vs tpl или Smarty на тот момент. Но мы обнаружили, что оказывается, один из лидеров российского рынка CMS с завидным упорством все пишет и пишет о якобы несостоятельности XSLT как массовой технологии и готов рассматривать ее только в контексте специфичных задач. А это негативно влияет на умы некоторых непосвященных разработчиков об XSLT.

В сети доступно масса документации по языку XSL. Данный раздел не претендует на роль документации по языку, а лишь кратко, по шагам объясняет, как создать свой XSLT-шаблон.

Описанная ниже схема успешно мною используется уже более 3 лет. По началу я к XSLT относился с большой опаской (особенно, когда разбирал чужие исходники), однако однажды поняв, что к чему, уже не представляю, как без него можно работать.

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

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

…тем временем вышла в свет новая версия CMS Energine 2.2. Функциональных улучшений не много, но всё, что было раньше, теперь работает намного лучше :)

Я приверженец xml. Мне очень нравится подход к проектированию вэб-приложений при котором бизнесс-логика отделена от представления посредствам xml/xslt. Я не сторонник изобретения велосипедов (шаблонизаторов типа Smarty), и вообще, прикручивания рогов и педалей к лопате.

На днях задался целью выяснить каких успехов достигли разработчики браузеров на ниве client side xslt-преобразования. Потому как выполнять преобразование на сервере не интересно — жрутся рессурсы, расходуется канал (что особо важно для пользователей слабеньких каналов и мощных компьютеров). Да и вообще, преобразование на стороне клиента на мой взгляд просто правильнее. Задача отображения документа — есть задача браузера. Вот пусть он этим и занимается.

ывапывапыва

Наверное, многие, начинающие изучать XSLT, сталкивались с проблемой — textarea в режиме вывода XML выводится как одиночный закрытый тэг:
<textarea name="text" id="text"/>
, а не как пара тэгов с нулевым ребенком:
<textarea name="text" id="text"></textarea>

В процессе изучения Zend Framework, Php, Javascript, Xslt появилась идея закрепить все на практике, написав учебный проект. Все началось со змейки, которая бегала по полю кушала «яблоки» и разбивалась об себя или об границы экрана. Ну, в общем, стандартная игрушка под старые nokia. Только не двухцветная, а трёх=)
Появились сначала уровни, потом обработка на стороне сервера с помощью Zend. Позже уже появился дизайн, взятый с www.freecsstemplates.org (так, как с дизайном у меня туго=) ). И так все постепенно переросло в теперешний проект — с редактором карт, регистрацией, квестом и т.д.

Для начала появилась потребность в шаблоне, что реализовал с помощью Xslt. После этого добавил права пользователей с помощью Zend_Acl и авторизацию с помощью Zend_Auth. Ввел регистрацию, для того, что бы добавлять новых пользователей. В этом случае мне понадобились Zend_Mail и Zend_Validate.
Реализовал контроллеры отдельные для квеста, случайной карты и определенной. Движки — на чистом Javascript. Для квеста — один движок. Для случайной и определенной карты — тот же самый плюс сохранение движения с помощью XmlHttpRequest.
Редактор так же на чистом Javascript. Сохранение происходит с помощью XmlHttpRequest. Проверка карты на корректность — на стороне сервера(проверяется можно ли с любой точки попасть в любую и существует ли точка, с которой нельзя выбраться).
В качестве базы данных использовал SQLite, так как не было потребности в каких-то других. Настраивается легко и быстро на персональном компьютере. Но в случае больших нагрузок можно легко изменить на любую другую без проблем, так как использую PDO.

В принципе, о проекте — все. Выкладываю не для того что бы показать, что я крут, а что бы посмотрели, высказали свои мнение и пожелания, желательно указали баги, которые я исправлю. Хочу получить опыт в «поддержке» проекта.

P.s. Проект — Open Source. Кому интересны исходники — обращайтесь. code.google.com/p/zendsnake/downloads/list

Сам проэкт — www.snake4ever.org.ua

UPD. Проект окончен. Но исходники можно до сих пор скачать.

Примечание: ниже перевод обзорной статьи «JSON vs XML», посвященной JSON и его сравнению с XML по ряду критериев. Публикуется в целях популяризации JSON среди читателей Хабрахабра.

JSON (англ. JavaScript Object Notation) — формат обмена данными, легко читаем людьми, легко обрабатывается и генерируется программами.

Основан на подмножестве языка JavaScript, Standard ECMA-262 3rd Edition — декабрь 1999.

JSON — Википедия

Что является правильным форматом ответа на XMLHttpRequest в AJAX-приложениях? Для большинства приложений, основанных на разметке, ответ будет простым — (X)HTML. Для информационно-ориентированных приложений выбор будет лежать между XML и JSON. До недавнего времени я не сильно задавался вопросом, что лучше использовать, XML или JSON. Я просто предполагал, что в каждом конкретном случае стоит выбирать наиболее подходящий формат, и все. Но недавно мне довелось проверить на практике этот подход. В этой заметке я опишу критерии, по которым проводил сравнение между XML и JSON, и собственные умозаключения.

Итак, критерии следующие.

• Удобочитаемость кода.
• Простота создания объекта данных на стороне сервера.
• Простота обработки данных на стороне клиента.
• Простота расширения.
• Отладка и исправление ошибок.
• Безопасность.

Микроформаты — это способ внедрения специфических семантических данных в HTML, который мы используем сегодня. Первый вопрос, который задал бы гуру XML: «А зачем применять HTML, если XML позволяет создать ту же самую семантику?» Я не буду перечислять все причины, по которым XML был бы лучшим или худшим выбором для кодирования данных, или же почему микроформатами был выбран HTML в качестве базы. Эта статья будет сосредоточена на том, как работают базовые правила парсинга, и как они отличаются от XML-ных.

 

Пролог

Две недели назад на хабре анонсировали онлайн-проигрыватель GuitarPro-табов.
К этому времени моя реализация с возможностью загружать свои табы и открытыми исходниками была почти готова к тому, чтобы ее было не очень стыдно показывать.

Думаю, для многих не секрет, что xml является достаточно удобным способом хранения и передачи информации. Вот уже который раз натыкаюсь в литературе на утверждение, что в будущем xml должен заменить html, а появление xhtml является тому подтверждением. Но тут есть нюанс. все браузеры знают как отображать html-документы, но ни один из них не знает, как должны отображаться xml-документы. Это связано прежде всего с тем, что формируя xml-документ Вы можете ввести свои теги. Я хочу коротко (это очень большая тема, на самом деле) рассказать о так называемых «Таблицах преобразований xml-документов».
Думаю, что многие наверняка знакомы с ними, но надеюсь что кому-то это может быть полезно, а, учитывая мою любовь к практике, хочу показать всё на очень простом примере