DragonMX

s0rr0w Ну я так и думал, все сводится, в основном, к 3-м функциям пхп: ob_start, ob_get_contents и ob_end_clean. В моем варианте это было бы вроде: <? $App->BeginCapture($buffer); ?> ... <? $App->EndCapture(); ?> Но не в этом суть. Я не собираюсь принудительно конструировать велосипеды. Если бы все тоже самое было доступно в виде обычного класса, имхо, было бы больше толку. Т.е. если бы в коде выше вместо $App был $Smarty, условно говоря. Меня в основном напрягает отдельный синтаксис. Вот тут как раз есть, над чем поспорить... {assign var="MyData" value="New value"} <? $MyData = 'New value'; ?> А уж это я вообще не комментирую: $image|cat:'<td><img src="'|cat:$row.thumbnail|cat:'" /></td>'|cat:"\n" В то же время, когда общее число человек, приходящихся на некоторую задачу, переваливает за определенный предел, эффективность каждого из них в отдельности начинает падать. В принципе, этот вопрос уже ведет к флейму, так что продолжать не буду. А я и не говорил, что надо писать на ассемблере. Я говорил про то, что функции смарти написаны на пхп, поэтому использовать их можно и без иного синтаксиса, а на родном пхп прямо в шаблоне. Компиляция шаблона не требовалась бы вообще. Да. Возможно, именно этого мне и не хватает.

s0rr0w Вот это уже интересная задача. Основная загвоздка в функции capture - никогда раньше не приходилось так собирать данные, поэтому не знаю аналога в пхп. В любом случае, я бы это реализовал в виде $App->Capture() или $App->BeginCapture() ... $App->EndCapture(), больше пока сказать не могу. Сейчас, безусловно, готовое решение выглядит привлекательнее. Спасибо за пример. В остальном там все аналогично синтаксису пхп. Ну вот как-то оно похоже на создание нескольких должностей на месте одной. Может быть, я не прав. Пусть еще мысль в голове поварится, да что-нибудь надумается. Не согласен с аналогией. Мы же добавляем в смарти функции на том же пхп. Это как, если бы я для своей программы писал аддоны на ассемблере, но я-то могу их писать на том же языке. Вопросы ветвления на пхп и смарти, вроде, решаются одинаково. Проблема пока только за capture. Есть еще пара таких специфичных случаев? Можно просто отправить меня к описаниям проблемных функций, маны по смарти у меня есть. Если такого добра там много, то может оно того и стоит. Хотя даже в этом случае все можно было написать в виде пхп-библиотеки и не сочинять дополнительного синтаксиса.

s0rr0w Подразумевается, что один из них пишет на пхп, а другой на смарти? Если нет, то я не понял. Надо же! Все те же функции пхп. А смысл было городить огород, если их так же можно вызвать среди тегов? Как будто просто намерено все усложнили. Что понимается под логикой отображения? Теги {# #} среди тегов <> </>? Разницы нет, как я уже говорил. Если имеются в виду функции и модификаторы - так сложить их в отдельную папку, все равно на том же пхп написаны. Люди, есть ли простой пример, показывающий, что что-то минимум в два раза проще сделать на смарти, чем на пхп? Пока все сводится к разным синтаксисам и различным местам хранения кода. P.S.: Погодите, пока писал, появился еще один пост s0rr0w. Читаю...

Zippovich Стоп-стоп-стоп. Где я сказал, что в шаблон попадает логика? Шаблон остается шаблоном, только синтаксис смарти меняется на классический пхп, а с сайта убирается ненужный компонент. Есть ли какая-то принципиальная разница, писать {# $MyValue #} или <?=$vars['MyValue']?> ? На мой взгляд, никакой (кстати, тот же смарти прячет переменные в массив $this->_tpl_vars). Да тут мудрить-то, в принципе, нечего. Все перекочевывает на обычный пхп, а там уже разработчики пхп помудрили и обкатали. Программеру остается пару полезных функций написать и наслаждаться результатом, т.е. идти писать логику. Покажите мне такую вещь, которая удобна на смарти и не удобна на пхп.

s0rr0w Ответственности за косяки или за то, кто что делает? По косякам, вроде, одинаково все выглядит, что тут, что там. По делам - дизайнер же все равно не будет функции писать, даже на смарти. А программеру писать на пхп или на смарти - опять все в ту же сторону. Ну тут в плюс, как я понял, смарти использует некоторый стандарт шаблонизаторов, типа, еще где-то такой синтаксис используется. Может быть это и важно, но я раньше вообще с ними не работал, так что для меня это не стандарт В общем, пока не сталкивался, поэтому однозначного мнения нет. "Языками не владею" (с). Что для этого требуется? Описать набор (массив) соответствий access_type, где в зависимости от $type (индекс 1-й вложенности) на каждый $access (индекс 2-й вложенности) будет выдаваться некоторый результат? Типа такого? $types = array( 1 => array( 1 => 0) 2 => array( 1 => 1) 3 => array( 1 => 1, 2 => 2) ); Если да, то где это описывается? И есть ли тогда разница с пхп? Эти функции где описаны? Или, лучше будет спросить, на чем? Если можно, приведи пример какой-нибудь небольшой функции. Не могу ощутить, что смарти здесь в чем-то выше пхп. Функцию с тем же успехом может написать программист на пхп, а потом дать ее название дизайнеру, чтобы тот ее применил по месту. P.S.: Не буду скрывать, что я априоре как-то отрицательно настроен против смарти, но я могу просто что-то упускать из виду. Хотелось бы разобраться.

Уже несколько месяцев сопровождаю проект, написанный со Smarty. Честное слово, до сих пор не понял его преимущества. Я добился ровно того же эффекта за вечер, сделав простой класс на php для всяких авто-include'ов с проверками, а переменные расшарил через глобальный массив. В итоге я имею те же шаблоны без использования лишего lib-нечто и его языка. Плюс к этому мои шаблоны сразу проглатываются php. В том же Smarty tpl сначала переводятся в php (вы смотрели их в кэше? банальный php!), а потом уже обрабатываются php. Зачем? Если с эквивалентным синтаксисом я могу писать это на php сразу. К тому же я не теряю возможности использования любых конструкций php в любой части кода - знаю, что должно быть четкое разделение кода и дизайна, но во время дебага всякое может пригодиться. Я, по крайней мере, не лишаю себя такой возможности. Вот чем первый шаблон лучше второго? {# include file='header.tpl.php' #} Бегущая строка: {# $creeping_line #}<br> {# foreach from=$Notes item=$Note #} <p>{# $Note #}</p><br> {# /foreach #} {# include file='footer.tpl.php' #} <? global $vars; global $App; ?> <? $App->Include('header.tpl.php'); ?> Бегущая строка: <?=$vars['creeping_line']?><br> <? foreach ($vars['Notes'] as $Note) { ?> <p><?=$Note?></p><br> <? } ?> <? $App->Include('footer.tpl.php') ?> Вполне возможно, что я еще чего-то не осознал. Но пока кроме лишней либы, нового синтаксиса и запрещенного php я ничего не получил. А, и удовольствия я пока еще не получил. В чем же суть Smarty тогда?

Searcher Короткий, когда все вбито в соответствующие поля. У меня наравне с этим часто надо передавать вычисляемые данные. Не спорю, можно по onclick посчитать все нужное, засунуть в input type="hidden" и отправить post'ом, но все равно уже JS нужен. А если на сервер надо отправить массив или дерево? Может быть, я просто не знаю, как - как это отправить post'ом? Если только сериализацией, но надо писать сериализатор под JS. А что в этом плохого? Извиняюсь за избитый пример, но как еще сделать дерево с подгрузкой? Да, здесь с JS напряг, но есть и целевая аудитория - у меня в нее мобильники не входят. От ajax'а? Имхо, ничуть. По крайней мере, не больше, чем от обычного оформления страницы. Думаю, здесь важно писать в соответствии с W3C DOM и постоянно проверять сайт на 3-4-х ведущих браузерах. Всем спасибо за мнения и советы. Думаю, стоит довести идею до конца и решить задачу без post'а. Из описанных трудностей я не встретил особо ощутимых.

Veseloff Отказаться от JS я не смогу. Как минимум, он используется при воспроизведении уроков по AICC - это у них в стандартном примере даже прописано. Даже если я откажусь от JS в одном месте, он останется в других, а значит нет смысла. Кроме отключенного JS проблемы могут быть?

Veseloff Слушайте, реально чтоли до сих пор кто-то может отключать ява-скрипт? Мне кажется, такие времена уже прошли. Но даже если так, то включенный ява-скрипт будет скорее правилом этого сайта, иначе там ничего работать не будет. Дерево с динамической подгрузкой без аякса не сделаешь, а иначе там слишком много сразу грузить. Списки, которые составляются в зависимости от того, что было выбрано ранее. Есть обработка строк на ходу. Да и есть там одна часть сайта, которая идет с ява-скрипт по технологии, так сказать - про AICC если слышали. А раз ява-скрипт включен по требованию, то надо им пользоваться по-полной. Да, я замечал, что это работает. А во всех браузерах? Знаю, что Опера по-своему обрабатывает Назад - такое ощущение, что она просто показывает предыдущую страницу, а не переходит на нее. Мало ли еще фокусов в разных браузерах. s0rr0w JsHttpRequest может файлы передавать. Сам еще не пробовал, но все понятно: так же создается input типа file и в request передается сам объект input - в этом случае содержимое придет на сервер в $_FILES.

Вот задумал переделать сайт полностью без POST. Не нравится он мне тем, что кнопка Назад потом криво работает. Все, что нужно отправить, хочу отправлять аяксом через JsHttpRequest, а потом делать автопереход через windows.location (или другой эквивалентный способ). Даже аутентификацию хочу сделать так же. Пока проблем не вижу - кнопка назад будет работать, отправка получит интерактивность, JsHttpRequest в отличие от POST позволяет отправлять просты объекты и сложные массивы на сервер. Я ничего не упустил? Не хочу потом топтаться по граблям.

Тем не менее, режимы "opaque" и "transparent" спокойно друг друга сменяют, хотя и эффект проявляется после клика, но это не страшно. А почему такая проблема с режимом "window", понять не могу.

Пробовал - контент перезагружается, а это не подходит, так как он должен просто продолжать работать.

Попробую. Хотя даже если этого нет в MSDN, это еще не значит, что так нельзя сделать.

Код вставки флеш в страницу: <object id="flashobj" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="350" height="350" id="Main" align="middle"> <param name="allowScriptAccess" value="sameDomain" /> <param id="MovieParam" name="movie" value="flash.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#ffffff" /> <param name="wmode" value="opaque" /> <embed src="flash.swf" quality="high" bgcolor="#ffffff" width="350" height="350" name="Main" align="middle" allowScriptAccess="sameDomain" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" /> </object> Необходимо изменять параметр "wmode" между "opaque" и "window", где "opaque" позволяет перекрывать флеш другимим слоями, но не дает принимать флеш внешние воздействия, а "window" - обычный режим, но флеш всегда поверх всего. Обращаюсь так: flashobj.wmode = "window"; Эффекта нет - как не работали клики по флешу, так и не работают. Порядок перекрытия тоже не изменяется. Зато при изменении параметра с "opaque" на "transparent" и обратно, все работает после первого клика на флеш - фон становится прозрачным или нет. Помогите заставить переключаться между "opaque" и "window".