Шаблонизатор CTPP2

> интерфейсы для С++

Веб-программирование на С++? О_о

Если это правда, то мои почет и уважения одиноким воинам дзена.

По ссылке что-то, кажущееся вменяемым. Занёс на полочку головного мозга.

Вариант WEB-интерфейса для сервера приложений на C++ Вы не рассматриваете?

Сервер приложений на С++? o_O

COM+ восстал из мертвых?

COM+ - единственно возможный вариант программирования на C++? o_O

наконец то появилось хоть что-то, заслуживающее внимание.

> Веб-программирование на С++? О_о

> Если это правда, то мои почет и уважения одиноким воинам дзена.

Неужели на асме никто не пишет??

>Неужели на асме никто не пишет??

Веб-сервера? :)

Ну и да, а портабельность как же? :)

Что вы уперлись в этот WEB-сервер? Классическую WEB-страничку с мускульной базой на плюсах естественно не пишут. Задачи бывают разные.

> единственно возможный вариант программирования на C++? o_O

Поддержку транзакций в сервере приложений руками писать бум или есть третий вариант, о котором я не слышал? O_o

Вообще то транзакции БД предоставляет, при чём тут сервер?

> Веб-программирование на С++? О_о

А чем это вас удивляет? О_о

> Вообще то транзакции БД предоставляет, при чём тут сервер?

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

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

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

Кто вам господа мешает использовать xslt и его наработанные за 10 лет преимущества? даже в любимом Cpp с ним очень приятно работать, особенно для веб приложений

Только мат в голову лезит. Хватит уже изобретать велосипеды. Все претенденты использования описанные на сайте можно решить при помощи xslt. На это создатели отвечают:

> При этом не требуется специальных знаний таких сложных технологий, как, например, XSLT.

XSLT очень простой язык. Освоил за день - благо есть спецификации от w3c и куча примеров. Но если охота иметь что-то свое, то почему бы не написать свою версию XSLT процессора. Читал, что ребята на рефале написали версию, которая работает в разы быстрее, если XML снабжается DTD. Версия xslt под mono работает быстрее libxslt за счет того, что само преобразование компилиться при первом запуске.

Вообщем, это пиздец.

> Кто вам господа мешает использовать xslt

Здравый смысл :)

> XSLT очень простой язык.

Да все языки простые. Вот только одни языки делали люди для людей, а другие делал скайнет для скайнетов. На XML-е программировать может только очень терпеливый человек.

> Да все языки простые. Вот только одни языки делали люди для людей, а другие делал скайнет для скайнетов. На XML-е программировать может только очень терпеливый человек.

Жжошь! Ффортунки :)

А что уже есть в продакшине написанное на на этом чудо-велосипеде?

Короче, хватит нам такого говна. Есть мейнстрим, напрмер Template-Toolkit или YTML::Template для перла. Вылизанные годами технологии. Есть быстрые версии. А ради ускорения на 10% ставить поделку Васи Шуткина желания нет.

Итого, приговор: в сад (т.е. на сайт разработчика), до момента взросления (т.е. лет на 5-7). Там посмотрим.

ЗЫ. 99 из 100, кто говорит об чистом МВС в вебе плохо понимают эту модель. :(((. Автор новости, очевидно, очевидно из их числа.

> Только мат в голову лезит. Хватит уже изобретать велосипеды. Все претенденты использования описанные на сайте можно решить при помощи xslt.

решить можно с помощью многих средств, вопрос только насколько это будет юзабельно вконце. xslt плохо решает вопрос разделения кода и представления в реальный условиях. это буквально язык программирования, а часто нужно чтобы шаблон оставался читабельным верстальщику после вмешательства кодера. xml структуры жутко тяжелые и при большом их объеме визуально отделить html код от xsl нелегко.
еще много проблем создает строгость xml'я, т.к. порой темплейты правят нубы-верстальщики и до них туго доходит что сущности нужно эскейпить. 1 ошибка и весь сайт может перестать грузиться. хорошо если стэйджинг какой-то... ну и вставки результатов какого-нить FCKEditor'а тоже радости мало доставляют. тяжелые темплейты могут неплохо нагрузить сервер, а рендеринг на клиенте может наглухо подвесить браузер. в общем нюансов есть, хотя плюсов тоже есть. не идеал.

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

>xslt плохо решает вопрос разделения кода и представления в реальный условиях

xslt хорошо решает вопрос разделения кода и представления в реальных условиях. Просто подходить нужно к делу с умом и использовать адекватные средства, а так же знать xslt.

Кроме того xslt обеспечивает прозрачную миграцию с одной платформы на другую.

>есть интерфейсы для [...] PHP

О, хорошо. Как раз мой фреймворк позволяет любые шаблонизаторы юзать. Надо будет заценить, а то на особо нагруженных логикой шаблонах Smarty имеет неудовлетворительную для высоко загруженных систем производительность. Сейчас в этом случае в качестве шаблонизатора сам PHP использовать можно, но это не так интересно :)

>>Неужели на асме никто не пишет??

> Веб-сервера? :)

http://www.kyllikki.org/hardware/wwwpic2/

? :)

>XSLT очень простой язык. Освоил за день - благо есть спецификации от w3c и куча примеров.

Синтаксис у него тако, что...

>Вообщем, это пиздец.

> 99 из 100, кто говорит об чистом МВС в вебе плохо понимают эту модель.

А слабо по ссылке сходить? ;) Там есть рациональное зерно. Мне понравилась вот эта фраза:

``Логично доработать модель MVC таким образом, чтобы часть информации обрабатывалась в представлении. Иными словами, чтобы основной набор данных по-прежнему создавался набором моделей, а окончательная подготовка к выводу производилась в специальном блоке - процессоре данных.''

> xslt хорошо решает вопрос разделения кода и представления в реальных условиях. Просто подходить нужно к делу с умом и использовать адекватные средства, а так же знать xslt.

невероятно обоснованно. и естественно ваш ум самый умный ум в мире и никто даже не догадывается что такое xslt. так и есть.


> Кроме того xslt обеспечивает прозрачную миграцию с одной платформы на другую.

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

>>>xslt плохо решает вопрос разделения кода

>>xslt хорошо решает вопрос разделения кода

>невероятно обоснованно

Это ирония.

xslt можно привести в читабельный вид благодаря xsl:include, xsl:import. Если использовать композицию из двух преобразований, то это позволяет добиться вынесения часто используемых приемов в некую библиотеку, например, <email bind="Form/Email"/> в первом преобразовании будет пропущен, а на втором обработан уже библиотечным шаблоном. Что касается средств, то mono, например, позволяет компилировать xslt (на лету), при том полученные объекты - thread safe. Таким образом сам xslt парситья только раз, а затем работает быстрее libxslt.

> Вообще то транзакции БД предоставляет, при чём тут сервер? Вопрос о транзакциях в состоянии сервера приложений (в т.ч. распределенных) а не транзакциях в СУБД, хотя они могут быть частью транзакции сервера.Писать таки да, руками. Для очень больших распределенных проектов framework на яве конечно полезнее будет, но не всегда это бывает нужно. Может быть например задача WEB-интерфейса к несложным разрозненным демонам, не требующим транзакций.faber (*) (15.05.2008 21:34:35)

А что ХА транзакции в яве впервые появились ? И CORBA конечно-же создавалсясь для жабы ... И никому в голову не придет, что монитор транзакций Taxedo в свое время был написан на С и имел интерфейсы к С++ ... MQ-Series целиком на С написана и поддерживает распределенные транзакции и для С и для С++ и для жабы. Дрова оракла для С++ тоже распределенные транзакции поддерживают. Persistence Layer фреймворков конечно наперечет и все комерческие, но написать свой, не гибкий и не адаптируемый к "любым" задачам, но очень шустрый - дело пары дней. Стоит ли морочить себе голову с re-usability если под задачи за пару дней все склепать можно ? Или купить готовый на все случаи жизни, если пр-во потоком идет и нет желания под каждый проект велосипед изобретать.

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

З.Ы. Авторам советую пользоваться OpenOffic'ом при наборе текста - даже не вчитываясь в текст заметил 2 опечатки =)

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

Ты еще не видел как сообщения об ошибках выводит :))). Если сможешь хоть что-то понять - значит ты сам автор этого идиотизма. :)

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

> Ты еще не видел как сообщения об ошибках выводит :))). Если сможешь хоть что-то понять - значит ты сам автор этого идиотизма. :)

Ну, уважаемый, не стоит так грубо. В конце концов любой труд - почётен. Возможно его функционал и стоит потраченных на изучение данной системы часов (недель?).

смотрю http://ctpp.havoc.ru/php-ctpp-tutorial.html . в библиотеке шаблонизатора для PHP они параллельно реализовали интерфейсы и в стиле ООП и в стиле процедурного программирования. интересно, зачем эта "двойная работа" -- ведь по сути они делают одно и тоже?... или есть какая-то принципиальная разница?

> Smarty имеет неудовлетворительную для высоко загруженных систем производительность. Сейчас в этом случае в качестве шаблонизатора сам PHP использовать можно, но это не так интересно :)

Smarty компилируемые шаблоны. И на выходе тот самый PHP. Главное не включать force_compiler и директорию под скомпилированные шаблоны прописать. Плюс к этому можно ещё еАкселератор прикрутить.

Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django Django
Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu Desu

Fastest templating engine ever, гыгы ;))? См. http://www.codeirony.com/?p=9, полезно.

>зачем эта "двойная работа" -- ведь по сути они делают одно и тоже?... или есть какая-то принципиальная разница?

1) В PHP4 нет интерфейсов в стиле ООП.

2) Различий в сишном коде экстеншена между ООП и не-ООП - 3 строчки на метод.

>Fastest templating engine ever, гыгы ;))? См. http://www.codeirony.com/?p=9, полезно.

Отличная статья. Но только говорится в ней не про template processing, а про отвратно реализованное взаимодействие с БД.

В нормально написанных вебпроектах бОльшая часть времени исполнения - это как раз template processing. См. презентации facebook и других подобных систем.

А можно ли узнать твое имя аноним? :) Я плотно работаю с этим шаблонизатором второй месяц. До этого много работал с Template-Toolkit, HTML::Template, Smarty и прочими. CTPP2 меня полностью устраивает как скоростью, так и возможностями.

>>>>Fastest templating engine ever, гыгы ;))? См. http://www.codeirony.com/?p=9, полезно.

>>>Отличная статья. Но только говорится в ней не про template processing, а про отвратно реализованное взаимодействие с БД.

>>>В нормально написанных вебпроектах бОльшая часть времени исполнения - это как раз template processing. См. презентации facebook и других подобных систем.

Не путайте теплое с мягким. В больших проектах под "template processing" поимают весь цикл сбора инфы с для отображения, а у нас разговор только про "физический" рендеринг страницы. По вашей логике, например Каталиста, - один большой шаблонизатор. :)))

>Поддержку транзакций в сервере приложений руками писать бум или есть третий вариант, о котором я не слышал? O_o

Tuxedo, COM+ Transactions, Corba Transaction Service - сто лет в обед.

Не нашел ничего нового по сравнению со Смарти.

>Не нашел ничего нового по сравнению со Смарти.

И с каких это пор для Смарти можно писать на Perl? :)

> В нормально написанных вебпроектах бОльшая часть времени исполнения - это как раз template processing

Хм, кто это сказал? Где это написано? Уверяю вас, такие проекты НЕнормальны!

>Хм, кто это сказал? Где это написано? Уверяю вас, такие проекты НЕнормальны!

Да вот, говорят, есть такие проекты: facebook, flickr ....

А много ли вообще кто-нибудь знает шаблонизаторов имеющих библиотеку для перла, пхп, c++ и т.д.?

Да и не нужен CTPP2 для крутых писателей хомячков и супермагазинов на 5000 товаров и с сотней посетителей в день. Иди и юзайте дальше свой смарти и радуйтесь этому. Этот шаблонизатор расчитан на проекты с десятками миллионов показов в день. Вот тут мы и получаем плюсы, когда что-то отладить и протестировать можно на перле или пхп, а потом шаблон без каких либо изменений перенести на боевой сервер, где контроллер написан на С++.

>на боевой сервер, где контроллер написан на С++.

И как часто такие сервера встречаются? ;)

Встречаются... :) Не все, к счастью, идут по пути: сейчас все напишем на пхп, а будет тормозить - поставим 1000 серверов с мемкешем...

Просто в таких случаях обычно не на Си++ переписывают, а на Java :) Си++ в этом аспекте - что-то крайне маргинальное :D

>>>Неужели на асме никто не пишет??

>> Веб-сервера? :)

>http://www.kyllikki.org/hardware/wwwpic2/

Прочитал. И какие же архитектуры он поддерживает?