Главная > AJAX, ExtJS Framework, PHP, веб-обзоры, Разное > Работаем с ExtJS на языке РНР — библиотека PHP-Ext

Работаем с ExtJS на языке РНР — библиотека PHP-Ext

2 мая 2008

Приветствуем наших читателей. Я вряд ли ошибусь, если предположу, что язык РНР достаточно популярен, если не самый популярный в веб-разработке. Мы не будем анализировать причины этого (а тем более, следствия), а сконцентрируемся на одном небольшом аспекте, а именно - как на РНР разрабатывать сложные AJAX веб-приложения. И не просто так разрабатывать, а использовать в своей работе библиотеку ExtJS, которая позволяет создавать интерфейсы для этих веб-приложений. Конечно, все это можно разнести и серверная сторона, на РНР или на любом другом языке, совершенно ничего не будет знать о клиентской части и AJAX-библиотеке, просто оперируя JSON данными и обычным HTML. Но можно сделать и по-другому - этот подход, аналогичен популярной сегодня технологии Google Web Toolkit. Мы ничего не разделяем, а просто пишем приложение, используя одну среду, один язык и все возможности (и языка и среды), а уже сервер самостоятельно генерирует код для клиента, полностью автоматически. Таким образом можно совсем (ну или почти) не знать и не разбираться в вёрстке, JavaScript и ExtJS, но писать приложения, которые будут использовать этот фреймворк.

Для языка Java подобные решения существуют, а недавно такой проект, EXT GWT, даже перешёл под крыло самой компании-разработчика ExtJS, превратившись в вполне серьёзное профессиональное решение. Ну а как в других языках? Java, конечно, хорошо и даже отлично, но душа и тело хотят разнообразия, или просто не хотят переучиваться. Для таких случаев есть свои решения. И одно из них, для РНР, так и называется - PHP-Ext.

Эта библиотека представляет из себя набор классов, частично повторяющий классы из ExtJS, которые переписаны на PHP, при этом добавлен механизм генерации выходного JS-кода, которые, собственно и отсылается браузеру для исполнения. Разработчик оперирует только РНР - подключаем библиотеку, инициализируем её, а потом создаём нужные нам объекты в виде РНР-классов, задаём им необходимые свойства, а в конце кода просто вызываем генерацию JavaScript и отсылаем её браузеру.

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

Код самой библиотеки достаточно большой, но текущая версия полностью совместима с РНР 5, в частности, использует все доступные возможности ООП. Сам код достаточно хорошо документирован (хоть и не идеально),а его структура соответствует стандарту Zend Framework PHP Coding Standard, что само по себе уже не так часто встретишь в развивающихся любительских проектах, здесь это показатель серьёзности разработки и, наверное, надежд на ее развитие (а вдруг и компания-разработчик ExtJS примет участие в проекте, так же, как это сделано с ExtGWT, в таком случае можно реально говорить о проекте-стартапе, причём, весьма успешном). Для разработчиков есть несколько примеров работы с типовыми объектами, например, формами - не придумывая собственные примеры, авторы библиотеки просто переделали те, что идут в стандартной поставке ExtJS, переписав их с использованием своей библиотеки. Это отличный способ посмотреть на ее реальные возможности и даже сравнить генерируемый код. Ну а для углублённого изучения есть справка по API, генерируемая по комментариям в коде при помощи phpDocumentator.

Пока, правда, не все ещё возможности реализованы, хотя тех, что есть, вполне хватит для построения относительно сложных приложений. В некоторые недостатки, с оговоркой на новизну проекта, я бы записал и использование предыдущей версии ExtJS - 2.0.2 (хотя и с 2.0.1 работает), тогда как сейчас стоит уже ориентироваться на 2.1. Но это будет поправлено, ведь сейчас только второй релиз под номером 0.8.2, поэтому пока считаем, что просто совершенствуем технологию.

Потенциал развития библиотеки очень большой, в частности, как по пути более полного переноса всего ExtJS API на сторону РНР, так и в сторону совершенствования самой платформы. Например, логично было бы иметь в составе генератора кода средства для сжатия кода, удаление неиспользуемых модулей (исходя из используемых классов и их зависимостей, сервер может на лету строить набор необходимых классов и генерировать сборку ExtJS под ваше приложение, пока же это можно сделать вручную при помощи он-лайнового конструктора). Пока проект молодой, но развивается достаточно быстро и, если за его разработкой будут стоять профессионалы и серьезная архитектура, он сможет стать отличным инструментом для разработки современных AJAX-приложений.

На мой же взгляд, вариант все же несколько сложный, вернее, слишком много кода и работы с ним для генерации интерфейса, при этом все равно необходимо чётко себе представлять, как страница генерируется и как будет работать этот JavaScript код, необходимо, мне кажется, даже лучше знать ExtJS и его возможности, чем при обычном варианте разработки, когда северная сторона совершенно не знает о клиенте. А вот какой-то проект, совмещающий шаблонный движок, например, Smarty или Template Lite (мой любимый) был бы просто фантастикой, если упросить создание и наполнение сложных шаблонов. В то же время, так как все последние версии ExtJS умеют генерировать визуальную часть по JSON-разметке, например, формы или окна, то я вижу очень много путей упрощения серверной части, которая бы генерировала только необходимый минимум JS кода, а основную часть разметки страницы - в виде JSON-данных. Но это уже совсем другая архитектура и подход.

А на последок приведём один пример, для того, чтобы наглядно понять механизм работы PHP-Ext. Следующий пример выводит обычную панель, которая может сворачиваться и разворачиваться, один из самых применяемых и универсальных виджетов библиотеки.

1. Так панель выглядит в браузере

2. Так выглядит код на РНР для генерации этой панели и задания ее параметров.

$p = new PhpExt_Panel();
$p->setTitle("My Panel")
  ->setCollapsible(true)
  ->setRenderTo(PhpExt_Javascript::variable("Ext.get('centercolumn')"))
  ->setWidth(400)
  ->setHtml(PhpExt_Javascript::variable("Ext.example.bogusMarkup"));  
  

echo PhpExt_Ext::OnReady(
	$p->getJavascript(false, "p")
);
?>

3. Это код, которые РНР-Ext сгенерировал для отображения этой формы (без кода самой страницы и подключения библитек).

Ext.onReady(function(){
var p = new Ext.Panel({title: 'My Panel',collapsible: true,
renderTo: Ext.get('centercolumn'),width: 400,html:
Ext.example.bogusMarkup});
});

4. А это оригинальный код с примеров ExtJS

Ext.onReady(function(){
    var p = new Ext.Panel({
        title: 'My Panel',
        collapsible:true,
        renderTo: 'container',
        width:400,
        html: Ext.example.bogusMarkup
    });
});
  1. 2 мая 2008 в 16:44 | #1

    И вы туда же 😐
    SAJAX, XAJAX, jQuery-PHP теперь ещё и эта штука.. я как-то писал об этом — такие библиотеки смешивают бизнес логику приложения.. Получается ещё большая неразбериха — попробуйте отследить по непонятным запросам как что работает.

  2. Игорь
    2 мая 2008 в 17:46 | #2

    Проект интересный конечно… но если не будет под крылом у ExtJS то толку будет мало.Навряд будут успевать за обновлениями и тестированием, конечно если не будет хорошего сообщества. И опять же стоит вопрос производительности.Которая снизется в разы это точно. Думаю пока у каждого не будет доступа в инет на скорости в 15 Mb/sec толку будет мало. У меня счас чистый ExtJS на локалхосте выполняется 3-5 сек, а с этой библиотекой домаю все 10-15 сек.

  3. 2 мая 2008 в 17:56 | #3

    Игорь, я извиняюсь, но вы либо невнимательно читали материал, либо еще не разобрались с библиотекой (и с одной, и с второй).

    1. Будет ли он с компанией ExtJS LLC, или нет -не так важно. АПИ некоторых компонентов не менялся с версии еще 1.1, да и самих их все же не так много, поэтому написать обертку на РНР и поддерживать с выходом новых версий, вполне по силам даже одному- двум людям. Много ли АПИ поменялось даже при переходе на 2.1? Нет, добавились некоторые свойства и новые компоненты всего лишь.

    2. При чем тут производительность? Это СЕРВЕРНАЯ библиотека, для генерации клиентского кода. Если ее доточить и сделать упор на оптимизацию клиентского кода, то производительность даже вырастет, по сравнению с читсым екстом.

    3. Про скорость вы загнули, вполне отлично работает на каналах от 256/512 Кб, которы уже стандарт везде, где только можно.

    4. Екст для веб-приложений, здесь другие мерки производительности и время загрузки и инициализации даже в 10 секунд — это мелочь. Разница между сайтом и веб-приложением большая. очень. Кроме этого, если очень хотеть, и владеть темой, даже обычный екст можно так заточить, что будет вполне быстро грузиться. Но всеравно первое и самое верное его применение — для веб-приложей, а здесь арифметика другая. Совсем.

  4. 2 мая 2008 в 21:17 | #4

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

  5. maxsim
    3 мая 2008 в 16:18 | #5

    Библиотека для более удобной разработки web-приложений, а это всегда хорошо.
    P.S.: Замените, пожалуйста, первую строку кода в пункте 2 на строки
    $p = new PhpExt_Panel();
    $p->setTitle(«My Panel»)
    а то сразу не понятно, что за setTitle(«My Panel») в воздухе повис 🙂

  6. 4 мая 2008 в 13:12 | #6

    maxsim — спасибо, исправил! заодно кучу очепяток нашел — вот что значит писать с другого компьютера без спелчека 🙂

  7. 11 мая 2008 в 16:43 | #7

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

  8. 19 мая 2008 в 11:41 | #8

    Пробю запукать пример, но безрезультатно

    Notice: Use of undefined constant PHP_EXTJS_DOC_ROOT — assumed ‘PHP_EXTJS_DOC_ROOT’ in z:\home\localhost\www\php-ext\library\PhpExt\Javascript.php on line 139

    Warning: PhpExt_Javascript::include_once(PHP_EXTJS_DOC_ROOT/lib/json.php) [function.PhpExt-Javascript-include-once]: failed to open stream: No such file or directory in z:\home\localhost\www\php-ext\library\PhpExt\Javascript.php on line 139

    Warning: PhpExt_Javascript::include_once() [function.include]: Failed opening ‘PHP_EXTJS_DOC_ROOT/lib/json.php’ for inclusion (include_path=’.;/usr/local/php5/PEAR;z:\home\localhost\www\php-ext\library’) in z:\home\localhost\www\php-ext\library\PhpExt\Javascript.php on line 139

    Fatal error: Class ‘Services_JSON’ not found in z:\home\localhost\www\php-ext\library\PhpExt\Javascript.php on line 140

  9. 20 мая 2008 в 08:50 | #9

    Игорь — что из этого не ясно и что нельзя поправить вручную? вроде все написано 🙂

  10. Игорь
    20 мая 2008 в 11:45 | #10

    да не ясно то, что как ни пробую у меня не запускается пример ни на денвере ни на хосте, ни где!
    взял последнюю версию с SVN, положил как написано все куда надо, и… не работает. Оно то понятно что на сайте у НИХ работает, но мне то важно чтобы заработало у меня хоть как нибудь. Как можно создать сообщество, когда библиотеку применить нельзя? Огромная просьба гуру! Опишите подробно на какую платформу ставить , можно ли помещать в подпапку и прочее и прочее?! Библиотека безусловно долгожданна как никогда, но не издевайтесь так над начинающими.

  11. 20 мая 2008 в 11:49 | #11

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

  12. Дмитрий
    21 мая 2008 в 11:16 | #12

    >>> А как они смешивают, если, по-моему, наоборот, сводят всю логику к одной платформе и, наверное верно, парадигме?

    Возьмем для примера CodeIgniter:
    — Вся логика содержится в моделях
    — Передачу данных берут на себя контроллеры
    — За представление отвечает представление, читайте ExtJS
    Это классика MVC. Совмещать контроллеры и представление для крупных проектов смерти подобно.

    Зачем изобретать велосипед?

    Плюсы PHP-Ext это заявленная сборка JS на лету. Но есть альтернативный метод: конфиги екста подключать динамически (хоть тем же IFRAME, чтобы не перегружать CPU)

  13. 21 мая 2008 в 21:39 | #13

    Пока успел прочитать только эту одну заметку, если и все остальное точно также интересно, то автору респект 🙂

  14. 30 мая 2008 в 16:13 | #14

    Красивая штука эти панели… Надо будет глянуть библиотечку

  15. Сергей
    5 июня 2008 в 11:36 | #15

    Мне кажется сомнительная штука 😕
    Когда пишешь под GWT забываешь даже о том, что в результате получается javascript. Просто пишешь на Java-е и всё.
    А здесь получается, что даже для таких простых задач требуется знать, что на клиенте работает какой-то Ext, что у него есть какой-то там метод get() и т.п.
    Если уж копировать API Ext, то на всё «катушку» 🙂

  16. 5 июня 2008 в 18:10 | #16

    Сергей — то, что создавая код в GWT можно не знать JS и как это работает в браузере, в основном, порождает просто плохой код и таких же, простите, программистов. Знать как это работает нужно и обязательно в любом случае. да, много тонкостей и рутины скрывается, но общие принципы остаются.
    Ну так а в чем проблема то? Зная GWT всеравно API нужен, но он заточен только под платформу его, а так, зная екст один раз, можно писать везде и понимать, как оно работает. Хотя частичка правды есть — возможно, некоторого высокоуровневого слоя не хватает, хотя как и на каком уровне — возможно типовые компоненты, я пока не представляю.

  17. 6 июня 2008 в 23:00 | #17

    Какие положительные результаты 🙂

  18. 12 июня 2008 в 20:40 | #18

    Довольно интересно написано. А вообще, поздравляю автора блога и всех его читателей с сегодняшним праздником — Днем России. Ура, товарищи! 🙂

  19. master
    27 сентября 2008 в 08:28 | #19

    Это всё замечательно. Уже год слежу за Экстом и полгода на PHP:EXT. Радует многое. Но. Использовать ни то, ни другое не тянет…
    Delphi в своё время были сделаны для облегчения работы с API. И такой мощи до сих пор нет ни для php, ни для js, ни тем более для их связки. Если бы эту штуку интегрировали бы хотя бы в Delphi PHP на основе идей Delphi (события, сообщения, компоненты, VCL) — было бы куда интереснее и безусловно имело бы право на жизнь. А так получается, что мы грузим и сервер, и клиента, а взамен получаем лишний геморрой в виде прослойки из лишнего php-кода и кучи JS-кода и никаких явных преимуществ… Даже передача сообщений (это в приципе то, ради чего и мутят js-приложения) невозможна в PHP-Ext. А отладка (а её придётся делать и для PHP-Ext, и для Ext, думаю ни у кого нет сомнений, что там будут баги при столь частых релизах) выливается в нечто неординарное.

  20. Vladimir
    1 января 2009 в 22:19 | #20

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

  21. 5 января 2009 в 20:44 | #21

    О, неплохая статейка! Я довольно-таки давно работаю с PHP, но всё как-то на любительском уровне. Хотелось бы организовать что-нибудь помощнее. Это поможет

Комментирование отключено.