Comments 31
здорово - сейчас пойду напью пива и посмотрю на эту штуку внимательнее ;))
Поддерживаю, надо поразбираться
пойду налью пива посмотреть как вы будете разбираться :-)
тема сисек библиотеки не раскрыта.
Как библиотека упрощает жизнь? Чем она лучше собственного PHP бек-энда?
Ну, в прочем понятно, надо смотреть на сайте PHP-Ext.
Как библиотека упрощает жизнь? Чем она лучше собственного PHP бек-энда?
Ну, в прочем понятно, надо смотреть на сайте PHP-Ext.
В вопросах создания большого приложения на ExtJS, эта библиотека кажется мне паразитом. (долблюсь над бэкэндом посредством ExtJS)
А вот что бы делать небольшие вставки приятных и удобных UI, по мойму очень даже удобно.
Учитывая, что много народу пользуется всякого рода шаблонизаторами...
Да, приятно, приятно не замарачиваться с 2-ми языками сразу :).
Кстати, порылся в коде, нашел для себя полезности в виде работы с json данными. Спасибо ребятам! дело на самом деле очень полезное!
А вот что бы делать небольшие вставки приятных и удобных UI, по мойму очень даже удобно.
Учитывая, что много народу пользуется всякого рода шаблонизаторами...
Да, приятно, приятно не замарачиваться с 2-ми языками сразу :).
Кстати, порылся в коде, нашел для себя полезности в виде работы с json данными. Спасибо ребятам! дело на самом деле очень полезное!
Хорошая задумка, но ...
Есть библиотека XAJAX, а есть, к примеру, jQuery.
Я очень долго использовал в проектах XAJAX, начал полтора года примерно назад. Но сейчас полностью перешел на jQuery. Бэк-енд скрипт должен только предоставлять данные в JSON, а js - подставлять данные в шаблоны.
К чему я это? Тут можно провести параллель с PHP-Ext и ExtJs + PHP.
Оба подхода хороши, но, на мой взгляд, второй подход более гибок и универсален. Это как сравнивать MS Access и C++ Builder + MSSQL.
Кроме того, есть расширения для ExtJs, позволяющие получать мета-данные компонентов с серверной части.
Есть библиотека XAJAX, а есть, к примеру, jQuery.
Я очень долго использовал в проектах XAJAX, начал полтора года примерно назад. Но сейчас полностью перешел на jQuery. Бэк-енд скрипт должен только предоставлять данные в JSON, а js - подставлять данные в шаблоны.
К чему я это? Тут можно провести параллель с PHP-Ext и ExtJs + PHP.
Оба подхода хороши, но, на мой взгляд, второй подход более гибок и универсален. Это как сравнивать MS Access и C++ Builder + MSSQL.
Кроме того, есть расширения для ExtJs, позволяющие получать мета-данные компонентов с серверной части.
Сейчас возникли проблемы с лицензией ExtJS. Разработчики поменяли ее на с LGPL на GPLv3 в новой версии, что тянет за собой все related проекты. Советую присмотреться к этому повнимательнее прежде чем использовать в своих проектах.
пожалуйста, не "мутите воду". В подавляющем большинстве случаев это ничего не тянет. Для серьезных проектов стоимость платной версии копеечная, для большиснтва других - подходит и GPL. Для особо завернутых на свободе - есть форк OpenEXT (устаревший 2.0.2). Всеравно аналогичного функционала и качества нигде нет и пока не предвидится, потому отказываться из-за такого - глупо и не выгодно. Или вы можете аргументировано описать какие кары из-за новой лицензии? Пока никто не привел аргументов (либо я не нашел, на русском всмысле :)
а никто ничего не мутит. Это вызвало очень большой резонанс. В подавляющем большинстве это тянет за собой все. Это природа лицензии GPL. Так вот, если вы пишите проект, который использует ExtJS, весь код в котором используется библиотека должен быть выпущен под GPL.
А это уже проблема. А если он жестко связан с сервером, как в случае этого фреймвонка, то и весь бэкэнд затрагивается. Проблема не для коммерческих, здесь я этого не касаюсь. Это проблема для опенсорс проектов, которые выпущены под другими лицензиями. Все плагины, темы, доп функциональность будет выпущена под GPLv3. Большой потенциал ExtJS обеспечило комьюнити. Это факт. И точто такой же факт, что этого не было бы если бы ExtJS была бы не под LGPL до этого Хотя сейчас Jack Slocum услышал комьюнити и готовит исключения в лицензии для открытых проектов. Смена лицензии 3 раза популярности не прибавляет. В англоязычном интернете очень много об этом.
А это уже проблема. А если он жестко связан с сервером, как в случае этого фреймвонка, то и весь бэкэнд затрагивается. Проблема не для коммерческих, здесь я этого не касаюсь. Это проблема для опенсорс проектов, которые выпущены под другими лицензиями. Все плагины, темы, доп функциональность будет выпущена под GPLv3. Большой потенциал ExtJS обеспечило комьюнити. Это факт. И точто такой же факт, что этого не было бы если бы ExtJS была бы не под LGPL до этого Хотя сейчас Jack Slocum услышал комьюнити и готовит исключения в лицензии для открытых проектов. Смена лицензии 3 раза популярности не прибавляет. В англоязычном интернете очень много об этом.
странно, я думал, что если ты что-то меняешь в коде самой либы - обязан эти изменения публиковать. а если я ее просто использую - никому ничего не должен...
Так с LGPL. С LGPL вы не обязаны выпускать свое приложение под такой же лицензией, т.к. работа не является производной если вы просто используете библиотеку. Если модифицируете, то тут да. А вот с GPL - обязаны выпускать под GPL даже если просто используете библиотеку под GPL. Это еще называют вирусной природой лицензии GPL. На форуме ExtJs очень много по этому вопросу написано. Тут конечно все намного сложнее и будут модификации для opensource от команды.
Вы неправы. Если в проекте используется библиотека с GPL лицезией, и ее код не модифицировался, то вы можете ее спокойно использовать в проприетарных продуктах и ничего никому не должны.
Если точнее, в GPL есть понятие «производная работа». Так вот, весь проект с использованием какой-либо GPL библиотеки не является производной работой от этой библиотеки. Производной работой является только модифицированная GPL библиотека, если она была изменена.
Тут есть один нюанс. Если вы встраиваете куски GPL-кода в код своего проекта, то вы его «заражаете» GPL лицензией. А если у вас лежит GPL-библиотека в какой-то директории, и вы только вызываете ее функции/методы, то никакого заражения GPL кодом нет, и вы никому ничего не должны.
Поэтому webmechanics прав.
Если точнее, в GPL есть понятие «производная работа». Так вот, весь проект с использованием какой-либо GPL библиотеки не является производной работой от этой библиотеки. Производной работой является только модифицированная GPL библиотека, если она была изменена.
Тут есть один нюанс. Если вы встраиваете куски GPL-кода в код своего проекта, то вы его «заражаете» GPL лицензией. А если у вас лежит GPL-библиотека в какой-то директории, и вы только вызываете ее функции/методы, то никакого заражения GPL кодом нет, и вы никому ничего не должны.
Поэтому webmechanics прав.
Сначала заинтересовался, а потом разочаровался, прочитав это:
"Мы ничего не разделяем, а просто пишем приложение, используя одну среду, один язык и все возможности (и языка и среды), а уже сервер самостоятельно генерирует код для клиента, полностью автоматически. Таким образом можно совсем (ну или почти) не знать и не разбираться в верстке, JavaScript и ExtJS, но писать приложения, которые будут использовать этот фреймворк."
Интерес сразу пропал.. почему? Ну а зачем знать JavaScript, разбираться в верстке и т.д. если умная библиотека все умеет сама? С таким же успехом зачем знать HTML? Подготовьте страницу в MS Word и сохраните документ "Как вебстраницу". А потом посмотрите исходный HTML код после "умного" word'a и постарайтесь не упасть в обморок. Полагаю, здесь картина примерно такая-же, легкость разработки карается изобилием мусора.
Делать нужно самому, ручками. Тогда будет полный порядок.
"Мы ничего не разделяем, а просто пишем приложение, используя одну среду, один язык и все возможности (и языка и среды), а уже сервер самостоятельно генерирует код для клиента, полностью автоматически. Таким образом можно совсем (ну или почти) не знать и не разбираться в верстке, JavaScript и ExtJS, но писать приложения, которые будут использовать этот фреймворк."
Интерес сразу пропал.. почему? Ну а зачем знать JavaScript, разбираться в верстке и т.д. если умная библиотека все умеет сама? С таким же успехом зачем знать HTML? Подготовьте страницу в MS Word и сохраните документ "Как вебстраницу". А потом посмотрите исходный HTML код после "умного" word'a и постарайтесь не упасть в обморок. Полагаю, здесь картина примерно такая-же, легкость разработки карается изобилием мусора.
Делать нужно самому, ручками. Тогда будет полный порядок.
согласен, универсальность порождает избыточность.
но посмотреть интересно.
но посмотреть интересно.
а где остановиться? язык программирования, ОС, драйвера и микрокод процессора тоже сами пишете? Кстати, то, что професиональному веб-разработчику код от ворда не нравится, реальным людям совершенно неважно, так как значение функции "сохранить как веб-страницу" другое и очень значительное (повторю - для нормальных людей и задач, а не узкого круга професионалов в узкой области)
Не могу не согласиться с вами. Однако, я прокомментировал именно с профессиональной точки зрения. Если я делаю простого хомяка для соседки-дачницы, которая хочет выложить пару фоток своих огородных успехов в интернет - ворд сгодиться :) Если что-то серьезное, мне пригодиться замечательная библиотека. Однако, если необходимо разработать более сложный проект, с функциональностью интерфейса хабра, например, то только руками. jQuery или Prototype + PHP - не смешивая все в одну кухню. Я не говорю о бесполезности продукта, скорее о предпочтениях, если речь идет о разработке сложных серьезных программных продуктов.
Чего-то я не вкурил смысла этой библиотеки. ExtJS это клиентский front-end. PHP это серверный back-end. Смешать, но не взбалтывать © Бонд.
не смешивать надо на другом уровне, вы путаете
если MVC, то View как-раз таки фронт-энд, и PHP-ExtJS очень кстати
если MVC, то View как-раз таки фронт-энд, и PHP-ExtJS очень кстати
View это клиентский фронт-энд? Под клиентом понимается браузер. Или я чего-то не понимаю…
Вообще такая библиотека пригодится когда нужно ну к примеру генерировать разные элементы управления для разных случаев. Ну и как-то все. Больше на ум ничего не приходит. Честно говоря все еще не понимаю смысла этого генератора JS-кода.
Вообще такая библиотека пригодится когда нужно ну к примеру генерировать разные элементы управления для разных случаев. Ну и как-то все. Больше на ум ничего не приходит. Честно говоря все еще не понимаю смысла этого генератора JS-кода.
а вы более общо посмотрите. MVC-паттерн можно применить локально, рассматривая архитектуру только серверной части, а можно и чуть выше поднятся, рассматривая браузер как полноценный клиент (а в случае современных AJAX веб-приложений, браузер совсем не пассивная штука для рендеринга и принятия запросов).
Открыл страничку проекта. Потыкал примеры. Извините за вырожение, глючит безбожно! [IE6]
Под Safari(win) вообще ни один пример правильно не отобразился.
Я в шоке!
Под Safari(win) вообще ни один пример правильно не отобразился.
Я в шоке!
Выучите долбанный JavaScript! Это замечательный язык и хватит страдать «программисткой ленью» и генерить один язык на другом.
клева! выучить можно, только вот с кроссбраузерностью траблы… ну не знает ИЕ про viewport, к примеру! ну и ладно. и это можно обойти. только зачем велосипед изобретать, когда есть уже решение! Нужно решать поставленную задачу, экономя ресурсы и время. Да, не спорю, что использование библиотек и фреймворков заставляет нас считаться с ними, и это неизбежно. Написать что-либо действительно стоящее, безопасное очень сложно. и языки тут вообще ни разу ни при чем. извините…
Дело не в отказе от фреймворков, а в использовании PHP из-за того, что Javascript учить лень. Надеюсь я правильно понял DmitryBaranovskiy.
ага, вы еще скажите, что IE не показывает офф примеры с viewport-ом… все работает, значит проблема в вашем коде. сам екст полностью кроссбраузерный
На мой взгляд нет ничего плохого в том, чтобы писать весь код на одном языке — PHP, а не смешивая его с JavaScript. Потому как в готовых библиотеках как правило уже зашиты некоторые полезные вещи (кроссбраузерность, например), про которые можно запросто забыть самому.
Sign up to leave a comment.
Работаем с ExtJS на языке РНР — библиотека PHP-Ext