LINUX.ORG.RU

XML как контейнер мета-разметки

 , , , ,


0

1

Уткнулся я тут в генерацию разнокалиберного HTML из своего расширенного BB-code (в первую очередь — генерация контента под очень разную ширину блоков) и пришла в голову мысль.

Сейчас транслятор разметки проводит очень много вспомогательных операций. Ну, например, брошенная отдельной строкой ссылка вытягивает с указанной страницы заголовок, описание, og:image, если последнего нет — генерит превью страницы, а потом в таком видел лепит в HTML. Например, так:

http://www.balancer.ru/img/forums/1302/lcml-sample-150301.png

В исходном тексте сообщения это только две строчки со ссылками.

При генерации под разные условия возникает проблема повторного использования тяжёлых операций. Когда один раз — не страшно. Сгенерировали (всё руки не доходят вообще на gearman перекинуть тяжёлые операции, реализовал пока на уровне теста концепции превью ссылок на PDF, но ещё работать и работать) один раз, сохранили скомпилированный вариант — и отлично, больше систему оно не грузит.

В случае нескольких разных вариантов трансляции с этим всё плохо. Ну, закешировать можно и несколько разных вариантов. Но для каждого придётся повторно выполнять тяжёлую трансляцию.

Естественно, в голову приходит вариант «тяжёлой» трансляции в промежуточный код. Сперва думал о расширенном bb-коде, в котором уже будет всё нужное. Ну, типа из

http://lenta.ru/news/2012/12/21/will/
http://lenta.ru/news/2012/12/21/mistral1/
сгенерировать
[url=http://lenta.ru/news/2012/12/21/will/]
[img float-left]http://www.balancer.ru/cache/sites/i/m/img.lenta.ru/news/2012/12/21/will/200x200/picture.jpg[/img]
[b]Lenta.ru: Оружие: ОСК опровергла отказ Минобороны от строительства "Мистралей"[/b]
[/url][br]
ОСК не получала от Министерства обороны России уведомления об отказе от планов строительства в России двух вертолетоносцев типа Мистраль. Об этом заявил пресс-секретарь ОСК Алексей Кравченко. Ранее газета Ведомости написала, что Минобороны отказалось от опциона на постройку третьего и четвертого Мистралей.
// [url=http://lenta.ru/news/2012/12/21/will/]lenta.ru[/url]

…

Вроде, всё извлечённое уже есть, потом только сгенерировать по-быстрому HTML… Но как-то оно неправильно показалось тащить в мета-разметку, которая более представляется логической сразу визуальное представление.

Тогда, следующий логичный шаг — переход к XML:

<site-link>
<url>http://lenta.ru/news/2012/12/21/will/</url>
<image>http://img.lenta.ru/news/2012/12/21/will/picture.jpg</image>
<title>Lenta.ru: Оружие: ОСК опровергла отказ Минобороны от строительства "Мистралей"</title>
<description>ОСК не получала от Министерства обороны России уведомления об отказе от планов строительства в России двух вертолетоносцев типа Мистраль. Об этом заявил пресс-секретарь ОСК Алексей Кравченко. Ранее газета Ведомости написала, что Минобороны отказалось от опциона на постройку третьего и четвертого Мистралей.</description>
</site-link>

<site-link>
...
</site-link>

Получается и разметка логическая, и однозначно транслируемые элементы (типа <strong>...<em>...) можно сразу отранслированными хранить, и трансляцию можно проводить общесистемными средствами уже, не велосипедить, да и даже компактнее в хранении, порой. Ну и формат вывода гибко менять можно.

Вроде, одни плюсы со всех сторон.

Но тут и третья сразу мысль — а никто такого ранее не делал в готовом виде? Вроде, настолько очевидное решение, что в голову приходит — а не занялся ли я велосипедостроением?

Кто что скажет?

★★★★★

у ленты ж есть rss тиеперь и с картинками

visual ★★★ ()

Не понял в чем тут соль. Ну да, ты вытягиваешь там что-то, парсишь и внезапно решаешь хранить это в обработанном виде. Ну да, так вроде и делают люди.

Я вот храню в БД такие результаты (только данных у меня поболее и связаны они хитро, но не суть), после чего вывожу это в удобный html.

Ну у тебя тут вместо базы данных xml-файлы? Можно было бы с таким же успехом какой-нибудь yaml или json использовать, разве нет?

anonymous ()
Ответ на: комментарий от visual

При чём тут Лента? o_O Текст вообще не касается проблемы работы с каким-то конкретным сайтом.

Пусть будет так:
http://www.balancer.ru/img/forums/1302/lcml-sample-150327.png

тоже из двух ссылок. Одна разворачивается в генерируемое превью сайта, другая — в код YouTube-плеера.

Или http://www.balancer.ru/img/forums/1302/lcml-sample-150329.png из ссылки на mp3.

Ссылки на большую картинку надо заменить на превью со ссылкой на полноразмер. Ссылки на PDF или DjVu — на их превью, мета-информацию и т.п.

В общем, много есть тяжёлых операций, которые полезно проделать только один раз.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

про ленту - это к слову.

а что касаецца всего, что ты написал, выглядит как минимум правдоподобно, но хлопотно. скорее всего придётся делать конвеер - но так будет легче, если придётся добавлять форматы.

visual ★★★ ()
Ответ на: комментарий от visual

скорее всего придётся делать конвеер

Там, вообще, несколько этапов планирую:
1. Предварительный парсинг (выправление типографики, например) с опциональной возможностью показать юзеру промежуточный вариант.
2. Генерация «быстрого» когда (когда все ссылки, скажем, тупо являются выделенными ссылками), чтобы сразу вернуть результат юзеру.
3. Если требуется сложное преобразование к в примерах выше, тогда уже запускается трансляция со всеми описанными хитростями. И по её завершению уже у юзера через AJAX обновится отображение на «продвинутое».

Я пункты 2 и 3 начинал отрабатывать ещё на превью ссылок на PDF. Потом было заброшено, скажем, превью ссылок сейчас генерятся в потоке юзера, так что ему приходится ждать 5..10 секунд порой, пока система обработает что нужно.

Но задача усложнилась ещё и генерацией конечного HTML разного формата. Тут и пришла в голову идея мета-формата. Который, заодно, и 2-й/3-й пункты упростит и отчасти позволит автоматизировать.

Так что этапов много, но это не страшно.

Тут вопрос именно в логике метаформата и в том, нет ли на этот счёт каких-то готовых решений. Ну, скажем, стандартного аналога bb-кода, но в области XML :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от visual

про ленту - это к слову.

А, вообще, у меня, в общем случае, ссылки разных источников обрабатывают разные выделенные классы. И они уже если надо и если есть возможность, могут пользоваться внешними IP, не извращаясь с метаданными страниц. Вот, например, вариант с YouTube: https://bitbucket.org/Balancer/bors-ext/src/01288a89a7035f9fd019f60dc09ab623d...

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Ну, скажем, стандартного аналога bb-кода, но в области XML :)

масло маслянное

bb - аналог html

html - подмножество xml (если строго)

так что s/[/</g s/]/>/g и в путь

visual ★★★ ()
Ответ на: комментарий от visual

bb - аналог html

Только на примитивном уровне :)

так что s/[/</g s/]/>/g и в путь

Вопрос не в сложности, вопрос в велосипедизации :)

Итак сейчас понемного приходится переделывать много решений, которые, будь я в курсе аналогов 10..15 лет назад, могли бы выглядеть сегодня современнее. То второй год разгребаю понемногу смешанные M+V, потому что для простых объектов не понимал удобства их разделения, то, собственно, с терминами, вымарывать приходится тонны object/target на современное model или page на view :) Разве что своё «storage» на «backend» менять не спешу, так как мой вариант точнее суть передаёт ;)

Ещё здорово повезло, что я задолго до появления psr-0 реализовал у себя систему именования классов с ним внезапно совместимую :) Так что даже система под composer'ом неожиданно работает без переделок.

KRoN73 ★★★★★ ()

А ещё, блин, в голову не приходит, как обозвать этот промежуточный слой. Нужно же классы работающие с ним обзывать, методы... Xml_meta — как-то сильно банально :)

...

Может, что-то типа Intermeta (Intermediate meta)?
Intermetax? — такого даже в Гугле нет :D

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Вопрос не в сложности, вопрос в велосипедизации :)

Я думаю, что у меня гораздо меньше опыта в таких делах, чтобы однозначно ответить на такой вопрос.

visual ★★★ ()

Продолжаю мысли вслух.

Ещё задача хитрая — сейчас библиотека BB-like разметки большая и старая (корни уходят в события 12-летней давности, а некоторые особенности — в конец 1990-х и qbasic :D).

Переписать всё сразу на новую логику — нереально.

Но есть плюс. Если нет ошибок, то текущий вариант генерирует в итоге валидный XHTML. То есть, нынешний результат можно сохранять как промежуточный слой и выводить его как есть.

А потом начать дорабатывать сложные случаи (те же ссылки), чтобы генерировали не XHTML, а промежуточный XML. Так и переписать всё в более красивый вариант по частям и поэтапно.

Вроде бы, вполне удачно выходит.

KRoN73 ★★★★★ ()

XSLT — это, походу, такой энтерпрайз-brainfuck. Как такой ужас можно было выдумать? o_O

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

XSLT — это, походу, такой энтерпрайз-brainfuck. Как такой ужас можно было выдумать? o_O

Не надо гнать на XSLT, он просто квинтэссенция того, как надо делать не «на отъе...ись», а «на совесть».

r_asian ☆☆☆ ()
Ответ на: комментарий от KRoN73

Да ладно, он своё дело делает. Правда с непривычки он такой… суровый :)

Deleted ()
Ответ на: комментарий от KRoN73

Отличный инструмент для своих целей, ну и потом какая ни какая но функциональщина ;)

bjorn ()
Ответ на: комментарий от r_asian

он просто квинтэссенция того, как надо делать не «на отъе...ись», а «на совесть»

Ну да. Считай, как brainfuck.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

все ить движется в правильную сторону: до необходимости применения xml-я доросли (хотя некоторых ужжжжастно пугает количество угловых скобуёчков, и о да! какой кошмар! - там тэги закрывать надо), а там где xml там все его родные инструменты и технологии под боком - тогда xslt и прочие «x-» вовсе не кажутся такими уж страшными.

dab18 ()
Ответ на: комментарий от dab18

Только причина со следствием немного поменялась :) Это не потому XML выбирается, что «правильный» и потом оцениваются инструменты, а наличие богатого набора стандартных инструментов позволяет терпеть ужасы XML :)

KRoN73 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.