Применение шаблонов в случае XML\XSLT для "больших" порталов и не только

[eurolinedev]

Применение шаблонов в случае XML\XSLT для "больших" порталов

Здравствуйте!
Этот пост является желанием подвести итог 21 страничной теме (http://phpclub.ru/talk/showthread.php?threadid=82489&rand=1 ) и сформировать некое мнение (которому придерживаться ещё некоторое время в будущем) относительно использования шаблонов в PHP.

Собственно, как я понял, все ранее существующие технологии шаблоных движков являются морально устаревшими и теперь следует использовать XML\XSLT

Господа, объясните технологию построения !!!

Т.е.
1. вся логика парсинга теперь находится в xslt а не вскриптах?
2. никак не могу понять, как в HTML-визуальных редакторах админок править дизайн(шаблоны) сайта... теперь просто обычный менеджер, следящий за контентом сайта своей фирмы должен знать XML|XSLT etc?
3. DAN, просветите пожалуйста (как я понял из того поста), Вы именно так и делаете... как Вы это делаете...
4. Ну... а для XML-based сайтов, есть какие-либо движки шаблонов...

Вобщем, что-то запутался я, народ, помогите...

 

[inTox]

Собственно, как я понял, все ранее существующие технологии шаблоных движков являются морально устаревшими и теперь следует использовать XML\XSLT

Вы неправильно поняли.

Господа, объясните технологию построения !!!

построения XSLT-шаблона?
Почитайте книжку Валикова "Технология XSLT" или "XSLT" Холзнера.
Опять же напоминаю, что XSLT - это не серебрянная пуля, а "language for transforming XML documents into other XML documents". Всего навсего.

 

[eurolinedev]

inTox, спасибо, что откликнулись!
XML знаю, XSLT тоже вроди как (за ненадобностью редко использую... вот может Вы меня и переубедите... точнее укажите на мои заблуждения)

Под Технологией построения имеется ввиду, технология построения самого сайта, самой структуры и ролей каждой компоненты(HTML, PHP, DB eetc)... примерно следующее:

Как было раньше: например имеется многоязычный портал(-чик. Образно говоря, состоит из
- шаблонов для каждого языка - статический HTML с перемеными, в которые вставляется некий результат скриптов, при парсинге конкретного шаблона. Шаблонный движок, например, IT(ITX) / Smarty и т.д.

- скриптов, результат работы которых, парсится в вышеназванные шаблоны

- ну и прочего суппортящего (там БД и т.д.)

в этом случае, например, есть простая админка с ВИЗИВИГ редактором (ну, для определённости, тот же FCKEditor), посредством которого, изменённая часть контента/дизигна, вносится в шаблон/БД и т.д.

Как есть теперь (так как я себе это представил)

- шаблонов нет! есть некий Model-View, коим является стиль xslt и
xml - как базовый мета-шаблон что-ли...

- для получения выходного HTML, xslt преобразовывает xml-ный шаблон и отдаёт браузеру...

- скрипты, теперь, только выдают данные/запускают процесс парсинга xml-я xslt-шными правилами

- юзер в админке, для изменения дизайна/контента вначале правит сам XML-шаблон, затем правилапреобразования XSLT - стиля


Что теперь, в случае XML/XSLT based сайтов понимается под шаблоном
как теперь выглядет технология генерирования выходного html/xhtml
Что же всё-таки редактирует пользователь в ВИЗИВИГ-эдиторе

-~{}~ 18.04.06 13:21:

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

1. не понятно что отвечать (укажите, что именно разъяснить более лучше, пологаю, что общего описания впринципе достаточно)

2. не хоятят утруждаться писаниной (тогда киньте плиз линки на сабж... на сабж, а не на референсы по языку, xml etc)

3. Не знают что ответить (т.е. мало кто смотрит в сторону XML?)

Ну, вобщем, если кому есть что сказать... жду комментариев

 

[glider]

Позволю себе ответить, надеюсь, правильно понял, в чем вопрос

Imho, вариантов три.
1. Если структура известна - определить набор тэгов или описать тэги своего пространства имен, висивиг-редактор настроить на их использование. Всё, что выходит за рамки определенных правил - в игнор/plaintext.
2. Если требуется редактирование контента с произвольной html-разметкой, юзер в админке может править только содержимое будущих CDATA-секций, которое "as is" выплевывается в результирующий HTML после XSL-трасформации.
3. Давать юзеру формировать структурированные данные из заранее определенного набора атомарных текстовых/числовых/etc элементов, из которых потом собирать XML-документ.

Если же есть необходимость менять структуру данных и шаблоны для их трансформации, то это уже не работа юзера, управляющего контентом, как мне кажется.

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

 

[dub]

Re: Применение шаблонов в случае XML\XSLT для "больших" порталов

Поскольку как я понял. Автору интересно любое мнение, попробую высказать свое... Скажем так, xml/xsl - начал использвовать где-то месяца 4 назад.
Причины:
1) это ОЧЕНЬ удобно. по крайней мере просмотреть несколько файлов потокового кода(где дизайн смешан с бизнес логикой) мне намного тяжелее. + я работаю с графикой которую создал дизайнер, создаю xsl шаблон для отображения одновременно с тем как контенщик работает с содержимым xml. на счет вузивуга я тут спрашивал: http://phpclub.ru/talk/showthread.php?s=&threadid=83654&rand=7.
2) Иногда ложылась база. а таким образом все можно более прозрачно кешировать. (в смысле + работы с файловой системой, хотя это и минус)
3) Можно создавать разные форматы на выходе. (я создавал html, xhtml, pdf)
4) Улучшается качество html - кода.
С другой стороны :
1) Под php 4 достаточно мало удобных средств для работы с xml, а его, почему то, еще больше чем 5.
2) Более медленная работа.
3) как то досих пор не разобрался что делать с большим количеством динамических данных. формировать xml и использовать его в преобразовании, или вызывать пхп функции в самом преобразовании.
4) Не могу понять как нормально наладить связь MySql-XML-XSL.

 

[eurolinedev]

glider, сенкс за ответы, скажи плиз такое:
в случае использования XML сайтов (применительно к шаблонным "технологиям" http://phpclub.ru/talk/showthread.php?threadid=82489&rand=1), отсутствует такое понятие как ШАБЛОН, какой мы понимали ранее (разные там ITX, Smarty и т.д.) ?
Т.е. теперь, для того чтобы отдать готовую HTML страницу, мы в начале не парсим никакие HTML-шаблоны, а генерим вывод исключительно постредством xslt ?

 

[inTox]

eurolinedev
Почитайте-ка и правда стандарты консорциума, касающиеся XML\XSLT\XPath. Дело в том, что логика преобразования XML отличается от шаблонной логики тем, что Вам придется научиться думать деревьями, узлами и контекстами. В простых случаях, с которыми человек сталкивается в первые месяцы изучения xslt он этого попросту не видит и не понимает этой специфики. А что касается организации "xml/xslt based" в данном аспекте, то она сводится к построению xml-документа тем или иным способом, который зависит от конкретной задачи. То есть нет никакого "теперь" и "раньше".

А по поводу разделения данных и представления обязательно почитайте Тимоти Лири, его рассуждения что это вообще сомнительно. Еще советую потратить время на флейм:
http://phpclub.ru/talk/showthread.php?s=&threadid=64789&perpage=20&pagenumber=1
http://phpclub.ru/talk/showthread.php?s=&threadid=57049&perpage=20&pagenumber=1

 

[eurolinedev]

inTox, благодарю за http://phpclub.ru/talk/showthread.php?s=&threadid=64789&perpage=20&pagenumber=1

непонятна мне была сама организация структуры.
Стандарты В3С читал, но поскольку не видел ещё ни одного сайта "на XML", возникали эти вопросы.

Вобщем, если есть что кому добавить интерсное, буду рад (и пологаю, многие другие тоже)

 

[Alexandre]

Собственно, как я понял, все ранее существующие технологии шаблоных движков являются морально устаревшими и теперь следует использовать XML\XSLT

нет ты не прав, просто технология XML\XSLT одна из разновидностей шаблонных технологий, она имеет свои преимущества и недостатки

 

[eurolinedev]

Народ, спасибо за наставления, ещё пара вопросов:
1. а скажите, есть ли смысл связывать шаблонизаторы и XML-based сайты...
Имеется ли смысл шаблонизировать xslt/xml (что-то типа как препроцессора)?
и если да, то в каких случаях...

Т.е. если выбрали за используемую технологию xml\xsl , то шаблонизаторы применять не следует?

2. всё-таки, не совсем понятна специфика работы контент-менеджера с визивиг-редактором... последний редактирует только информационную составляющую (непосредственно сам текст?);
Как тогда будут выглядеть его действия по форматированию лейаута и идизайна, например, нужно добавить на страничку некоторую часть оформления (например, какие-то таблицы, другие экзотические вещи и т.д.)

p.s.
как я уже говорил, я просто не видел сырцы подобных CMS (или просто сайтов), подскажите названия подобных или где можно скачать...

Спасибо

 

[Alexandre]

есть ли смысл связывать шаблонизаторы и XML-based сайты...

на твое усмотрения, на мое - есть
надо пользоваться правилом (Правило 1): максимально использовать то - что ты хорошо знаешь,
(Правило 23 )не следует использовать какую-то технологию, ради технологии.

не совсем понятна специфика работы контент-менеджера с визивиг-ред

вайзивиг - редактирует на стороне клиента (браузера) - потом все отправляется на сервер. Как все устроенно на сервере - это уже твое личное дело. (XML-based сайты или мускульные или CSV)
см правило 1

 

[dub]

eurolinedev
2)
Да собственно что мешает контент-менеджеру. знающему html менять шаблон xslt, особенно если сделать его читаемым. мол
<!--центральная часть сюда вставляем табличку-->. Да и вобще, xsl - это подвид xml по сути. По чему бы, не дать контент менеджеру средства(интерфейс) для редактирования определенных нод. Плюс можно в этом же интерфейсе предусмотреть некоторые стандартные действия, описать корорые можно xsl, но контенщику не нада будет особо туда вникать, просто кнопочки нажимать к примеру. Интересно,
1 а есть ли уже вузивуги работающие подобным образом?
2 если не сложно, может, кто-то кинуть пару ссылочек на крупные проекты работающие на xml/xsl?

 

[eurolinedev]

Автор оригинала: dub
eurolinedev
2)
Да собственно что мешает контент-менеджеру. знающему html...

Знание этого HTML и что там ещё...
Фактически ВСЕ менеджеры больны Синдромом Вёрда (с) Не помню кто с этого сайта и всем нужна ВИЗИВИГность чего-то типа того-же FCKEditor...

На xpoint есть статья "Пишем правильный ВИЗИВИГ-редактор", но тот-же самый случай...

Господа, объясните в 2-х словах, что из себя должен представлять ВИЗИВИГ-редактор (его ф-ции, процедура работы с ним пользователя) способы, которыми можно изменять сам дизайн страницы без редактирования xml/xsl ...

1 а есть ли уже вузивуги работающие подобным образом?
2 если не сложно, может, кто-то кинуть пару ссылочек на крупные проекты работающие на xml/xsl?

Именно, поддерживаю 2-я руками, и господа, а чем это не тема для FAQ или отдельного номера PHPInside?

-~{}~ 19.04.06 13:46:

Автор оригинала: Alexandre
(Правило 23 )не следует использовать какую-то технологию, ради технологии.

Золотые слова... ах где Вы билы года 3-4 назад, когда я бросил Java и перебежал на .NET Framework

... Как все устроенно на сервере - это уже твое личное дело.

так вот что должно быть на сервере?
т.е. по каким алгоритмам/соображениям мы из полученного от пользователя каши, вытаскивам и обновляем шаблоны/базы... по какому "принципу" производим изменения...

Допустим, наш Визивиг показывает распарсенный ХТМЛ клиенту, который последний редактирует... затем, при сабмите изменений, едитор отдаёт сайту валидный xhtml, затем, с этим потоком начинаем извращаться, на тему определения, какая нода есть элемент дизигна, а какая - собственно текст... потом обновляем (как-то) xml, xsl, ccs и т.д.

Мне не понятна сама специфика и система работы пользователя с ВИЗИВИГом в случай xml-based...

 

[slach]

=) IMHO редактировать в WYSIWYG именно ПОЛНОСТЬЮ документ...
гибельный путь
тебе тут сказали вполне приемлимые решения

1) все что может быть СТРУКТУРИРОВАНО редактируется обычной ВЕБ формой на сервер кладется POST'ом и на сервере хранится в SQL или если позволяет сервер базы данных в XML

2) все что НЕ МОЖЕТ быть структурировано как то "куски текста" типа "текст статьи" и т.п. редактируется стандартным уже MSHTML SDK\Midas\Opera9+ инструментарием и потом кладется в CDATA и выводится как disable-output-escaping...

если уж так интересуешься то смотри в сторону
http://www.bitflux.ch/
там есть Editor и даже CMS
и все это с использованием XSLT делается

 

[eurolinedev]

Посмотрел http://www.bitflux.ch/ - неплохо, спасибо.
Однако, их редактор только под Фаерфокс... у меня не хватает времени вникнуть в его АПИ, что бы понять - используются ли там какие-то специфические фичи только для ФФ (ну мидас само-собой), которые нельзя продублировать в ИЕ, или разработчикам было просто лень портировать в ИЕ
Народ, кто уже разбирался с ним, скажите плиз, его можно портировать на ИЕ (ну переключения курсора по F7 - само-собой отпадает)? Эти его inplace hot areas, прикольнули конечно... (кто желает посмотреть, должен скачать этот эдитор, так как он-лайном почему-то редактировать нельзя...)

Конечно, там есть и кроссбраузерные (тот же ФЦКЕдитор), но технология то совсем другая...

Автор оригинала: slach
=)
1) все что может быть СТРУКТУРИРОВАНО редактируется обычной ВЕБ формой на сервер кладется POST'ом и на сервере хранится в SQL или если позволяет сервер базы данных в XML

т.е. в любом случае, пользователь может редактировать исключительно текст... если нужно изменить диз - прийдётся редактировать уже сами xsl/xml шаблоны? Раньше юзер мог без труда (тот же ФЦКЕдитор) накидать кучу таблиц, дивов и т.д...

если уж так интересуешься то смотри в сторону
http://www.bitflux.ch/
и все это с использованием XSLT делается

а какие ещё СМС можете порекомендовать к "изучению" технологий построения xml-based сайтов... у Флюкса значительно страдает сторона документирования АПИ

p.s. Господа, пологаю, было бы замечательно, если кто-нибудь, разбирающийся в теме напишет что-то води статьи по созданию
XML CMS - тема всё более и более актуальная (если не вытесняющая "классические" CMS)

 

[Alexandre]

XML CMS - тема всё более и более актуальная (если не вытесняющая "классические" CMS)

использование XML CMS несет на себе следующие недостатки:
- ограничение использование данных по объему контента
- ограничение использования по нагрузке посещения, т.е. проблема flock
- менее надежный способ защиты файлов нежели данных БД
По этому в ближайшем будущем (3-5 лет) "классические" CMS еще будут преобладать над XML CMS.

Развитие XML CMS подтолкнет, если будет внедрен модуль XQuery в существующие Опенсоурсные БД. Притом, хочу заметить, что модуль XQuery должен быть именно внедрен, а не быть надстройкой над существующей БД ( модулем интерпретации SQL)

Судя по темпам освоения XML технологий, это возможно произойдет в течение трех лет. Ну еще заложимся года два на раскачку и изучения технологии XQuery.

 

[eurolinedev]

Автор оригинала: Alexandre
использование XML CMS несет на себе следующие недостатки:
- ограничение использование данных по объему контента

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

- ограничение использования по нагрузке посещения, т.е. проблема flock

т.е., если правильно Вас понял, проблема синхронизации, что-то типа lock read | lock write?
ну а если в БД держать только сам контент (инфу), тогда локи можно как угодно ставить (ну ессно в зависимосте от сервера БД)

- менее надежный способ защиты файлов нежели данных БД

это да...

Alexandre, а что бы ещё могли порекомендовать в дополнение к http://www.bitflux.ch/

 

[Alexandre]

что бы ещё могли порекомендовать в дополнение к http://www.bitflux.ch/

к сожалению, я с http://www.bitflux.ch/ и аналогами не знаком. По этому, порекомендовать ничего не могу.

В случае больших порталов, ЦМС пишется исключительно под проект, так как правило, большие порталы - это не ординарные проекты и в них мало типовых решений (в смысле типовых реализаций).

-~{}~ 20.04.06 16:43:

не скромно говорить о себе, но у меня опыт работы с XSLT более 3х лет (теоретически с 2002 ), но реально в качестве шаблонизатора, я его использовал только в двух проектах. При том, в одном проекте из-за большого объема данных - XSLT процессор просто умирал (формирование эксельной таблицы 3 000 строк) и мне пришлось отказаться от этой технологии.

использование технологии XSLT должно быть оправдано. На сегодняшний день - ее использование в качестве шаблонизатора на много проигрывает в скорости обычным шаблонным движкам.

-~{}~ 20.04.06 16:46:

Правило 2 ; ) не следует использовать какую-то технологию, ради технологии

 

[eurolinedev]

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

просто не хочется отставать от "моды" что-ли... а посему приходится нарушать это самое правило...

резюмируя: xml - конечно рулез, но использовать как шаблонизатор для "универсальной" СМС - пока рано или вообще не стоит.
Удел xml (если здраво смотреть на вещи) - конфиги, схемы, какая-то простая мета-информация и т.д.

Но, господа, почему тогда такой ажиотаж вокруг xml\xsl в областе СМС?

 

[Alexandre]

почему тогда такой ажиотаж вокруг xml\xsl в областе СМС

сам удивляюсь, и не раз задаю себе вопрос, а так же ни как не пойму почуму суета во круг ДотНета? Мода наверное.

Собственно, самого ажиатажа во круг ЦМС в области xml\xsl лично я не наблюдаю, да и Рекомендации W3C читать надо внимательней, на сколько я знаю, там ЦМС не упоминается (могу отстать от жизни, признаюсь давно не просматривал изменения).

Удел xml (если здраво смотреть на вещи) - конфиги, схемы, какая-то простая мета-информация

Удел xml, Соответсвуя Рекомендациям W3C - это передача структурированной информации между разнородными приложениями, так сказать универсальный слой обмена Данными. Все остальные практические стороны применения xml, так сказать конфиги, и какая-то простая мета-информация - это уже промыслы народных умельцев (хочу отметить, что из них есть много даже удачных экземпляров).
А схемы были придуманы для описания самого xml, вернее спецификаций, разрабатываемых на базе того самого xml, опять же для того, чтоб понять (тебе чужую структуру или твою, кому-нибудь) или проверить структуру данных используемой (на базе xml) спецификации .