LINUX.ORG.RU
Новости — Open Source  

Вышел майский спецвыпуск (#3) PHP Inside


0

0

Третий номер полностью посвящен 2-й PHP-конференции,
прошедшей 14 мая в Москве.

Основные темы выпуска:
Smarty - компилируемые шаблоны
Эффективное использование MySQL
ООП в PHP: применение и эволюция
Эффективное использование XML-технологий в WEB-проектах
Почему PostrgeSQL?
Использование PEAR для ускорения разработки WEB-приложений

>>> Подробности

Обидно, что в разделе ООП в PHP не привели реализацию описанной модели. А то вот прочитав про Smarty я невольно вспомнил как мои знакомые с пеной у рта доказывали мне, что у perl непонятный синтаксис и уж для WEB куда более грамотнее использовать PHP а не perl. Так вот прочитав эти материалы я еще раз убедился, что как ни крути perl и в WEB'e в более менее крупных проектах намного удобнее PHP (о не WEB проектах я вообще молчу).

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

dyker
()
Ответ на: комментарий от dyker

дык дело привычки. однако пока я разбирал 14all.cgi - чуть не поседел. все никак у людей. если такое читаешь уже по привычки - одно дело. но это ни разу не оправдание чтоб такое учить

anonymous
()
Ответ на: комментарий от anonymous

Согласен, что в очень многих проектах (я так понял вы о MRTG), когда рисуют веб - морду на perl (cgi) грешат удобочитаемостью. Но Вас же никто не заставляет ТАК писать (хотя в приведенном вами примере я НЕ вижу никаких отличий от PHP, для меня именно такой стиль ассоциируется с PHP). Обычно в довольно крупных проектах (я о них писал в предыдущем посте), обязательно используется механизм шаблонов для разделения работы дизайнера и программиста (будь то Template Toolkit или HTML::Mason, ... добавьте по вкусу). А если еще и реализуют грамотную объектную модель (если это к месту), то вообще читаемость замечательная.

PS А что вас не устраивает в 14all.cgi? Или вас не устраивает, то что perl дает вам несколько вариантов написания одного и того же? Так это надо синтаксис изучать, чтобы в чужом стиле разбираться.

dyker
()
Ответ на: комментарий от dyker

слушайте объясните глупому зачем в пхп шаблоны ? чтоб упростить процедурный язык для дизайнера ?
хорошо у меня MVC но зачем сверху на пхп еще один кастрированый язык? зачем рисовать теплейты на смарти если можно рисовать хтмл со вставками пхп ? неужели средний дизайнер не может выучит 5 конструкций пхп и ему проще разбиратся в странном сиснтаксисе тысяч теплейт энджинов ?

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

anonymous
()
Ответ на: комментарий от hvicha

это если есть кому подготовить XML(типо "юзайте Oracle"), а если MySQL, то связка MySQL->PHP->XML->XSL рулит! конечно для решений "а-ля кошкин дом"

kavich ★
()

а можем кто скажем, почему у меня gpdf в гноме 2.6.1 (локаль cp1251) вместо текста показывает какую-то хрень ? причем левая панель с содержанием нормально читается и первая страница читается (довольно симпатичная кстати).

сколько смотрел разных pdf'ов, никогда проблем не было.

jodaka ★
()
Ответ на: комментарий от anonymous

это для php 5, точнее для того половинчатого api, который был в rc1 для 4 код ещё короче, надо только правильно собрать (php).
идея ясна?

function apply_template($buffer)
{
$php_self = $_SERVER['PATH_TRANSLATED'];

$xsl_template = str_replace('.xml', '.xsl', $php_self);

$proc = new xsltProcessor;
$dom = new domDocument;
$dom2 = new domDocument;

$dom2->loadxml($buffer);
$dom->load($xsl_template);

$proc->importStylesheet($dom);
$result_html = $proc->transformToXml($dom2);

if ($result_html)
{
return $result_html;
}
else
{
$result_html='<html><body><p>Error processing <strong>"'.$php_self.'"</strong> with template <strong>"'.$xsl_template.'"</strong> error is: <strong>"'.@xslt_error($xh).'"</strong></p></body ></html>';

return $result_html;
}
}

function start_xslt()
{
ob_start('apply_template');
}

function end_xslt()
{
ob_end_flush();
}

--
crz

anonymous
()
Ответ на: комментарий от anonymous

> зачем рисовать теплейты на смарти если можно рисовать хтмл со вставками пхп

просто это чаще "пхп со вставками хтмл"

anonymous
()
Ответ на: комментарий от dyker

> прочитав про Smarty я невольно вспомнил

Вывод неверный ;) Сделан по одному рассмотренному факту. А пример был
плохой. Для php существует несколько десятков реализаций шаблонов.
Smarty - лишь один из них, и, кстати, по своему убожество наиболее
напоминает стандартные поделия на перле ;) Изучай дальше.

> доказывали мне, что у perl непонятный синтаксис

Неверное определение. Понять можно что угодно и кого угодно.
Даже немого человека можно понять. Точнее сказать так:

1) синтаксис настолько компактен, что создаёт трудности для чтения,
эффект примерно такой же, как читать письмо, написанное
микроскопическими буквами, плюс местами зашифрованное ;)
2) сиснтаксис черезмерно вольный. А это значит, что каждый программер
привыкает писать по-своему, и поддерживать прогу в коллективе
программеров уже будет проблематично. Чужой код будет читаться далеко
не так быстро и легко, как чужой код на php.

> и уж для WEB куда более грамотнее использовать PHP а не perl.

А это верно. Встроенная в язык обработка запросов GET/POST, COOKIE,
сессий, встроенные драйвера для большинства распространённых БД.
Всё под рукой. Скорость исполнения программ дял web выше, чем у перла,
выше и безопасность за счёт встроеннызх средств контроля используемых
ресурсов, возможности запретить исполнение определённого набора
функций, режим SAFE_MODE. Писать легче, писать приятнее, поддерживать
удобнее и дешевле.

Ну, а то мнение, которое ты высказал - оно ничего не стОит ;) Что
может ценного сказать человек, только сегодня прочитавший олписание
Smarty? Для пишущих на php ценность его высказываний стремится к нулю ;)



anonymous
()
Ответ на: комментарий от anonymous

> хорошо у меня MVC но зачем сверху на пхп еще один кастрированый язык?

Во-первых языком шаблонов может быть сам php! Смысл даже не в том, чтоб
какой-то абстрактный дизайнер мог править шаблон без знания
программирования, а в упрощении поддержки приложения, и минимизации
затрат на изменения/исправления. В чётком и ожднозначном отделени кода
от блока презентации данных. Если ты это не понимаешь, то ты не понял
до конца принципы и цели MVC.

А вариантов реализации шаблонов в php великое множество. Не судите по
самой неудачной ;)

anonymous
()
Ответ на: комментарий от anonymous

> дык дело привычки. однако пока я разбирал 14all.cgi - чуть не поседел.

Обычных код, а'ля copy&paste. Скорей дело опыта.

fi

anonymous
()
Ответ на: комментарий от anonymous

> Встроенная в язык обработка запросов GET/POST, COOKIE, сессий,
Так же как и в perl.

> встроенные драйвера для большинства распространённых БД.
Вот самое больное место в php - отсутствие механизма сборки внешних модулей, только вместе со всем php. Пример, сделать rpm для Suse 8.2 с oci - вот песня!

> Скорость исполнения программ дял web выше, чем у перла,
Это лож.

От себя добавлю, проблемы работы с памятью, сильно зависет от опций к компелятору.

anonymous
()
Ответ на: комментарий от anonymous

Во-первых языком шаблонов может быть сам php! Смысл даже не в том, чтоб какой-то абстрактный дизайнер мог править шаблон без знания программирования, а в упрощении поддержки приложения, и минимизации затрат на изменения/исправления. В чётком и ожднозначном отделени кода от блока презентации данных. Если ты это не понимаешь, то ты не понял до конца принципы и цели MVC. -------------

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

anonymous
()
Ответ на: комментарий от anonymous

Синтаксис php удобнее?

возьмем первую попавшуюся строчку из примера выше: $result_html='<html><body><p>Error processing <strong>"'.$php_self.'"</strong> with template <strong>"'.$xsl_template.'"</strong> error is: <strong>"'.@xslt_error($xh).'"</strong></p></body ></html>';

В связи с чем вопрос: разве в пхп нельзя сделать $string = "text $VAR text"; ? обязательно включать каждую переменную в строку через конкатенацию? нда...

anonymous
()
Ответ на: комментарий от anonymous

И слава богу! Сколько я глючков насмотрелся из за включенных в кавычки $ переменных. То они не тянутся как переменные, то переменными становится чёрт знает что.
Пишу всегда ".$var.", берегу нервы.

anonymous
()
Ответ на: комментарий от anonymous

>Вывод неверный ;) Сделан по одному рассмотренному факту. А пример был >плохой. Для php существует несколько десятков реализаций шаблонов. >Smarty - лишь один из них, и, кстати, по своему убожество наиболее >напоминает стандартные поделия на перле ;) Изучай дальше.

Назови хотя бы одну реализацию шаблонов в php, которая может хотя бы сравнится с Template Toolkit в perl (я конечно не сомневаюсю, что ты назовешь, но скорее всего это будет наглая ложь :)

>1) синтаксис настолько компактен... Для многих людей (и для меня тоже) это огромный плюс. Это входит в идеологию и стиль языка (perl)

>2) сиснтаксис черезмерно вольный... Смотри выше. По-моему, программисты одного уровня пишут одинаково (на perl). Если ты их не понимаешь - делай выводы

>А это верно. Встроенная в язык обработка запросов GET/POST, COOKIE, >сессий, встроенные драйвера для большинства распространённых БД. >Всё под рукой. Скорость исполнения программ дял web выше, чем у >перла, >выше и безопасность за счёт встроеннызх средств контроля используемых >ресурсов, возможности запретить исполнение определённого набора >функций, режим SAFE_MODE. Писать легче, писать приятнее, поддерживать >удобнее и дешевле. Вы меня конечно извините, но такого наглого пиздежа я не слышал даже от любителей php. Особенно было бы интересно посмотреть ваши тесты по поводу сравнения скорости исполнения

>Ну, а то мнение, которое ты высказал - оно ничего не стОит ;) Что >может ценного сказать человек, только сегодня прочитавший олписание >Smarty? Для пишущих на php ценность его высказываний стремится к нулю >;) Ценность моих высказываний каждый волен определять для себя сам

dyker
()
Ответ на: комментарий от dyker

ну чего вы этот перл так защищаете. огромный респект конечно людям потрудившимся выучить его, выкручивая мозги (хотя уж лучше лисп или форт учили), но зачем же с нуля ЭТО учить? не понимаю. аргументация как у сектантов - иди с нами - у нас круче, стоит только _п_о_н_я_т_ь_ да не будь cpana-a этот перл и нах никому не нужен был бы. а потом и разводятся ламеры которые лепят перловку туда где и awk\sed-a с головой хватило бы.

anonymous
()
Ответ на: комментарий от anonymous

>> Встроенная в язык обработка запросов GET/POST, COOKIE, сессий,
> Так же как и в perl.

?? С каких пор они _встроены_? Бредим?

>> Скорость исполнения программ дял web выше, чем у перла,
>Это лож.

Это true!

anonymous
()
Ответ на: комментарий от dyker

> Для многих людей (и для меня тоже) это огромный плюс. Это входит в идеологию и стиль языка (perl)

А приходилось читать и быстро править чужой код?

> По-моему, программисты одного уровня пишут одинаково (на perl).

Ага, щас. Один любит писать if !, другой unless, один пишет
$a="b" if $b="a", а другой if($b="a"){ $a="b"} и т.д., и т.п. Это самые
простейшие примеры.

> Особенно было бы интересно посмотреть ваши тесты по поводу сравнения скорости исполнения

Делал. Давно правда. Сейчас нет ни времени, ни желания. Но хотя бы чисто
теоретически, согласимся, что встроенная обработка post/get запросов,
написанная на Си просто обязана работать быстрее, чем тормозной CGI.pm.
То же самое с драйверами БД. Что можно привести в опровержение этой
теории. Я ленивый, но если теория будет квалифицированно опровергнута,
я не поленюсь проделать вновь тесты на скорость.

anonymous
()
Ответ на: комментарий от anonymous

> Ага, щас. Один любит писать if !, другой unless, один пишет $a="b" if $b="a", а другой if($b="a"){ $a="b"} и т.д., и т.п. Это самые простейшие примеры.

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

> Но хотя бы чисто теоретически, согласимся, что встроенная обработка post/get запросов, написанная на Си просто обязана работать быстрее, чем тормозной CGI.pm.

Аналог grep, написанный на perl, делал по скорости реализации grep, написанные на Си (кроме GNU grep). Вот вам и теория.

anonymous
()
Ответ на: комментарий от anonymous

> Люди, которые обращают внимание на подобные мелочи, не являются программистами.

То же самое я думаю о людях, которые допускают наличие таких "мелочей"
в крупных проектах.

> Аналог grep, написанный на perl, делал по скорости реализации grep

Это не аргумент, так нет данных о полноте реализации того перлового
grep'a. К тому же, это уход от темы и от вопроса. Принимаются только
аргументированные доводы, желательно с бенчмарками. Profile, don't
speculate!

anonymous
()
Ответ на: комментарий от anonymous

ситуация из жизни. какая-то программа подправила реестр на юзерской тачке и та стала запрашивать все картинки статистики генерируемые 14all.cgi одновременно. на каждую получается загружался интерпретатор. более 7 экземпляров запущенных одновременно погружали сервер в коматоз. запуск вручную дал результат ~1.5 секунды на обработку скрипта. было принято решение вызывать rrdgraph вручную из php. результат - 0.4 секунды на одно изображение. тормоза полностью исчезли. вот вам и скорость перла.

anonymous
()
Ответ на: комментарий от anonymous

Языки программирования, как разговорные языки: если все ваше знания языка основывается на общении с 10 одноклассниками/сокурсниками (например, при изучении английского в школе), то вам будет очень сложно разговаривать с человеком, который знает язык ... ну если не в совершенстве, то по крайней мере свободно....

А когда знаешь язык, то уже начинаешь ценить стиль речи, красоту и изящество оборотов. Тогда и получаешь удовольствие от использования языка.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Open Source