Гм. А английский подучить?

Некоторые модули (а не сам перл! К тому же почему-то не указано, какие именно модули) могут создавать временные файлы с предсказуемыми именами. В результате можно НЕ получить доступ к ЛЮБОМУ файлу, а сделать линку и запортить какой-либо файл (если у запускающего скрипт будет достаточно прав). Т.е. еще нужно знать, кто данный скрипт запустит и когда.

Вывод - опасность ниже средней.

to PAL: otozh poyomu i virusov pod *nix vsego paru desyatkov - glavnoe: kto i kogda

> Некоторые модули (а не сам перл! К тому же почему-то не указано, какие именно модули) могут создавать временные файлы с предсказуемыми именами. В результате можно НЕ получить доступ к ЛЮБОМУ файлу, а сделать линку и запортить какой-либо файл (если у запускающего скрипт будет достаточно прав). Т.е. еще нужно знать, кто данный скрипт запустит и когда.

Ну по самому срипту типа непонятно, что он может сделать. Например root свою рутину автоматизирует. Права root - это круто. Тут можно и /dev/hda вместо временного файла подсунуть. :)

>Вывод - опасность ниже средней.

В принципе да. Но все равно неприятно. Поэтому, все дружной толпой перестаем юзать это дырявое поделие и переходим на питон.

Можешь заодно перестать пользоваться и этими поделками: gettext, GNU Ghostscript, glibc, GNU Groff, gzip, kerberos5, lvm, mysql, netatalk, openssl, perl, libc6, and postgresql

http://xforce.iss.net/xforce/xfdb/17583

>Можешь заодно перестать пользоваться и этими поделками: gettext, GNU Ghostscript, glibc, GNU Groff, gzip, kerberos5, lvm, mysql, netatalk, openssl, perl, libc6, and postgresql

Есть множество других причин отказаться от перла. Читай трэд про python-2.4. Там было признано всеми, что перл непригоден ни для каких задач. Эта дырка -- последняя капля, которая должна переполнить чашу терпения честных юзеров, админов и программеров.

это признано только тупорылыми анонимусами :)

> это признано только тупорылыми анонимусами :)

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

Вполне возможно :), а я имел в виду тех, кто не способен отличить дырку в модуле от дырки в интепретаторе и делает идиотские заявления типа "Там было признано всеми, что перл непригоден ни для каких задач".

>Вполне возможно :), а я имел в виду тех, кто не способен отличить дырку в модуле от дырки в интепретаторе и делает идиотские заявления типа "Там было признано всеми, что перл непригоден ни для каких задач".

Вот поэтому не надо делать идиотских обобщений. Если один анонимус придурок, то не надо кричать, что придурки все. Надо говорить так:

"анонимус, который сказал, что перл говно -- придурок" "анонимус, который сказал, что питон рулит -- идиот"

Но фраза "тупорылые анонимусы" неправдива...

> делает идиотские заявления

Если следовать логике этого анонима, то любой софт, слинкованный с glibc "непригоден ни для каких задач". ;)

ЗЫ. Кто-нибудь смотрел, что там в PostgreSQL "исправили"? Скрипт из контрибов?

>Есть множество других причин отказаться от перла. Читай трэд про python-2.4. Там было признано всеми, что перл непригоден ни для каких задач. Эта дырка -- последняя капля, которая должна переполнить чашу терпения честных юзеров, админов и программеров.

Тогда тебе, вместе со всеми анонимусами того треда, дорога на тот же cpan.org, убеждаться в обратном. А бейсик вместе со всеми его инкарнациями - долой.

>>> Есть множество других причин отказаться от перла. Читай трэд про python-2.4. Там было признано всеми, что перл непригоден ни для каких задач. Эта дырка -- последняя капля, которая должна переполнить чашу терпения честных юзеров, админов и программеров

не гони, перл юзали и будут юзать

> Есть множество других причин отказаться от перла. Читай трэд про python-2.4. Там было признано всеми, что перл непригоден ни для каких задач. Эта дырка -- последняя капля, которая должна переполнить чашу терпения честных юзеров, админов и программеров.

Если ты мне покажешь аналог перлового TT2 для Python, обещаю купить по Python'у букварь и почитать на досуге. Если ничего похожено в Python нет -- фтопку.

Только учти, никакой самодеятельности, нормальный, работоспособный, бесплатный аналог, внутреннему языку которого я смогу обучить дизайнера в течение получаса. Так что никаких заморочек с типизацией данных, никаких "страшных символов", никакой разницы между обращением к процедуре и обращением к данным. Одним словом, аналог должен уметь Do The Right Thing с одной стороны и быть до неприличия расширяемым с другой.

Наличие в нём возможности написания собственных плагинов и наличие необходимой для этого инфраструктуры даже не обсуждается.

> Если ты мне покажешь аналог перлового TT2 для Python...

4Suite, и никакой самодеятельности вроде самописных шаблонов, которых и так развелось выше крыши. Аналоги в Перле тоже есть, но, перепробовав три из CPAN, я нашел только один работоспособный.

Заодно посмотрите шаблоны Zope, которые работают и в "оторванном" от Zope состоянии, если уж так хочется экзотики.

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

Вы бы еще домохозяек вспомнили. :D

По поводу CPAN... Размеры, конечно, впечатляют, но, честно говоря, работоспособность некоторых модулей оставляет желать лучшего. Кроме того, много дубликатов, делающих по сути одно и то же, но предоставляющих разный API.

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

TT2 это темплейт тоолкит?

Как по мне так уж больно распухший модуль. Я доку к нему почитал, это ж сколько надо учить что б на нем хоть что-то намалевать? Да, пакет мощный, из цикла "мы не используем более 90 процентов его возможностей"

Вот скажите, нафига из хтмл темплейтов вызывать SQL запросы? И всякие фор и ду зачем там нужны ? ;)И идея !учить дизайнера! "программировать" внутри темплейта мне не нравится.

Кто б провел агитку по теме тт2 и обьяснил чем же хорош этот монстрик... ;)

> Вот скажите, нафига из хтмл темплейтов вызывать SQL запросы?

Чтобы сделать дырку в безопасности, а потом долго ее исправлять :D

> И всякие фор и ду зачем там нужны ? ;)И идея !учить дизайнера! "программировать" внутри темплейта мне не нравится.

А вот циклы в шаблоне нужны. И шаблон должен делать, ИМХО, не дизайнер, а верстальщик, в совершенстве разобравшийся с языком шаблона.

Однако как, таки, python стремительно набирает вес. В рунете еще год назад про python вспоминали не особо часто, примерно как сейчас про tcl, lisp или, скажем, ocaml с haskel'ем. А сейчас любая завязка треда про perl ведет к обсуждению python.

P.S. Python рулит :-)

А у меня работает php + bash и ни перл ни питон не нужны :)

Про циклы я согласен, когда программист в программе кидайт в темплейт массив данных, а верстальщик ими пользуется. Типа <start array> html <and array> Но зачем в темплейте организовывать свои for и прочие? Вместо удобного инструмента темплейтовый движок превращается в набор заморочек.

ИМХО самый верный подход не придумывать лишних сущностей. Программеру - программерово, верстальщику хтмл ; ) Как говорится идеал это когда нечего отнять, а не наоборот ;)

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

> 4Suite

Vrode prosili svobodnij analog TT2?

1) 4Suite - NE svoboden (GPL-incompatible) 2) Eto ne analog, ti predlagaesh web-designer'u uchit XSLT, etc...

> З.Ы. А ещё мне непонятен подход, когда товарищи начинают придумывать в темплейтах свои собственные псевдотаги, якобы для облегчения жизни вестальщика и реализовывать их поддержку в парсерах шаблонов... Такие жуткие монстры получаются...

Aga, zato dermeco ala JSP konechno rulezzz...

Nafig-nafig. Jakarta Velocity & TT2 rulyat

> 1) 4Suite - NE svoboden (GPL-incompatible)

GPL - не единственная свободная лицензия. Вы же наверняка используете такой же "несвободный" apache. :)

> 2) Eto ne analog, ti predlagaesh web-designer'u uchit XSLT, etc...

Во-первых, не дизайнеру, а верстальщику. Или у Вас и швец, и жнец, и на дуде игрец? :) Может, он еще и программист? :)

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

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

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

программист должен отдавать "сырые" данные

это мнение ленивого программиста ? ; ))))))

Template Toolkit 2 - позволяет совершенно отделить сбор данных от их представления.

Вызов SQL запросов из TT2 осуществляется через известный DBI. А в TT2 реализована только соответствующая обертка. _ПРИ_ЭТОМ! загружается эта обертка только при необходимости! Если в шаблонах не используются обращения к БД - то этот плагин _не_загружается и _не_отягощает систему.

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

У TT2 много плагинов: и для работы с изображениями, и для работы с датами, и для криптования. Но опять же - при желании их можно даже не устанавливать.

Помимо прочего очень удобно создавать сайты под mod_perl. И дизайнерам с верстальщиками потом эти сайта "украшать".


Возьмем, к примеру, интернет магазин.
создавая его разработали следующие объекты:
Товар, Корзина, Заказ, Покупатель, ...

Теперь передаем в парсер шаблонов ссылки на конструкторы этих объектов. И в одном из шаблонов:

-----
в вашей корзине:
[% FOREACH товар = Корзина.товары %]
товар.название - товар.цена
[% END %]
...
-----


При инсталяции другого магазина нужно будет ВЕРСТАЛЬЩИКУ всего лишь "обернуть" созданные шаблоны в новый дизайн. Или, зная интерфейс нескольких объктов, элементарно создать новые.

И никакого вмешательства непосредственно в perl-код.

Документация на русском. http://www.template-toolkit.ru

Я читал об этом, но зачем следующее

[% webpages = [ { url => 'http://foo.org', title => 'The Foo Organisation' } { url => 'http://bar.org', title => 'The Bar Organisation' } ] %]

<ul> [% FOREACH link = webpages %] <li><a href="[% link.url %]">[% link.title %]</a> [% END %] </ul>

В хтмл темплейте? Обычно данные требующие перечисления беруться из БД или ещё откуда нить, логично это делать из программы, выводив в темплейте одной конструкцией массива, а если они задаются в темплейте - какой в этом смысл? Легче сразу руками написать две готовые ссылки.

А [% FOREACH user = DBI.query('SELECT * FROM user ORDER BY id') %] <tr> <td>[% user.id %]</td> <td>[% user.name %]</td> <td>[% user.email %]</td> </tr> [% END %]

в шаблоне на мой взгляд вобще маразм, кто у нас шаблоны делает, программист? Вот [% 15 / 6 %] может и полезна в темплейте, так же как и форматирование или преобразование данных (хотя имхо это лучше предусматривать программеру) но вот в полезности [% CALL dbi.disconnect %] как в вызове функции в программе я усомнюсь.

Может я и не прав в своей попытке измерить ТТ2 своим аршином но после прочтения доки к той части ТТ2 которая отвечает за работу с шаблонами, мне захотелось повесится. Это какой же ужасной становится жизнь хтмл кодера ;) если нужно использовать все это обилие новых псевдоязыковых конструкций становясь чуть ли не программером..

На мой взгляд для веб темплейтов достаточно конструкций типа if/ifnot с возможностью == > <, массивов с возможностью ограничения видимости, вложения один в другой и рекурсии, библиотек щаблонов и переменных передаваемых из программы. Кеширование собранных темплейтов тоже не помешает ; ) Остальное обилие наворотов лишь отжирает процессор и память, оставаясь весьма сомнительной в концепции разделения оригинального труда программиста и кодера/дизайнера.

>Как по мне так уж больно распухший модуль. Я доку к нему почитал, это ж сколько надо учить что б на нем хоть что-то намалевать? Да, пакет мощный, из цикла "мы не используем более 90 процентов его возможностей"

Даже если используется 2% от его возможностей, остальные лежат себе на винте и не мешают работать. Зато если "внезапно" понадобится добавить ещё каких-нибудь фишек, то эти самые оставшиеся 90% придутся ой как кстати.

>И идея !учить дизайнера! "программировать" внутри темплейта мне не нравится.

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

В том то и дело, что "каких-нибудь фишек" в темплейты прибавлять не нужно ; ) нет таких фишек.. и не нужно ;)

Я понял вашу модель разработки, в одном лице - программеро/дзийнеро/кодер к бухгалтерским уклоном? ; )))) Тогда нет вопросов, снимаю шляпу.

>А вот циклы в шаблоне нужны. И шаблон должен делать, ИМХО, не дизайнер, а верстальщик, в совершенстве разобравшийся с языком шаблона.

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

Ты когда-нибудь видел ландшафтного дизайнера, которы не знал бы ничего про почвы, посадки, рост, вегетативный период, период цветения и прочие интересные вещи? Я лично ни одного. Точнее, все четыре знакомых ландшафтных дизайнера разбираются в биологии очень и очень неплохо. Зато почему-то считается, что веб-дизайнер не должен знать ничего, кроме Фотошопа, Корела, Флэша и, в лучшем случае ещё Дримвивера. Почему? Ты себе DB-админа, который SQL не знает представляешь? Я -- нет. И дизайнер, который не умеет сделать работоспособный шаблон я тоже не представляю. Это полудизайнер получается какой-то.

Кроме того, я не прошу дизайнера сляпать шаблон, который будет сам ходить в БД за данными, сортировать их и так далее. Самый сложный процесс взаимодействия -- это договориться об интерфейсе. Скажем, menu -- это массив хэшей с данными необходимыми для создания меню сайта, отсортированный в оговоренном порядке. Дизайнер умеет написать

[% FOREACH item = menu %]

<a href="[%- item.url -%]">[%- item.name -%]</a>

[% END %]

И все довольны. Проблема представления данных теперь лежит на дизайнере, моё дело -- доставить ему эти данные в том виде, в каком мы заранее договорились в то место, в какое ему надо. Дизайнер даже не узнает, что когда он зовёт menu, он на самом деле дёргает не массив хэшей, а определённую подпрограмму, которая ему этот массив собирает на лету. Ему, впрочем, это не только не обязательно, но ещё и совсем не интересно. За него TT2 с его Do The Right Thing интересуется.

Ну и кроме того всего, выплаченные заказчиком суммы лучше делятся на 2, чем на 3. Так что верстальщик, как ни крути, не нужен.

>В том то и дело, что "каких-нибудь фишек" в темплейты прибавлять не нужно ; ) нет таких фишек.. и не нужно ;)

Такое чувство, что ты живёшь в идеальном мире, в котором заказчик всегда знает, чего же он хочет. К тебе туда можно как-нибудь визу получить?

>Я понял вашу модель разработки, в одном лице - программеро/дзийнеро/кодер к бухгалтерским уклоном? ; )))) Тогда нет вопросов, снимаю шляпу.

Нет, не понял. Лица всё-таки два: дизайнер, который делает дизайн и шаблоны и я, который делает всю программную часть. С бухгалтерией у нас всё просто, так как никакого официоза в отношениях с заказчиком нет, если не считать ТЗ, которое мы на пару с дизайнером сами же и пишем. Да, геморрой. Да, не похоже на работу солидной транснациональной корпорации. Зато это очень хорошая прибавка к основной зарплате, и мне, честно говоря, плевать на [не]правильность организации нашего рабочего процесса. Он достаточно эффективен, чтобы не создавать лишних проблем. Как говорится, делать надо не "правильно" или "неправильно". Делать надо так, чтобы работало. Рамки понятия "работает" каждый определяет самостоятельно для каждого отдельно взятого случая.

> В связке Дизайнер-Верстальщик-Программист Верстальщик является оскорблением Дизайнеру, помехой Программисту и просто лишней сущностью.

Еще бы он не был помехой, если он SQL-запросы в темплейте корежить может :)

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

> Ты когда-нибудь видел ландшафтного дизайнера, которы не знал бы ничего про почвы, посадки, рост, вегетативный период, период цветения и прочие интересные вещи? Я лично ни одного. Точнее, все четыре знакомых ландшафтных дизайнера разбираются в биологии очень и очень неплохо. Зато почему-то считается, что веб-дизайнер не должен знать ничего, кроме Фотошопа, Корела, Флэша и, в лучшем случае ещё Дримвивера. Почему? Ты себе DB-админа, который SQL не знает представляешь? Я -- нет. И дизайнер, который не умеет сделать работоспособный шаблон я тоже не представляю. Это полудизайнер получается какой-то.

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

> В связке Дизайнер-Верстальщик-Программист Верстальщик является оскорблением Дизайнеру, помехой Программисту и просто лишней сущностью.

когда дело касается фрилансерских заказов, то верстальщик да, суть третья, лишняя.
Но если рассматривать работу конторы, то у меня сидит дизайнер, который получает очень хорошие деньги. Получает за то, что умеет за несколько часов в фотошопе сделать дизайн сайта. который менеджеры продают тоже за хорошие деньги. Он любит дизайнить, любит создавать изображения.
Зачем тогда напрягать его версткой ХТМЛ и шаблонов? За то время, что мы будем разбираться со структурой передаваемый в шаблон данных, за то время, что он будет верстать сайт, стоимость производимого им в эти часы упадет в разы!!! Зачем?

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

2 CybOrc: пожалуйста, внимательнее следите за обсуждением. Создается впечатление, что вы не читаете ответов, а говорите "лишь бы говорить".

Перечитайте сказаное вашими оппонентами ранее.

Это относится к реплике: CybOrc * (*) (09.12.2004 10:45:10)

> 2 CybOrc: пожалуйста, внимательнее следите за обсуждением. Создается впечатление, что вы не читаете ответов, а говорите "лишь бы говорить".

Конкретнее, пожалуйста, а то Ваше замечание больше напоминает нечистый полемический пример. Впрочем, что взять с анонимуса?

> Конкретнее, пожалуйста, а то Ваше замечание больше напоминает нечистый полемический пример. Впрочем, что взять с анонимуса?

пожалуйста. Ваше высказывание: "Еще бы он не был помехой, если он SQL-запросы в темплейте корежить может :)"

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

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

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

А дизайнеру писать XSLT шаблоны - это значит заниматься не своим делом.

> Ну и тогда какого хрена стоны на тему, что дизайнер не может XSLT понять и выучить? Это дилетантство, а не работа.

ты программист? и ты изучаешь фотошоп? и находишь, что знать фотошоп - это твоя работа?

бугагагаа...

Велкам ту идеальный мир

буду рад переместить плоскость беседы в сторону почты ;) без наездов, просто хочу побеседовать на тему темплейтов и движков... nassaja dog bk dot ru

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

А HTML::Template еще проще... для дизайнера. Для сайтов домохозяек в самый раз! :D

> А дизайнеру писать XSLT шаблоны - это значит заниматься не своим делом.

Дизайнеру вообще писать шаблоны - это значит заниматься не своим делом. Но если оный по совместительству веб-верстальщик, то основы верстки знать должен. :)

> ты программист? и ты изучаешь фотошоп? и находишь, что знать фотошоп - это твоя работа?

Я программист. Но я не дизайнер по совместительству. В данной беседе шла речь о дизайнере и верстальщике по совместительству.

2CybOrc

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

Попробую наехать на XSLT, а зачем оно нужно на сайте? Потому-что исходные данные вначале кто-то засунул в XML? Тогда вопрос, зачем? Берем чистые данные <оборачиваем в одну обертку, затем с помощью одной сложной для понимания и чтения штуки преобразовываем из этой оберкти а хтмл> добавляем дизайн и скрипты. Вот то что в скобках можно бы и опустить? ;) Я понимаю роль XML в ит мире, но я не могу понять модное веянье совать его во все дырки, как говорил один чел, врядли мы сможем описать весь мир в рамках XML... Пожалуйста пебеубедите меня, я не пустословно злословлю, я просто не понимаю полезность этого преобразования программа->xml->xslt->html, если можно воспользоваться скажем перлом плюс тт2 или пхп с их темлейтами...

И о тт2... В итоге у меня сложилось мнение, что этот монстрик написан программистами исключительно для программистов. Я всегда считал что любой темплейтовый движок служит прокладкой "оби" между темным миром программирования и странным миром дизайна/верстки. И его целью является ускорения/облегчения разработки сайта, что бы разные специалисты не ипали мозги себе и друг другу в процессе разработки, ибо гемора хватает и там и тут. А данная реализация предлагает скрестить ежа с ужом, добавив гемороя программеру и особенно верстальщику/дизайнеру (пускай уж они будут вместе, как Сид и Ненси ;))

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

Получается следующая система, минимальная программа на перле, что бы мод_перл смог её схавать и все остальное лабаем на новом искуственном языке прямо из темплейтов. Геморой товарищи! Искажение понятий!

Мне обидно, что под перл до сих пор нет компилятора (смотрим в сторону пхп) хотя бы в байт код (смотрим в сторону пхп), нормального, понятного, легкого и в то-же время мощного темплейтового движка (пхп). Да и нормального акселератора под апачь тоже не водится. Сами знаете какая жопа этот мод_перл и в какой букет "удовольствий" превращается разработка под эту (IMHO морально устаревшую) жопу сложных сайтов.

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

perl скрипт в байт-код:
http://search.cpan.org/~nwclark/perl-5.8.6/ext/B/B/Bytecode.pm

ТТ2 позволяет передавать в шаблоны объекты и работать с ними в шаблонах. Какой еще парсер шаблонов это позволяет?

Да, ТТ2 вырос уже к уровню своеобразного языка. НО! все его операторы можно перечислить по пальцам. В основном это: циклы и условия. Это как раз то, что нужно для создания представления данных из чистых данных.


>И о тт2... В итоге у меня сложилось мнение, что этот монстрик написан программистами исключительно для программистов. Я всегда считал что любой темплейтовый движок служит прокладкой "оби" между темным миром программирования и странным миром дизайна/верстки. И его целью является ускорения/облегчения разработки сайта, что бы разные специалисты не ипали мозги себе и друг другу в процессе разработки, ибо гемора хватает и там и тут. А данная реализация предлагает скрестить ежа с ужом, добавив гемороя программеру и особенно верстальщику/дизайнеру

и чем же ТТ2 добавляет гомороя?



Сейчас Ларри с Леопольдом и командой активно занимаются созданием Perl6 и виртуальной машины для него. В вирт. машние, кстати, изначально закладывается поддержка Питона.

> > ты программист? и ты изучаешь фотошоп? и находишь, что знать фотошоп - это твоя работа?

> Я программист. Но я не дизайнер по совместительству. В данной беседе шла речь о дизайнере и верстальщике по совместительству.

это вы предлагаете, что Дизайнер должен быть верстальщиком по совместительству. Я же вам предлагаю посмотреть на это с другой стороны: вам стать программистом и верстальщиком, по совместительству. Думаю, программисту не доставит большого удовольствие сидеть и резать шаблоны в фотошопе.

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

Да? А вы пользовались прежде чем показывать? Думаю нет. Попробуйте сделать это для программы с DBD::Mydql и парой модулей. Да хотя бы простой модуль конвертнуть в байткод, думаю что оно пошлет вас далеко и надолго.

По поводу перл6, к тому времени как появится сие чудо думаю везде будут рулить лонгхорн моно пхп и питон ) Долго ждать сию штуку.

По поводу ТТ2 вы мыслите как программист, я же писал свое мнение, темплейты должны разграничивать программу и хтмл. Кесарю - кесарево, знаете? А у вас все смешано. Просто попробуйте понять, какой прок хтмл верстальщику от кучи перловых обьектов в его шаблонах? ;) у него есть <form> и <h1> да css && jscript в придачу. Только обьектов и новых конструкция для этих обьектов ему нехватает для полного счастья.

Я так понял ТТ2 это заморочка под мод_перл, ибо видать легше извращаться в шаблонах чем писать под мод_перл нормальную программу. Одна кривость порождает другие загогулины

> Попробую наехать на XSLT, а зачем оно нужно на сайте? Потому-что исходные данные вначале кто-то засунул в XML? Тогда вопрос, зачем? Берем чистые данные <оборачиваем в одну обертку, затем с помощью одной сложной для понимания и чтения штуки преобразовываем из этой оберкти а хтмл> добавляем дизайн и скрипты. Вот то что в скобках можно бы и опустить? ;) Я понимаю роль XML в ит мире, но я не могу понять модное веянье совать его во все дырки, как говорил один чел, врядли мы сможем описать весь мир в рамках XML... Пожалуйста пебеубедите меня, я не пустословно злословлю, я просто не понимаю полезность этого преобразования программа->xml->xslt->html, если можно воспользоваться скажем перлом плюс тт2 или пхп с их темлейтами...

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

> Мне обидно, что под перл до сих пор нет компилятора (смотрим в сторону пхп) хотя бы в байт код (смотрим в сторону пхп)

А чем mod_perl для web плох?

> нормального, понятного, легкого и в то-же время мощного темплейтового движка (пхп).

Сорри, я не в курсе новинок PHP. Случайно не та каша из кода и дизайна подразумевается?

> это вы предлагаете, что Дизайнер должен быть верстальщиком по совместительству

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

> Просто попробуйте понять, какой прок хтмл верстальщику от кучи перловых обьектов в его шаблонах? ;) у него есть <form> и <h1> да css && jscript в придачу. Только обьектов и новых конструкция для этих обьектов ему нехватает для полного счастья. основные конструкции: IF и FOREACH. Имо, они должны быть в любом парсере шаблонов. Что значит "новых объектов"??? Для верстальщика это просто переменные, которые он может или использовать или не использовать. Какая в этом проблема? Как можно без переменных? Самое приятное, что создание Объекта происходит только в момент обращения к нему. И не нужно генерить "кучу" данных, часть из которых может и не использоваться. > Я так понял ТТ2 это заморочка под мод_перл Нет. TT2 портированный под мод_перл называется Apache::Template.

> Я так понял ТТ2 это заморочка под мод_перл, ибо видать легше извращаться в шаблонах чем писать под мод_перл нормальную программу. Одна кривость порождает другие загогулины

Нет, mod_perl - это правильная штучка. И писать под нее нормальный софт можно, если забыть о плохой читабельности любого перлового кода, отличного от "Hello, world!"