я уже давно с успехом использую http://www.princexml.com/doc/6.0/
отличная библиотека, имеет интерфейс к многим популярным языкам, в том числе php. конвертирует (x)html в pdf с поддержкой css. работает как с utf-8, так и с windows-1251 (вдруг кому нужно). короче говоря я свой выбор сделал.
Платформа: winXP, Apache/2.2.4 (Win32), PHP/5.2.4
результаты тестирования можно увидеть на скриншоте →
Также пришлось переводить не один проект с win2003/iis/php4(php5) на linux. В процессе перехода сполна ощутил разницу в системах.
Возможно условия тестирования не вполне объективны? Мне уже самому интересно — неужели на win-платформах прямой слеш (/) не проходит когда-то.
да и вобще. стоит взять документацию по какому-нибудь фреймворку (zend подойдет например) — возможно там вы найдете ответы на все интересующие вас вопросы (даже если потом не будете этот фреймворк использовать).
Интересный вопрос. На сколько я знаю однозначного ответа на него нет.
Есть несколько подходов к решению.
Ну во-первых, если четко придерживаться MVC то все данные для формирования хедеров, меню и подобных повторяющихся блоков нужно формировать в контролерах и передавать в шаблоны в виде готовых к «употреблению» массивов.
с другой стороны, на мой взгляд, у этого подхода есть один минус — в каждом контролере придется повторять одну и туже рутинную операцию. Конечно ее можно свести к минимуму, но все же.
есть еще способ — использование так называемых плагинов (виджетов, хелперов) в шаблонах. Тогда мы немного отступаем от стандарта MVC и схема работы сайта получается такой:
запрос → контроллер → модель → контроллер → шаблон → плагин → модель → плагин → шаблон.
соответственно плагин это некий контролер, вызываемый из шаблона. он автономен, но при этом знает все о запросе и может корректировать свою работу в зависимости от параметров запроса. например если плагин отвечает за рендеринг меню он может в зависимости от запроса подсвечивать текущий раздел. и так далее.
это решение, которое использую я. Есть конечно еще варианты, например еще больше изменить архитектуру MVC, чтобы процесс выглядел примерно так:
запрос → контроллер → шаблон → плагин → модель → плагин → шаблон.
→ плагин → модель → плагин →
→ плагин → модель → плагин →
т.е. единственная роль контролера — вызов шаблона. а уже в шаблоне вызываются плагины, которые рендерят контент в вставляют его в сетку шаблона. тогда шаблон собирается как бы из кубиков, а каждый кубик автономен.
Я не открыл что-то новое, есть довольно большое количество литературы, описывающей тот или иной подход. Стоит рассмотреть несколько вариантов, а потом сделать вывод какой из них наиболее подходит для решения ваших задач. Ну или имплементировать лучшие стороны каждого и (на свой страх и риск) написать свою схему построения приложения. Выбор за вами.
ps: все сказанное является отражением моей точки зрения на проблему, и не есть руководство к действию. Всегда открыт для конструктивных замечаний :)
Наверное правильно было бы написать: «Используете ли вы множественную имплементацию интерфейсов в PHP?». Тогда небыло бы лишних вариантов. Хотя с другой стороны вопрос на засыпку, так сказать :).
в качестве $hyp можно использовать ­ — символ мягкого переноса. Правда говорят что этот символ не всегда корректно работает. У меня firefox 3b4 под Mac OS — в нем все работает правильно.
у кого есть время и желание проводят объективные (по их мнению) обзоры, сравнивают, приводят доводы, перечни, +, -. ссылок на подобные вещи можно найти в достаточном количестве.
другие же просто делают свой вывод. и вывод этот не всегда «IE - дерьмо».
Вот-вот. Наиболее яростные и непримиримые борцы против ie — разработчики. Т. к. только они могут в полной мере оценить все преимущества и недостатки того или иного броузера. «Простые» пользователи предъявляют (или не предъявляют вовсе?) несколько другие требования. Кому какое дело насколько тяжело программистам? В конце концов это их работа. И почему это должно быть всеобщей проблемой? Разве что из солидарности...
PS: я очень часто использую ie. приходится постоянно пополнять файлы ie_fix.css, т.к. истории про стандарты не помогут сдать мне проект вовремя.
Есть задача. Есть средство, решающее задачу. Результат полностью удовлетворяет? — отлично!
Выбор каждого — искать аналоги в надежде получить что-то лучшее или пользоваться тем, чего и так вполне достаточно.
Единственно верного решения нет. Относительность, мать её ;)
да. это уже способ реализации. я думаю что в данном конкретном случае Strategy, а значит и классы-реализации стратегии излишни. хотя все зависит от обстоятельств конечно. кстати, раз речь о патернах: как можно назвать патерн, который реализует Zend_Feed? Декоратор, агрегатор... не силен в теории.
Чем rss отличается от обычной html ленты постов? По-моему, только способом представления данных, т.е. шаблоном. Получается что для отдельного вида шаблонов (RSS) мы создаем новую сущность (объект, класс) и тем самым плодим их (сущности).
На мой взлад для создания rss ленты нам нужно две вещи: массив данных и xml-шаблон для их вывода. Зачем объекту юзер думать о том, в каком виде (шаблоне) его данные будут выводиться, зачем ему вообще о шаблонах знать что-то?
Другое дело что подготовка массива данных для вывода в xml-шаблоне довольно рутинная операция: нужно привести массив к определенному стандартному виду (например к полям типа title, description, date, url и т.д.). И для этого возможно понадобиться класс, который эту рутину будет максимально просто выполнять. Для примера можно посмотреть Zend_Feed, который именно этим и занимается.
А добавлять логику работы с rss в $user или $blog и прочие объекты, на мой взгляд, не стоит.
имхо разумеется)
в чем то вы правы.
Однако при увеличении количества блогов и топиков операция удаления всех топиков пользователя происходила бы путем перебора всех блогов юзера и последовательным вызовом $blog->clearAllTopics();
Притом возможность работы напрямую со всеми топиками юзера непременно может понадобиться (например для создания rss ленты юзера), и тогда удобно будет использовать $user->getAllTopics() ну или в дальнейшем $user->getAllComments();
В любом случае связь между объектами Blog, User и Topics очень тесная и совсем отделить их друг от друга не получиться (да и нужно ли?).
коллекция топиков чересчур абстрактная сущность. $blog->clearAllTopics() — значительно более прозрачное действие удаления всех топиков блога (хотябы явно видно что удаляються топики конкретного блога).
ну и соответственно $user->clearAllTopics();
по крайней мере я всегда делаю так, но было бы интересно подискутировать на эту тему).
все замечательно, единственное я бы заменил
echo $user->getBlog()->getTopics()->topic[$topic_id]->message;
на
echo $user->getBlog()->getTopic($topic_id)->message;
дабы не создавать класс, представляющий из себя массив топиков.
да и разруливать ситуацию, когда запрашивается отсутствующий топик так гораздо проще.
а в целом объекты — наше все.
отличная библиотека, имеет интерфейс к многим популярным языкам, в том числе php. конвертирует (x)html в pdf с поддержкой css. работает как с utf-8, так и с windows-1251 (вдруг кому нужно). короче говоря я свой выбор сделал.
результаты тестирования можно увидеть на скриншоте →
Также пришлось переводить не один проект с win2003/iis/php4(php5) на linux. В процессе перехода сполна ощутил разницу в системах.
Возможно условия тестирования не вполне объективны? Мне уже самому интересно — неужели на win-платформах прямой слеш (/) не проходит когда-то.
Есть несколько подходов к решению.
Ну во-первых, если четко придерживаться MVC то все данные для формирования хедеров, меню и подобных повторяющихся блоков нужно формировать в контролерах и передавать в шаблоны в виде готовых к «употреблению» массивов.
с другой стороны, на мой взгляд, у этого подхода есть один минус — в каждом контролере придется повторять одну и туже рутинную операцию. Конечно ее можно свести к минимуму, но все же.
есть еще способ — использование так называемых плагинов (виджетов, хелперов) в шаблонах. Тогда мы немного отступаем от стандарта MVC и схема работы сайта получается такой:
запрос → контроллер → модель → контроллер → шаблон → плагин → модель → плагин → шаблон.
соответственно плагин это некий контролер, вызываемый из шаблона. он автономен, но при этом знает все о запросе и может корректировать свою работу в зависимости от параметров запроса. например если плагин отвечает за рендеринг меню он может в зависимости от запроса подсвечивать текущий раздел. и так далее.
это решение, которое использую я. Есть конечно еще варианты, например еще больше изменить архитектуру MVC, чтобы процесс выглядел примерно так:
запрос → контроллер → шаблон → плагин → модель → плагин → шаблон.
→ плагин → модель → плагин →
→ плагин → модель → плагин →
т.е. единственная роль контролера — вызов шаблона. а уже в шаблоне вызываются плагины, которые рендерят контент в вставляют его в сетку шаблона. тогда шаблон собирается как бы из кубиков, а каждый кубик автономен.
Я не открыл что-то новое, есть довольно большое количество литературы, описывающей тот или иной подход. Стоит рассмотреть несколько вариантов, а потом сделать вывод какой из них наиболее подходит для решения ваших задач. Ну или имплементировать лучшие стороны каждого и (на свой страх и риск) написать свою схему построения приложения. Выбор за вами.
ps: все сказанное является отражением моей точки зрения на проблему, и не есть руководство к действию. Всегда открыт для конструктивных замечаний :)
function smarty_modifier_splitword($string, $wordmaxlen = 50, $hyp = " ")
{
return preg_replace('/([^\s]{' . intval($wordmaxlen) .'})+/U', '$1' . $hyp, $string);
}
в качестве $hyp можно использовать ­ — символ мягкого переноса. Правда говорят что этот символ не всегда корректно работает. У меня firefox 3b4 под Mac OS — в нем все работает правильно.
другие же просто делают свой вывод. и вывод этот не всегда «IE - дерьмо».
К чертям политкорректность.
IE — дерьмо, ездите на Audi! Только другим об это не говорите, а то мало ли...
PS: я очень часто использую ie. приходится постоянно пополнять файлы ie_fix.css, т.к. истории про стандарты не помогут сдать мне проект вовремя.
Выбор каждого — искать аналоги в надежде получить что-то лучшее или пользоваться тем, чего и так вполне достаточно.
Единственно верного решения нет. Относительность, мать её ;)
На мой взлад для создания rss ленты нам нужно две вещи: массив данных и xml-шаблон для их вывода. Зачем объекту юзер думать о том, в каком виде (шаблоне) его данные будут выводиться, зачем ему вообще о шаблонах знать что-то?
Другое дело что подготовка массива данных для вывода в xml-шаблоне довольно рутинная операция: нужно привести массив к определенному стандартному виду (например к полям типа title, description, date, url и т.д.). И для этого возможно понадобиться класс, который эту рутину будет максимально просто выполнять. Для примера можно посмотреть Zend_Feed, который именно этим и занимается.
А добавлять логику работы с rss в $user или $blog и прочие объекты, на мой взгляд, не стоит.
имхо разумеется)
Однако при увеличении количества блогов и топиков операция удаления всех топиков пользователя происходила бы путем перебора всех блогов юзера и последовательным вызовом $blog->clearAllTopics();
Притом возможность работы напрямую со всеми топиками юзера непременно может понадобиться (например для создания rss ленты юзера), и тогда удобно будет использовать $user->getAllTopics() ну или в дальнейшем $user->getAllComments();
В любом случае связь между объектами Blog, User и Topics очень тесная и совсем отделить их друг от друга не получиться (да и нужно ли?).
ну и соответственно $user->clearAllTopics();
по крайней мере я всегда делаю так, но было бы интересно подискутировать на эту тему).
echo $user->getBlog()->getTopics()->topic[$topic_id]->message;
на
echo $user->getBlog()->getTopic($topic_id)->message;
дабы не создавать класс, представляющий из себя массив топиков.
да и разруливать ситуацию, когда запрашивается отсутствующий топик так гораздо проще.
а в целом объекты — наше все.