Очень хорошая статья о проблемах PHP...

Все, что там описано, имеет место быть.К сожалению это факт.
Это первая статья, за последние года 2-3, без шапкозакидательства, а с грамотным анализом.

Не соглашусь с автором в том, что PHP не пригоден для крупных проектов. Все зависит от умения программировать.
Не соглашусь и с цитатой, что PHP прогеры деградируют... Нет. Рано или поздно переходят на другой уровень, Си, C#.

Security specialist leaves PHP security team — Report of 13.12.2006 21:57



Эксперт по безопасности покидает команду PHP. Патчи для контроля почты — 14.12.2006 22:12

SergeCpp, это я еще тут в новостях давал...
Тут любопытно привести еще одну цитату:

http://phpclub.ru/talk/showthread.php?post...6365#post676365



При этом, хочу отметить, что автор этих строк не последний человек в PHP сообществе.

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



Так и PEAR же придумали уже. Поддерживает постгрес, майскл, мс скл

А еще есть PDO
И потом это по сути (PEAR) - пользовательские библиотеки, а речь идет о core & ext


Какое отношение Smarty имеет к framework'у?

По ссылке есть пара интересных замечаний, в частности по поводу именования функций и вообще их большого количества. Но в оценках прослеживается явный субъективизм...Автор просто не знает о многих вещах.

Автор не указал на платформозависимость многих нативных функций PHP, а также отсутствие всякой логики (зачастую просто мэпят C'шные функции в пространство PHP).

Мне реально не хватает пакетов/неймспейсов, некого общего фреймворка (PEAR вешь хорошая, но не всё) и "декларативности" языка (closure, конструкции для работы со списками, match etc). PHP5 как язык ещё не плох, но стандартная либа для него явно не подходит. Но! пишем, в умелых руках и х. отвёртка 

Сейчас складываю свои общие часто используемые компоненты сюда, по идее может получиться ещё один фреймворк под 5'ку.

Sardar, 

Уверены, что не получите ещё один велосипед? Есть вполне приличные фреймворки. Тот же CakePHP.

Посмотрим. В любом случае я не фанатичен и не бросаюсь переписывать что уже есть. Во фреймворке сейчас именно то, что я не видел в других (даже в Zend Framework) или видел, но "криво".

Можно поподробнее?

Secandr на днях ссылку подкинул: http://www.onphp.ru/index.ru.html

Mal Hack, спасибо! Почитаю.

Будет оффтопом 

Ну хотя бы просто конфиги по всей системе. Компоненты не должны конфигурироваться в коде (define и прочее). Также компонент не должен иметь каких либо .setParam(), т.к. использующий его код не должен знать какие настройки он по дефолту имеет. Я написал Configuration класс, с по мощью которого любой компонент в системе может сам себя сконфигурировать (дефолтовых значений в код тоже не вшиваеться).

К примеру такой код:


Построит страницу, запишет в кешь и выдаст из кеша при последующем запросе. На первый взгляд просто, но если же углубимся в код то заметим:

• определиться локаль пользователя на основе Accept-language и других источников (locale.php, Localization.php)
• допустим шаблоны лежат в /templates, текущий скин 'default', тогда путь до шаблона будет: /templates/default/ru/my/ru_RU.template.tpl. Естественно поиск локализованного ресурса дотаточно умён что бы выдать в любой подходящей локали (единый язык) или упасть на не локализованный шаблон (дефолтный).
• по дефолту шаблонизатор компилируемый/транслирующий (CompiledTemplateDocument), допустим ложит он собранные PHP инклюды в /data/compiled_templates/...
• кешь тоже знает свои пути и допустим ложит контент в: /data/cache/static/pages/some.page.cache

Все пути и настройки не зашиты в коде, а беруться у Configuration, который читает опции по первому требованию из /data/config/*.props файлов (XML). Все конфиги прописаны в начале кажого файла, глянь на "[template]dir:source-base-dir" и подобные строки.

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

Это только о конфиге, а если о шаблонизаторе поговорим?   Штука мощная, не псевдо-PHP как Smarty и подобные, но в то же время простой text-stream, что удобней для генерации страниц чем XML+XSLT (IMHO). Не имеет встроенных конструкций (только теги и блоки), расширяем и на мой взгляд довольно удобен.

Модератор: извиняюсь 
Если кому интересно, спрашивайте/пишите здесь.

Я попозже тему разделю на "Проблемы PHP" и "PHP Framework", если никто не против.