Цитата

19 октября 2005 года компания Zend Technologies объявила об инициативе по созданию открытой среды разработки и развертывания PHP-приложений, которая де-факто станет промышленным стандартом для PHP-разработчиков в скором будущем. Предполагаемая среда разработки и развертывания PHP-приложений будет интегрирована в проект Eclipse - открытую платформу для разработки программного обеспечения, близкую к компании IBM. При этом предполагается создать не просто Zend Studio на платформе Eclipse, а создать так же Zend PHP Framework - фреймворк, который будет стандартом для разработки PHP-приложений будущего и позволит разработчикам фокусироваться на уникальном для их приложений функционале и уделять миниммум внимания задачам, общим для большинства приложений. В союзе с новой IDE на базе Eclipse, такой проект будет представлять некоторого рода аналог MS Visual Studio и ASP.Net. Уже сейчас к проекту присоеденились такие компании как: IBM, Oracle, MySQL, Intel и множество других известных компаний. Насколько это понятно из официального FAQ, компания Zend прекратит дальнейший выпуск Zend Studio (но не поддержку) и сконцентрирует усилия на PHP Collaboration Project. Компания считает, что для ее клиентов переход на Eclipse будет только полезен, так как помимо стандартной платформы для разработки, они смогут получить расширяемое API и большое количество сторонних модулей. Обсуждения этой темы можно найти на сайтах: phpclub.ru (на русском языке) и sitepoint.com (на английском). http://phpinside.ru/?q=node/220

Может тоже кто что слышал, что знает, очень интерестно?
Интерестно услышать что-нибудь, что нет на этих двух форумах )))

Интересная тема. Надо будет разузнать.

Это очень классно! Означает, что PHP не умрет!

А можно не знающему пояснить что такое фрэймворк и что зенд решил сделать?

Это сообщение отредактировал(а) Mal Hack - 16.1.2006, 19:21

Это что то вроде коллекции классов как у MS в его Framework'e. Видимо решили своими руками написать то что мы пишем постоянно. Мне кажется что в РНР немного нехватает втроенной объектной ориентированности. Возможно они решили создать свою библиотеку классов для всеобщего счастья

Т.е. что-то вроде PDO, но под графику, текст и т.п.?

Mal Hack, это мое предположение. Я бы именно так и сделал на их месте, потому что если взять любые другие языки, они предоставляют очень большие возможности как по работе с ООП, так и по бибиотекам которые можно использовать, в РНР в данный момент мне кажется это не доработано, но к этому они и стремятся, эб этом можно догадаться если посмотреть на более мощьную ООП в 5 -ке.
Но как говорится, это ИМХО.

Если бы это всё хозяйство было в нативном виде(extension php) + исходники(php) былобы вообще замечательно... Если это всё ещё и объеденить с Parrot, то было бы очень удобненько...

Компании, учавствующие в разработке

• 100days.de
• bebe.com
• IBM
• JamboWorks
• Ning
• OmniTI
• php|architect
• StepUp Commerce
• SugarCRM
• Zend

С чем( надеюсь) ?))

Parrot virtual machine
Объеденяет perl/python/ruby

http://simpletest.sourceforge.net/ - Simple Test PHP Unit Test Framework
Тоже интерестный проект...

Да этих фреймворков на PHP полным-полно ... Только ни одного стоящего для PHP нет пока. Будем ждать сабжа.

Для чего нужно? В действительности сейчас на PHP пишут так, как могут. А с использованием фреймворка разработка веб-приложений будет "стандартизована".

Еще ссылка: http://www.zend.com/collaboration/framework_overview

Не знаю почему, но Zend всегда рулил и сейчас рулит По-моему даже сертификат от Zend самый важный для PHP-программиста

Смотрим МАН
Качаем ТУТ
Добавлено @ 10:24
ЗЫ Если кто найдёт где скачать IDE под eclipse буду очень признателен за сцыллку )))
Добавлено @ 10:26
А тут уже примеры появились )))

AntonioBanderaz, спасибо за инфу. Сейчас посмотрим и заценим

Ну что, с начала обсуждения сабжа прошло не мало времени, недавно вышла новая версия фрэймворка:
Zend Framework 1.0.0 Release Candidate 2  (2007-06-07)
качать здесь: http://framework.zend.com/download

У кого какое мнение по этому фрэймворку, кто уже использует его в своих проектах, поделитесь опытом...
Сейчас вот как раз занимаюсь выбором фрэймворка и выбор пока что пал на этот.

Имхо, самый перспективный фреймворк среди всех имеющихся на данный момент. Отмечу, что в нем понравилось:
1. Написан полностью под 5ый PHP и все вытекающие от сюда плюсы. ООП, Exception-ы итд.
2. Хороший стиль. HEREDOC-и грамотные и есть у всех классов/методов. Хотя встречаются случаи, где Zend Studio не может понять, что возвращает метод Zend Framework-а 
3. Очень грамотная обработка исключений. Никаких trigger_error(), die() и пр. 
4. Достаточно хорошо реализовано кэширование.
5. MVC реализован достойно, что не сказал бы про другие популярные фреймворки.
6. Сам по себе фреймворк очень гибкий, предельно просто расширить любую его функциональность не затрагивая сам движок.
Имхо, минусы:
1. Тормазнутый (в частности MVC).
2. Еще сыроват.
3. MVC... Хотелось бы что-нибудь оригинальнее...
4. Хотелось бы видеть также инструментарий для AJAX, но увы им там и не пахнет.
5. Loader классов кривой...

Это сообщение отредактировал(а) sTa1kEr - 17.6.2007, 18:19

В общем со всеми плюсами согласен, вот по минусам хотелось бы уточнение, я просто только начинаю использовать его, хочется знать все подводные камни:

С реализацией MVC в ZF почти разобрался, что именно Вы считаете тормознутостью в ней?


а что именно в нём криво?

Производительность с другими фреймворками я не сравнивал, но общее впечатление при работе с контроллерами мне показалось очень медленным. В принципе этот пункт можно было объединить с 3им пунктом.
Не нравится мне, что в *скриптовом* фреймворке так расточительно используется ресурсы сервера. При каждом клике диспетчер проводит достаточно большую и, имхо, бесполезную обработку всех контроллеров, плагинов, хелперов итп. К примеру, в ASP.NET-е это не было бы критично, т.к. ASP.NET, в отличии от PHP, это веб приложение, которое запущенно постоянно и которому не требуется каждый раз обрабатывать весь исходный код перед началом работы основных скриптов. Но для PHP это, имхо, не правильно.

Дело в том, что вся логика подгрузки классов основана на относительных путях. Еще ладно, если бы относительно той папки в которой лежат сами скрипты, но они загружаются относительно include_path ! (примерно также, как и в PEAR-е). Из-за этого были проблемы, да и не люблю я зависеть от подобных настроек PHP. При изучении этого фреймворка, я первым делом комментарил все инклюды и методы Loader-а и загружал все необходимые классы своей функцией.

Ну в общем это легко решается с помощью функции set_include_path(), как я уже успел разобраться, в дальнейшем я просто регистрирую авто загрузчик классов - Zend_Loader::registerAutoload(). В принципе пока на проблемы не натыкался, т.к. часто использую spl autoload.



Вот с этим ещё не успел разобраться полностью, ну думаю эту проблему можно решить с помощью кэширования.

Какая разница, что set_include_path(), что прописать путь в php.ini. То что на этом завязан Loader, меня не устраивает, т.к. я использую другую логику (я тоже использую autoload, только свой), а исправить можно только в самом коде. В общем это мое имхо.

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

mvc того стоит. если она не нужна ее можно просто не использовать, там и без того есть на что посмотреть. различные части ЗФ мало зависят друг от друга.

ну вобще-то вполне естественно что каждый клик -> это http-request. проход идет далеко не по всем контроллерам и тем более плагинам и хелперам. ЗФ писали те, кто больше других знают как оптимизировать пхп-код ;) 


уже был 1.0.0 релиз


а что, есть что-нибудь лучше MVC ??  


вобще-то это PHP-фреймворк, а не JS )) ZF предоставляет все необходимое для организации серверной части AJAX-приложений на пхп. например класс для работы с JSON. а к клиентской части пхп не причем, можно успешно юзать например prototypejs вместе с ЗФ



зенды руководствовались простым правилом - библиотеки классов должны располагаться в папке для библиотек )) если на сервере 100 сайтов используют ZF и у каждого в папке своя копия ЗФ - это тупо, лучше просто сложить в инклуд - он для этого и нужен. да и тем более никто не мешает использовать одновременно оба подхода загрузки.

з.ы. если сравнивать ZF с аналогичным продуктом, то имхо корректнее всего сравнивать с Rails (для Ruby) или с Django (для Python) -- потому что именно такую нишу должен был заполнить ЗФ для пхп.

Это сообщение отредактировал(а) Scorched - 5.7.2007, 19:49

Почему многие любят находить старые топики, цитировать их и говорить "что за чушь вы говорите? уже все давно по другому!"  Я знаю, что на днях вышел релиз, но на момент написания этого поста, ZF был еще в стадии BETA. Да и сейчас в первом релизе еще много багов и недочетов, почитайте хотя бы Issue Tracker. Но, не смотря на все это, Zend молодец, очень уверенно движется вперед.

MVP.

Если так подходить к этому вопросу, то зачем вообще тогда нужны View Controller-ы, Helper-ы для них, да и вообще весь фреймворк? Писать на нем серверные службы? JS уже давно стала неотъемлемой частью создания веб-приложений. И создать для AJAX оснастку было бы не только не третьей ногой, но и абсолютно логичным и нужным решением. Кстати, Zend планирует в будущем расширить функционал для работы с AJAX. http://framework.zend.com/whyzf


Да дело не в этом. Попробуйте воспроизвести у себя такую ситуацию: ZF как положено лежит рядышком с PEAR-ом и все его классы замечательно подгружаются. Но у вас есть *свой* авто-загрузчик для *своих* классов (ну не хочу я перед каждым использованием класса писать require_once(), Zend_Loader::loadClass() или еще что-либо! ). Теперь попробуйте создать свой класс Table_Row для какой-либо таблицы и при этом загрузить его через свой авто-загрузчик не трогая сам ZF. Удачи.

Ну так назовите этот класс My_Table_Row он будет отличаться от Zend_Table_Row от Zend_Db_Table_Row и т.д. Что вам мешает это сделать?

Да при чем тут имя класса?  Все дело в том, что для многих классов, таких как пользовательский клас Row, он сначала запускает метод Zend::loadClass($my_private_class), первая строчка этого метода:

Обратите внимание на второй параметр, он означает, что авто-загрузчик не будет использоваться при проверке наличия классов. Все, далее он пытается найти класс своим методом и если не находит - экзепшен... Т.е. либо называйте классы как МЫ хотим, либо идите другой дорогой... Не смотря на то, что это мой класс.

Это сообщение отредактировал(а) sTa1kEr - 6.7.2007, 01:15

Ну так а что Вам мешает реализовать свой авто-загрузчик, который будет уметь подгружать Ваши классы? с помощью spl_autoload_register() или же с помощью Zend_Loader::registerAutoload('Your_Loader_Name'), что в принципе эквивалентно. Хотя с исключениями они действительно намудрили...

Добавлено через 9 минут и 26 секунд
Хотя беру свои слова обратно, ничего они не мудрили с исключениями:
Zend_Loader

т.е. при регистрации метода Zend_Loader::autoload() - через Zend_Loader::registerAutoload() или в ручную - все исключения отлавливаются, как мы видим, что позволяет остальным авто-загрузчикам попытать счастье, в поиске класса.

Еще раз по порядку:
1. У меня реализован мой авто-загрузчик, который быстро и комфортно подгрузит любой класс. Он прекрасно РАБОТАЕТ. Если я напишу  строку типа $row = new MyRow(); то не будет никаких проблем.
2. У меня реализован класс (предположим он называется MyRow), наследованный от Zend_Db_Table_Row_Abstaract
3. Я работаю с базой данных и ZF видит, что для некой таблицы я реализовал свой клас MyRow.
4. Он явно вызывает метод Zend::loadClass() для поиска этого класса и естественно не находит его, так как не использовал ни одного авто-загрузчика, а сразу выдает Exception.
Итого: я не могу использовать свой авто-загрузчик для подобных классов.


Это сообщение отредактировал(а) sTa1kEr - 6.7.2007, 01:47

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

Единственная его проблема, чтобы нормально заменить один из компонентов (View например) приходиться углубляться во все его внутренности с напильником

Если вы используете в работе именно Zend Framework - то почему (есть ведь Symfony, CakePHP и т.д.)? И что в нем реально вам помогло лучше и быстрее программировать?

!  PARROT

Уважаемый Автор! Большая просьба перед созданием новой темы пользоваться поиском. А то бардак будет!

Это сообщение отредактировал(а) PARROT - 5.9.2007, 11:56

Компания Zend является сорозработчиком ядра php, насколько мне известно. Плюс - в нем самый удобный дебаггер, который легко настраивается.
Единственный минус - Java.... Потому как тормозит на моей машине дико в начале...

Guedda, 
Zend Framework!!! Не ZDE!

Drkwv, 
Не поддерживает php4 и следовательно полностию ОО. Очень хорошо продуман.

WolfON, 
Отлично всё подменяется. Недавно заменил View на Smarty.

А разве в ZDE нет фреймворка???

Guedda, 
Нет.

К вопросу про IDE
вот на сайте ibm:

ссылка на eclipse PDT Project



Это сообщение отредактировал(а) kit_kat - 6.9.2007, 23:11

kit_kat, 
Понятное дело. Они же приложили руку к Eclipse. Вообще PDT стоит того, чтобы её пользовать.

Ну, не то, чтобы приложили, а они Eclipse изначально и сделали. А в PDT задействованы и ребятки из Zend'a

SamDark, 



C:\Program Files\Zend\ZendStudio\bin\ZendFramework

Глаза открой, потом мозги пудри людям!

!  PARROT

Следите за выражениями, Уважаемый!

В ZDE есть ZendFramework

YURIC, 
1. Он там лежит несвежий. (Бэта. К использованию не годится. Считай, что нет).
2. Он не интерирован в среду. (В отличие от Zend Studio 6 Neon). Т.е. просто включен в classpath и всё. В настройках галочкой можно как раз его из classpath убрать.