Как и многие другие, я думаю, был поглощен просмотром первого выпуска новой платформы .
Первоначально вел заметки о впечатлениях, но чувствую, что сейчас нет особого смысла — первый выпуск — качество «предварительного просмотра», а шероховатости — это само собой разумеющееся. Прямо сейчас это подходит только опытным PHP-разработчикам, желающим понять, что будет дальше — подождите и избегайте разочарований.
Можно утверждать, что он был выпущен слишком рано — он не прошел тест « Установи меня» Маркуса, по крайней мере, в том, что касается контроллеров, что, как я полагаю, большинство людей хотят видеть. В отличие от Ruby, PHP — это язык, который многие люди хорошо знают и способны формировать правильные мнения, поэтому аудитория, вероятно, будет гораздо более критичной и выпустит ранние негативные отзывы о рисках.
Тем не менее, я лично счастлив, что Зенд получил что-то за дверью. Поработав некоторое время, я также осторожно оптимистичен.
Построение консенсуса
Самое положительное впечатление, которое я получаю от предварительной версии, — это то, что Zend устанавливает различные соглашения о том, как «делать» библиотеки и повторно использовать код в PHP.
Вы можете получить представление, читая блоги Роба Аллена на фронт-контроллере и просматривая (Роб сделал это для PHP London Conf BTW) — обратите внимание, как он организует свое собственное пространство имен в файловой системе и реализует некоторые из интерфейсов Zend;
/ Библиотека / Akrabat /lib/Akrabat/Action.php /lib/Akrabat/Router.php
Если у вас есть указанный выше каталог lib в вашем пути включения, вы можете загрузить классы с помощью метода Zend :: loadClass () .
Это просто наводит на мысль, но поскольку Zend имеет вес, чтобы заставить мяч двигаться, он может видеть, как он генерирует соглашения и соглашения о том, как развертываются библиотеки и расширения инфраструктуры. Если Zend Framework начинает появляться в дистрибутивах Linux и устанавливается по умолчанию хостинговыми компаниями, есть сильный стимул делать то же самое.
Это само по себе было бы огромным плюсом для PHP, поощряя организацию и фокусируя внимание на людях, пишущих библиотеки PHP с открытым исходным кодом. Сегодня объединение проекта с использованием стороннего кода означает либо склеивание, либо взлом исходного кода — с помощью фреймворка Zend в качестве центральной точки, мы наконец-то начинаем выводить какую-то организацию из хаоса. Добавьте к этому, что сама структура устраняет необходимость заново изобретать определенные колеса, такие как то, что обеспечивает InputFilter , а также предоставляет точки расширения, такие как помощники настраиваемого представления или некоторые из интерфейсов, которые они включили (хотя DI необходим — подробнее ниже).
Выбор по-прежнему вариант
Если вы готовы принять Zend Framework в центре (и я не думаю, что в этом есть что-то вредное, кроме, возможно, хорошей кеш-памяти кода операции), есть много места для распространения ваших вещей в качестве дополнений для Это.
Например, фреймворк не реализует движок шаблонов как таковой, ваши скрипты вида являются PHP (я думаю, это основано на опыте Пола с Savant ). Ничто не мешает Smarty или WACT распространять свои механизмы шаблонов в форме, которая «готова к работе» с Zend Framework, и на самом деле для этого есть веские причины — если Zend Framework получает широкое признание, то есть «Zend Framework». Соответствует »(логотип кто-нибудь?) Добавит законности.
То же самое относится и к компонентам eZ — их можно легко приспособить к среде Zend, предоставляя массу вещей, которые среда не делает, и выбирая некоторые вещи, которые она делает .
Кроме того, глядя на контроллеры, у меня складывается впечатление, что дизайн по умолчанию будет работать в некоторой степени как в Rails — пользовательские классы контроллеров с методами классов, соответствующими определенным действиям / URL-адресам. Лично я не особенно очарован таким подходом и предпочел бы увидеть что-то похожее на web.py ;
class WikiPage extends Resource { public function GET() { // response to HTTP GET } public function POST() { // response to HTTP POST } }class WikiPage extends Resource { public function GET() { // response to HTTP GET } public function POST() { // response to HTTP POST } }
То, что до сих пор, похоже, имело место, — то, что я смогу взять свой пирог и съесть его — должна быть возможность создать этот вид API в рамках текущей конструкции контроллера, с небольшим расширением и реализацией существующих API.
Особенность убийцы
В данный момент думаю, что самая сильная функция, которую он предлагает, — это средства поиска (еще не завершенные / стабильные), которые являются портом проекта Apache Lucene (Java) для PHP. Прямо сейчас в принципе нет приличного поискового инструментария, встроенного в PHP (кроме создания расширений для таких проектов, как Xapian ). Уже можно вспомнить один проект, который должен был катиться самостоятельно .
Опять же, как спроектирован API, можно было бы использовать проекты, использующие Zend Framework в своей основе, для доступа к функциям индексации поиска, что позволяет пользователям выполнять «унифицированный» поиск по различным приложениям, которые они используют на своем сайте.
В противном случае, хотя это и не совсем особенность, действительно приятно смотреть на код, который четко написан непротиворечивым образом и хорошо документирован .
Обеспокоенность
Теперь есть несколько мелких проблем, которые я мог бы поднять (например, Feed API очень крутой, но как насчет кодировки символов?), Но не будет в настоящее время, учитывая статус предварительного просмотра.
Есть две большие вещи, которые, я думаю, отсутствуют.
Во-первых, это юнит-тесты, которые не были частью загрузки. У меня есть подлое подозрение, которое может быть из-за того, что пока нет никаких юнит-тестов (дайте мне пощечину, если я ошибаюсь), учитывая один или два из выпусков релиза, которые произошли. Я знаю, что есть необходимость вывести эту платформу «туда», но не жертвуйте модульными тестами (модульные тесты должны быть в этом списке )! Скоро появится онлайн- трекер ошибок . Дополнительным (и я бы сказал, более ценным) источником обратной связи были бы результаты теста — если пользователи запускают тесты и доставляют их, скажем, по электронной почте вместе с небольшой информацией об их среде (версия PHP, ОС и т. Д.), у вас есть очень хорошее свидетельство того, насколько прочная структура — гигантская ферма, если хотите. В противном случае модульные тесты необходимы для установления доверия с пользователями (разработчиками).
Другой, более неясный, это инъекция зависимости , о которой я продаю после выступления Павла . Поверьте, Себастьян из соавторов имеет некоторый опыт там. Что убедило меня Павла в PHP-версии picocontainer, так это то, что для PHP это можно сделать «легковесным» способом, который не потребляет ресурсы. Для Zend Framework это кажется критически важным, если он станет центральной точкой «интеграции» для других проектов — вместо того, чтобы специально загружать и создавать экземпляры объектов, внедрение зависимостей позволит компонентам получать «сервисы» через платформу, предоставляя пользователям возможность решать какую реализацию они хотят использовать.
Нижняя линия
Zend Framework — это то, чего PHP давно не хватает. Он еще не готов к продуктивному использованию, но его текущая форма должна дать разработчикам библиотек понимание того, как их код может быть приспособлен к нему. С моей точки зрения, это, безусловно, не угроза, и это лучший шанс, который мы когда-либо получим, чтобы связать многие тысячи часов совместной работы в единую платформу. Возьми это или оставь.