Простой шаблонизатор (HTML+CSS) или XML/XLST связка

[440hz]

Простой шаблонизатор (HTML+CSS) или XML/XLST связка

Сейчас на одной системе в качестве шблонизатора стоит простой самописный быстрый шаблонизатор. Новый программер упорно пропихивает менеджерам идею глобальной XML/XLST шаблонизации как новой, перспективной и т.д.

что б ему такого сказать кроме того, что:

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

мож я не прав? поправьте?

не ради флеймы а истины для!

есть у кого какой опыт?

 

[atv]

Сейчас на одной системе в качестве шблонизатора стоит простой самописный быстрый шаблонизатор.

Если уже стоит, так тут аргументов не нужно, переводить на новую технологию нерентабельно.

Другое дело, если внедрить в новой системе, так тут твои аргументы слабоваты.

 

[IIIEPJIOK]

http://phpclub.ru/talk/showthread.php?s=&threadid=105609&rand=51

 

[Pabla]

Может стоит узнать, каких возможностей не хватает ему в текущем шаблонизаторе?

 

[440hz]

Автор оригинала: Pabla
Может стоит узнать, каких возможностей не хватает ему в текущем шаблонизаторе?

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

-~{}~ 12.03.08 13:47:

Автор оригинала: IIIEPJIOK
http://phpclub.ru/talk/showthread.php?s=&threadid=105609&rand=51

о! огромное спасибо!

 

[AmdY]

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

 

[IIIEPJIOK]

AmdY
Стесняюсь сказать, я не понял, вообще ничего, что вы имели ввиду, если не сложно, поясните:

это кривость бошльшинства реализаций

чего, шаблонизаторов?

второе скорость и тюнинг

дык, что по вашему быстрее? что вы имели ввиду по "тюнинг"?

В течении пару суток, а то и за один день, можно заменить xslt на смарти и получить тот же функционал

это в пользу XSLT или смарти?
ЗЫ
заранее прошу простить за "непонятливоть".

 

[Alexandre]

440hz, ты мне на инструктаж этого программера пришли, я ему мозги прочищу.
если бы у XSLT было б больше достоинств, чем у того простенького шаблонизатора, что мы с тобой написали, тогда бы в нашей ЦМСке давно уже бы использовался бы XSLT. Передай ему это от автора Шаблонизация XSLT
и чего ему там не хватает? минимальный функцианал построения шаблонов присутствует.

[off]Пора пить кофе

В течении пару суток, а то и за один день, можно заменить xslt на смарти и получить тот же функционал.

хех.. это как сказать. все зависит от того, на сколько глубоко используются XML технологии. У меня в одном проекте, сразу из БД принимался XML, на который еще довешивался кусок XMLя, ну и это все конвертировалось XSLT. А в некоторых местах - приходилось конвертировать 2 раза.
короче, чтоб перейти на смарти, тебе надо будет переписать 50% движка, не говоря о полной переработке структуры всех шаблонов (речь идет именно о структуре или логике шаблонизации а не о самих шаблонах).

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

кстати это хорошее качество - Познание мира. Только эти технологии надо с умом внедрять. Один студент убедил руководство использовать Оракл в простом проекте, где вполне хватало бы и мускуля. В результате, из-за ресурсоемкости оракла или не правильного администрирования... проект стал жутко тормозить. Это так - оффтоп.

-~{}~ 13.03.08 02:27:

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

и еще, XML очень строг к синтаксису. незакрытие какого-нибудь тега или пропущенного апострофа может вилиться в часы поиска. а если это не знак, а невидимый метасимвол??

 

[atv]

незакрытие какого-нибудь тега или пропущенного апострофа может вилиться в часы поиска.

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

 

[Alexandre]

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

 

[IIIEPJIOK]

на мой взгляд, мысль примерно такого содержания "XML/XSL - имеет минус в том, что в моей команде нет специалистов должной квалификации" - не очень корректна.
Это минус не технологи, а команды, разве нет?
Скорее правильнее сказать: "Команда, в которой я работаю, не может использовать XML/XSL, в связи с отсутствием (необходимого количества) специалистов должной квалификации." Но это будет совсем другая история.

 

[atv]

Alexandre, чтобы добиться корректного отображения страницы, да ещё в разных браузерах, верстальщику необходимо следить за тегами, в чём бы он не верстал, в HTML или в XML. Так что для них это как дважды два. В XML просто добавляются некоторые обязательные теги. Вторая и третья ошибки (ты наверно имел ввиду зависимые от первой), вылазят не так уж часто.

Так что, этот минус XML сильно преувеличен

 

[440hz]

Скорее правильнее сказать: "Команда, в которой я работаю, не может использовать XML/XSL, в связи с отсутствием (необходимого количества) специалистов должной квалификации." Но это будет совсем другая история.

в точку!
сенкс.

 

[IIIEPJIOK]

в точку!
сенкс.

Рад стараться

 

[AmdY]

IIIEPJIOK поясняю.
в виденных мной реализациях шаблонизации на xslt была куча багов, неудобства работы и ограничений. Где-то символы проскакивают, где-то пустые теги закрываются (<textarea/>), где-то невозможно всунуть частичное кеширование, где-то геморное формирование самого xml.
Я неплохо знаком с xslt и знаю его плюсы и минусы и меня просто бесит когда его используют там, где легко можно заменить обычным шаблонизатором. Есть задачи в которых шаблонизатор не сравнится с xslt (exslt), вот в них и нужно использовать данную технологию, а не xslt ради XSLT

 

[Alexandre]

Есть задачи в которых шаблонизатор не сравнится с xslt (exslt), вот в них и нужно использовать данную технологию, а не xslt ради XSLT

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

 

[IIIEPJIOK]

IIIEPJIOK поясняю.
...........

Спасибо

Чтоб не создавать новую тему, у меня вопрос ко всей аудитории...
XSL-преобразование на стороне клиента vs на стороне сервера. Кто что думает?

 

[Pabla]

Автор оригинала: IIIEPJIOK
XSL-преобразование на стороне клиента vs на стороне сервера. Кто что думает?

Если преобразование не сложное, то все прекрасно работает.

 

[джамшут]

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

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

да, и переведите мне xslt шаблон, использующий apply-templates, на смарти. а я посмеюсь :-D

 

[Alexandre]

сли преобразование не сложное, то все прекрасно работает.

все хорошо, но не для всех браузеров. (а делать двойную работу, как-то не хочется) Лично я за - на стороне клиента, так как мы разгружаем часть операций на сервере. данное решение Хорошо для внутреннего портала, когда всех можно просто обязять пользоваться осликом.