Все согласны с этим утверждением?

RossVic, а зачем на JAVA cms, простите меня.

RossVic, Вы вообще Java владеете? Если нет, почему пишите и утверждаете то, что не знаете? Что такое вопрос технологичности? Все, что можно сделать на PHP, можно сделать и на Java. Но ни в коем случае не наоборот, PHP даже 10% возможностей Java не покрывает. Взять те же persistent objects...

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

Все. Остальное - минусы. Да, PHP - конкурент джаве в проекте с бюджетом 500 USD. Но вообще не конкурент в чем-то более крупном. Про фреймворки, библиотеки, и CMS на Java - посмотрите в google. Сразу найдете массу и бесплатных, и платных Java решений.

Далее, про топик. Зачем вообще сравнивать производительность XSLT процессора и кода на каком-либо языке программирования? Как говорится, "сколько не качай мышцы, всегда найдется кто-то, более сильный". Да, Вы можете сделать код на PHP, который будет делать более быстрое преобразование. Кто-то еще может сделать это же на языке Ассемблера, и будет работать быстрее чем на PHP, наверное, раз в 100. Но почему не пишут все-все на языке Ассемблера? XSLT процессор - инструмент для преобразования документов. Зачем микроскопом гвозди забивать?

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

Цитата ("tvv"):

Все. Остальное - минусы. Да, PHP - конкурент джаве в проекте с бюджетом 500 USD. Но вообще не конкурент в чем-то более крупном. Про фреймворки, библиотеки, и CMS на Java - посмотрите в google. Сразу найдете массу и бесплатных, и платных Java решений.

Вы имеете ввиду, не конкурент для разработки с нуля крупного программного комплекса? Потому что при выборе "рефакторинг/дописывание существующего кода" vs "Полная переделка существующего кода" вполне может быть конкурентом Ведь довольно крупные проекты крутятся на PHP (например badoo.com, mamba.ru , liveinternet.ru и др.) Довольно крупные проекты крутятся на Perl (mail.ru, yandex.ru, rambler.ru, elance.com) - не потому что java плохая, а потому что исторически так сложилось )))))))

perldev, да, я же не спорю что есть крупные проекты на PHP/Perl. Совершенно верно, сложилось исторически. И только потому, что заказчикам конторы-исполнители предложили PHP/Perl решения, так как у них были в наличии такие специалисты. Ведь джавистов днем с огнем не найти было что раньше, что сейчас (любой малейший джавист сразу заманивается в какую-либо IT компанию, что в местную аутсорсинговую, что в западную, и почти всегда на крутую зарплату, редкодостижимую на фрилансе).

"крутую зарплату" - это сколько?
ссылка
Пока что Perl'овики ценятся выше Java-кодеров, и это радует
Но недолог тот час, когда я напишу свою последнюю "1;" в конце программы на Perl.
Эх...

P.S. Кстати java-кодеров в Мск, как собак нерезанных. И это радует - популярность платформы в первую очередь определяется количеством кодеров.

Остался вопрос об XSLT в качестве шаблонизатора, давно собираюсь написать такой для фреймворка студии, но мучат сомнения производительности. Вот tvv, например, не рекомендует использовать его для постоянных преобразований, но разве цепочка MySQL->PHP->XML->XSLT->HTML не является постоянным преобразованием? По-моему это будет сильно нагружать систему, или я не прав? Изучаю XSLT но на счёт крупных проектов не уверен, как говорили люди с яндекса: не стоит использовать его в качестве шаблонизатора, XSLT это средство преобразования XML документов, а шаблонизаторов в PHP полно... (с РИТ 2007)

Вообще если у кого-нибудь есть опыт реализации XSLT-шаблонизаторов, то отпишитесь пожалуйста, ну оооочень интересно

Zionit
Поищите на хабрахабре последние статьи по xslt - там все очень хорошо было разобрано.

Смотрел, читал. Вопрос в основном с надежной на ответ tvv

____________________
Добавлено через 30 секунд:


Кстати, прикол)))))) ссылка только написал пост о tvv, сразу нашёл его на хабре по запрос ХСЛТ)))

Zionit, тут принцип простой.

Попытайтесь замерить, насколько часто нужно будет выполнять XSLT преобразования в проекте?
Если это может быть часто, например при каждом реквесте, то такое решение - неприемлемо.
Если относительно редко, например после обновления данных в админке CMS, или например раз в 10 минут формируются страницы ленты новостей из внешних источников, и т.д., а затем результат кешируется, то смело можно использовать XSLT преобразование.

В таких случаях ситуация очень двузначная. С 1 стороны на сайтах в основном контент обновляется редко и генерировать всё 1 раз в 10 минут допустимо, но с другой стороны есть такие блоки, например комментарии, которые нужно изменять динамически.

Как лучьше поступить в этом случае, можно ли оставить XSLT? И как поступать с динамическими частями?

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

Дело в том, что такие цыфры получить нереально, тк. шаблонизатор планируется встроить в КМС, которая может использоваться как на маленьких, так и на крупных проектах. Изначально она будет оптимизирована именно под крупные.

Мне интересно как разработчики УМИ.КМС решили проблему производительности.

Так кешируй.
HTML-код каждого комментария будет браться из кеша. А если в кеше пусто, тогда этот комментарий преобразуется.

Цитата ("alibek"):

Так кешируй.
HTML-код каждого комментария будет браться из кеша. А если в кеше пусто, тогда этот комментарий преобразуется.

Чтобы добавить 1 комментарий нужно будет выполнить полное преобразование всей страницы, а если комментарии будт писать каждые 3 секунду, то это уже большая нагрузка ...

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

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

Цитата ("alibek"):

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

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

Тогда это будет 2 вида шаблонизации, такой выход возможен, но это хардкодинг уже Получиться что для комментариев XSLT в качестве шаблонизатора использовать НЕЛЬЗЯ, хотя во всех остальных частях он будет. Соответственно для коментариев тоже нужно какой-то шаблонизатор

Чтобы сказать точнее, следовало бы проверить.
В конце концов это очень простое преобразование, может быть и непосредственный XSLT окажется подходящим.

Более тормознутого чем ХСЛТ преобразование нужно ещё поискать, оно в любом случае будет притормаживать.... Постоянные преобразования делать нельзя...

В крайнем случае кто мешает переложить XSLT на клиента?
Сайт будет отдавать XML и XSL, причин тормозить у него не будет.
А у клиента уже будет трансформироваться.
И все будут довольны, уж у клиента комментарии точно не будут по три раза в секунду обновляться.

Нет, а как же поисковые машины? Как же браузеры без поддержки XSLT (даже там где поддерживаеться, часто глючит)