Цитата(MuToGeN @ 5.12.2003, 01:38)

Если уж говорить о шаблонизаторах, то уже давно пользую вариант с апачевыми AddHandler и Action, когда фаил с определенным расширением передается на обработку PHP скрипту. В итоге имеем полностью прозрачный шаблонизатор + сессинный движок + инклюд всех необходимых функций + все необходимые заголовки

У меня была такая идея.
Сделать сайт на XML
индексами дирикторий сделать XML файлы, и передавать их имена на обработку PHP скрипту, который будет подставлять нужный файл под xsl шаблон!

но в связи с моим опытом работы с xml идея благополучно отправлена в to do

Не... У меня без xml и xsl, просто текстовые фаилы.
Еще когда-то что-то типа этого мастерил с mod_rewrite

Master

Цитата

смотриш на скрипты и не вериш, как же я мог такую охиней понаписать

Цитата

да уж, PHP тем и хорош, что одну и ту же задачу, через месяц решает легче и изящнее раз в 5, и думаешь: шож я дурак раньше такой бред понаписалто, когда тут раз и два! ;))

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

Цитата(Master @ 4.12.2003, 17:39)

akul а что в ?view=guestbook нехорошего. При чем здесь умение или не умение? у меня полным полно страниц и разделов на таких вот элементах.

чем плохи сами урли такого вида сами по себе, писано-переписано, начиная с трудолюбивого Лебедева и кончая сотней форумов. А для меня это просто показатель, что используется плохой (дыры, которые _надо затыкать_) и ненадежный (надо вручную таскать параметры через URL) принцип. Кстати, туда же - файлы .inc (тоже кто-то советовал..). Достаточно десяти минут, чтобы найти в инете кучку сайтов, базу которых можно вскрыть только потому, что у них файлы .inc называются. Т.е. если кто-то называет файлы .inc - я вижу, что человек ещё чайник. Естественно, надо запретить это в апаче, вынести за корень.... но это все - затыкание дыры, которую мы сами создали, когда надо было сразу .inc.php. Надеюсь, объяснил.

Цитата

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

Тут важно понять, что делить надо не "дизайн от программы", а декларативные и процедурные описания. Это в общем. Шаблоны в общем случае эту задачу не решают и решить не могут. Но то, что они делают, прекрасно делает тот же include "кусок дизайна.html" в нужном месте метода класса компонента.
А имя переменной {в фигурных скобках} ничем не лучше <?=таких скобок?> с точки зрения понятности дизайнеру. А хуже тем, что добавляет совершенно лишний промежуточный слой с дополнительными глюками и тормозами.
И заметьте - когда верстальщику "станет мало" и раз уж он взялся изучать процедурные конструкции, ничто не мешает ему сразу изучить <? for(...) ?> вместо доморощенных шаблонных аналогов со своим синтаксисом.

Цитата

А если верстальщик (или дизайнер) ведет сайт через веб-интерфейс? Давать ему доступ к самому сокровенному??

Давать ему доступ к частям дизайна, включаемым внужных местах. Всё это делается в рамках ООП. Иллюстрация самого простого способа :

<? require_once 'page.class.php';

class SitePage extends Page
{
function PrintHeader($args){?>

дизайн-дизайн-дизайн

<?}
function PrintFooter($args){?>

дизайн-дизайн-дизайн

<?}}?>

Цитата

чем плохи сами урли такого вида сами по себе, писано-переписано, начиная с трудолюбивого Лебедева и кончая сотней форумов. А для меня это просто показатель, что используется плохой (дыры, которые _надо затыкать_) и ненадежный (надо вручную таскать параметры через URL) принцип. Кстати, туда же - файлы .inc (тоже кто-то советовал..).

Чем же это он такой плохой и ненадежный, можно узнать?:?

Ясное дело, что файлы называются:
my_file.class.php
или
my_file.inc.php

Минус ООП - дольше работает

Цитата(Secandr @ 5.12.2003, 16:44)

Ясное дело, что файлы называются: my_file.class.php или my_file.inc.php Минус ООП - дольше работает

ну, что касается PHP - может быть.. В общем случае неверно, всё как раз наоборот. Компилятор, имея куда больше информации о данных, можут гораздо лучше оптимизировать код. Оверхед обычно возникает оттого, что с использованием ООП мы можем делать вещи, о которых без оного только мечтали, сооответственно типична стельба из пушки по воробьям. Но это не свойство ООП, а особенность психологии. Это о компьютере. Что касается программиста, то ООП не просто ускоряет, а кардинально ускоряет работу.

Цитата(Dr @ 5.12.2003, 15:52)

Чем же это он такой плохой и ненадежный, можно узнать?:?

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

Цитата

akul> ненадежный(надо вручную таскать параметры через URL)

Я что-то не понимаю, ненадежность - это значит, что не надо параметры вручную через URL таскать?
P.S.

Цитата

чем плохи сами урли такого вида сами по себе, писано-переписано, начиная с трудолюбивого Лебедева и кончая сотней форумов

Кинь ссылку, я хочу просветиться.

Цитата

Давать ему доступ к частям дизайна, включаемым внужных местах. Всё это делается в рамках ООП. Иллюстрация самого простого способа : <? require_once 'page.class.php'; class SitePage extends Page { function PrintHeader($args){?> дизайн-дизайн-дизайн <?} function PrintFooter($args){?> дизайн-дизайн-дизайн <?}}?>

Не-ет, это же значит сунуть голову в микроволновку!
Так мы дадим возможность любому человеку, с доступом к админовской странице, сделать всё что угодно - начиная от закачки произвольного файла на наш сервер, заканчивая установкой скрипта-фильтра всех входящих и исходящих GET/POST -- что например для магазина равносильно смертному приговору с судебными разбирательствами.

Чем хорош "слоёный пирог" из Smarty/ООП - это тем, что каждый слой занимается только своим делом, и не имеет доступа к базовым функциям другого слоя. Так, наш дизайнер никогда не сможет сделать ни шага влево, ни шага вправо от HTML/TPL (не дадим мы ему PHP, и всё тут), и вместе с тем у него в руках будет вся мощь языка PHP, спрятанная на более низком слое/уровне (где работает программер). Вот в чем соль template-подхода.

akul>> в том и дело. PHP - не компилятор
И ООП в нём реализовано не лучшим образом. Насколько я помню историю пхп, он первоночально создавался без поддержки ооп, затем ооп притянули за уши к пхп.

Цитата(Dr @ 5.12.2003, 17:40)

Кинь ссылку, я хочу просветиться.

статьи, хорошие своей популярностью:
http://spectator.ru/technology/php/easy_templates
http://spectator.ru/technology/php/user_friendly_urls

Цитата(mr @ 5.12.2003, 22:00)

Не-ет, это же значит сунуть голову в микроволновку! Так мы дадим возможность любому человеку, с доступом к админовской странице, сделать всё что угодно - начиная от закачки произвольного файла на наш сервер, заканчивая установкой скрипта-фильтра всех входящих и исходящих GET/POST -- что например для магазина равносильно смертному приговору с судебными разбирательствами. Чем хорош "слоёный пирог" из Smarty/ООП - это тем, что каждый слой занимается только своим делом, и не имеет доступа к базовым функциям другого слоя. Так, наш дизайнер никогда не сможет сделать ни шага влево, ни шага вправо от HTML/TPL (не дадим мы ему PHP, и всё тут), и вместе с тем у него в руках будет вся мощь языка PHP, спрятанная на более низком слое/уровне (где работает программер). Вот в чем соль template-подхода.

Прежде всего нам надо хорошо подумать, что и от кого мы защищаем. Итак, чайник дизайнер, не способный запрограммировать цикл, у нас превратился в злобного хакера, способного обойти safe mode и нафигачить нам гадостей на сайте. Ну что тут сказать? 1. Уверяю тебя, что шаблоны не являются панацеей от этого, и "вся мощь PHP" в руках дизайнера и "безопасность сайта" - вещи взаимоисключающие, сколько бы там слоев не прокладывали. 2. Приведённый кусок - только иллюстрация, где я не рассматривал вопросы защиты сайта от кого-бы-то-ни-было. Вопросы защиты в простейшем случае "разрешаем ему в дизайн переменные вставлять" решаются одним оператором типа:

if(preg_match("/<"."\\?[^=]/",$template)) trigger_error("Обломись!",E_USER_ERROR);
(Обращаю внимание, что это тоже _иллюстрация_. Это обходится, но я не собираюсь тут "Enterpise ready" движок сайта эпистолярничать. Я только показываю направление.)

akul ну ты прям у нас белая ворона...
Во первых я не понимаю.... как ты будеш искать дыры в скриптах для работы которых требуются GET параметры...
также для меня загадка где Лебедев про такое писал.