Речь идет о полной поддержке PHP5. В частности, я бы посоветовал начинать уже с всех преимуществ PHP 5.3 и использовать Zend Studio 7.1 или на крайний случай netBeans.

Добавлено @ 19:54

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

 Ой, ну что за чушь   

Это специфика PHP, все остальные веб-ориентированные языки это умеют: в них запрос обслуживает не копия приложения, а лишь отдельный поток единожды(или неск. раз) запущенного.

На сколько я знаю Zend Studio и netBeans - среды разработки (aplication development environment), а CodeIgniter - MVC framework при том достаточно легковесный.  
Чем среды разработки помогут в использовании полной мощи PHP?

Сказать честно я уже с неделю подумываю прейти на что-то IDE вроде Aptana, Zend Studio, NetBeans. Сей час пользуюсь VIM c него не ухожу потому что потратил год на работу с этим редактором.

Чем-то чую что работа с VIM смахивает в  на войну америкосов во вьетнаме. Времени потрачено уйма, по сему оступать не хочется. Но с другими системами было-бы быстрей.

Думаю что лучше весего переходить на Zend. Он случайно бесплатным не стал? 1.5 года назад он был триал 30 дневный.




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

А бизнес решение это проект средней нагрузки или система учета "бизнес-процессов" (учет времени, планирование).

 Примерно тем же, чем может помочь автомобиль при переезде из Владивостока в Мурманск: с одной стороны можно и пешком, но... долго, ненадежно и неудобно.


 PDT - его бесплатная реализация.

Прошу меня простить, я было подумал что речь идет об устаревшем редакторе. В качестве фреймворков могу посоветовать Zend и Symfony.


Дело в том, что в Zend сильно заточен на Zend Framework имеет множество полезных плагинов и расширений. Взять хотя бы модули контроля версий SVN/CVS.


К сожалению, бесплатным он не стал. Есть лишь два варианта - купить, или сами знаете - что.
А VIM не плох для быстрого редактирования/дебага в экстренных ситуациях, поскольку только всевышний знает, откуда нам может понадобиться поправить багу.



Именно. В первом случае, порой, приходится использовать нестандартные решения. От named и до патча для реализации транзакций в mecached.
В последнем случае - главное логика, скорость и удобство разработчика и пользователя.

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

Ипатьев, с ORM не работал. Но использовать подход, создавать объекты на каждый тюк - никто ведь не мешает? 

P.S. Я видел подобный подход на одном из наших проектов, но по сути, реализация его была убога.

Так автор же в первом посте описал - чем мешает.
По сути его вопроса ответов, по сути, и не было. Были только шаблонные рекомендации-заклинания - ORM, объект для работы с базой...
Меня данный вопрос тоже интересует. От ООП в пхп очень часто встречается лишь внешний вид, синтаксис. Причем большая часть техник, как совершенно справедливо автор пишет, оказывается лишней, ненужной. 
Критиков много, но за кучей слов о рефакторинге, управлении кодом и прочим теряется само понятие объекта, того самого яблока из учебника.

а его и нет, жизненный цикл у веб приложений по другому строится, не как у десктоп приложений.
Но кто сказал, что должно быть так же? Что, на asp по-другому?
А взять клиента с его js, в прототипном программировании по-другому только из-за того, что приложение дольше живет,
есть механизм событий и т.д. В php этого изначально не может быть по его природе. 
Кстати в десктоп приложении я не буду строить список объектов для всех записей, а потом вызывать метод вывода для каждого. К примеру у меня 1000 пользователей. Что, мне создавать 1000объектов для каждого? Проблемы с проектированием, но не у меня в данном случае.
 
Согласен, для любого приложения

Похоже степень очевидности у нас различается.
ООП нужно применять там, где оно в совокупности производительности и удобства (где на первом месте все-таки производитьельность) будет выигрывать. А если бытовое понимание применять везде, где вздумается...

Следовало, наверное, уточнить, что производительность имеется в виду разработки, а не кода ;)
И вот именно поэтому я в предыдущей дискуссии на эту же самую тему заметил, что вопрос "зачем ООП в РНР" стоит формулировать как  "зачем ООП программисту"...
А ответы сводятся к тому, что ООП упрощает клепание типовых сайтов на конвейере. Грустно.

очень грустно

Задача публикации этой темы определить наиболее подходящий стиль проектирования и разделения задачи на классы и объекты для web проектов.

Поделитесь опытом, приведите примеры решения практических задач из жизни в PHP c использованием наследовния и полиморфизма.  Где эти механизмы действительно органично вписываются в структуру.


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











Это сообщение отредактировал(а) Dima50 - 26.8.2009, 09:01

ООП ради ООП встречается не только в РНР, но и в других языках. А вот про недоступные в РНР техники проясните, плиз.


На это можно посмотреть и с другой стороны -- попытка запихнуть объекты в ни разу не объектную реляционную модель. Если наборы данных, с которыми вы работаете, состоят в основном из одной строки, то ORM вдруг становится намного симпатичнее.

Да, создавать, если вам нужно произвести с ними какие-то сложные действия. Например, начислить ЗП

1. Есть набор виджетов. Контент получают от удаленных сайтов. Страница собирается из конкретных виджетов, но, естественно, расчитывает на интерфейс BaseWidget. Ну и тут IZ@TOP недавно пример приводил по поводу фотолабораторий

В этой ветки примера про фотолабораторию не нашел.  

 Почему же?
PRADO PHP Framework
Delphi for PHP
ASP.NET в конце концов.

Те вещи, на которые вы ругаетесь, там достаточно прозрачны.


Только я бы не стал называть такую модель классической