PhantomJS — это сборка движка WebKit без графического интерфейса, позволяющая в режиме консоли загружать веб-страницу, выполнять JavaScript, полноценно работать с DOM, Canvas и SVG. Одним из главных заявленных применений PhantomJS является автоматизированное функциональное тестирование пользовательского интерфейса. PhantomJS имеет интеграцию с различными фреймворками для тестирования JavaScript и веб-страниц. Посмотрим, что можно сделать на базе стандартного функционала PhantomJS, чтобы протестировать отдельный компонент и целое приложение, написанное на ExtJS/Sencha. В этой статье я приведу некоторую простейшую заготовку для тестировочного фреймворка, иллюстрирующую подход к тестированию кода, основанного на сторонней JavaScript-библиотеке. Весь код, представленный в статье, доступен на GitHub.

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

Описанная схема имеет все недостатки толстого клиента. Это и необходимость разработки отдельного приложения для работы из браузеров (что в современном мире является нормальным требованием), и необходимость установки дополнительного ПО, и проблема его обновления, и вообще необходимость найма специалистов по разработке десктоп приложений. Согласитесь, нам, как веб разработчикам, проблема работы офлайн всегда была костью в горле.

Сегодня этот вопрос решается элегантно — с помощью HTML5 с его локальным хранилищем (local storage), Ext JS 4 с возможностью прозрачно работать с этим хранилищем, и HTML5 кэшем приложений (Application Cache). Совокупность этих технологий позволяет реализовать следующую схему: при наличии сети статичные файлы (HTML/CSS/JS код и картинки) загружаются с сайта и мы работаем с серверной централизованной базой данных, при отсутствии сети статика загружается из Application Cache и мы работаем с локальным хранилищем, которое сохраняется в серверную БД при появлении доступа к Интернет. При этом без активного подключения по URL адресу страницы браузер отображает не ошибку доступа к сети, а функциональную систему, работающую с локальным хранилищем. Пояснения и рабочий пример (да не упадет мой vds под хаброэффектом) — под катом. Статья получилась немаленькая, но, надеюсь, весьма содержательная.

Думаю, каждый, кто писал WEB-приложение с активным использованием JavaScript на стороне клиента, сталкивался с проблемой десятичного разделителя. И решение этой проблемы отнюдь нетривиально, как может показаться на первый взгляд. В ExtJS использован простой в реализации и управлении подход: числовому полю указывается символ, который считается разделителем, и ввод других символов, исключая цифры и "-", запрещен. Однако этот подход, как мне кажется, имеет один существенный недостаток: когда используется несколько раскладок десятичный разделитель на цифровой клавиатуре соответствует разным символам. Как это исправить описано ниже.

Проблема взаимопонимания

Представьте себе ситуацию: вы — фрилансер и работаете с Ext. С вами удалённо работает один (или несколько) разработчиков back-end. Работа идёт быстро и гладко. Но вот вот случилось так, что разработчик серверной части сменился. Если у нового коллеги есть опыт взаимодействия с Ext — всё замечательно. Но вот если человек впервые будет писать back-end для Ext или впервые будет писать для веба (такое тоже случается), то вам будет необходимо найти общий язык.
И вот тут могут начаться проблемы…
Придётся тратить время на простое объяснение протокола, объяснения как должен реагировать сервер на те или иные запросы. Чтобы избежать этого, я подготовил документ, описывающий все (ну или почти все нюансы стандартного для Ext протокола). Этот документ и представлен под катом.

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

Несмотря на то, что четвертая версия каркаса ExtJS вышла уже достаточно давно, материалов по этой версии на хабре не слишком много. А если учесть, что в четвертой версии существенно переработан API, структура классов и предлагаемая архитектура приложения, то, как мне кажется, тут есть, о чем поговорить.

В данной статье я попробую рассказать свои впечатления от фреймворка в контексте портирования существующей кодовой базы на новую версию; постараюсь так же не забыть о подводных камнях и ссылках на полезные (и не очень) страницы справки.

Эта статья — перевод статьи из блога www.swarmonline.com с небольшими моими дополнениями

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

В этой статье мы собрали список некоторых из вещей, которые рекомендуем вам делать, когда вы начинаете работать с Ext JS (даже, если вы ветеран разработки, всё равно можете узнать что то новое!). Эти вещи прошли через наш опыт, через просмотр и ответы на одни и те же вопросы на форумах. Это наиболее общие из лучших техник программирования.

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

Добрый день, хабрапользователи! Сегодня я бы хотел поделиться с проблемами, которые обычно отталкивают добропорядочных программистов от использования фреймворка — Ext JS. Опишу конкретную ситуацию: в один прекрасный день после некоторого времени потраченного на просмотр возможностей, которые предлагает Ext JS, возникает непреодолимое желание попробовать его «в деле». Качается дистрибутив, ставится на локальный сервер и запускаются красивые примеры гридов, форм и, даже, готового рабочего стола! Разработчик меняет пару «фишечек», все вроде легко и просто. Резонно в голове бой-скаута возникает идея сделать некий коммерческий проект на Ext JS (чаще всего это бывают различного рода CMS, админки, CRM). И тут начинается самое интересное…

Постоянно меняющиеся требования и сжатые сроки подтолкнули нас к использованию ExtJS 4 для создания прототипа.

Проблемы в ExtJS, с которыми мы столкнулись при разработке, едва ли превысили опыт, который мы получили при препарировании ExtJS.

В интернете много статей про ExtJS 4 уровня basic. Например очень порадовала эта статья http://css.dzone.com/articles/how-use-extjs-4-jquery. А вот серьезных “не кассовых” статей по решению (или созданию) каких-то проблем с помощью ExtJS не много.

Предлагаю вашему внимаю первую статью в рамках ExtJS patch lab… Ну и немного о самой соц. сети… совсем немного.

Преамбула

Ext JS 4 представляет разработчикам много новых возможностей, в числе которых, например, большое количество новых графиков и диаграмм. Сравните — для четвертой версии приведено 22 примера использования элементов Chart против всего четырех примеров для третьей версии. Внушающе, не правда ли?

Однако что, если в наличии есть большое приложение, реализованное на третьей версии Ext JS и возникает необходимость использования некоторых виджетов четвертой версии? Например, типична ситуация, когда в приложение нужно добавить новые диаграммы, но переписывать всё на «четверку» нецелесообразно.

К счастью, разработчики фреймворка позаботились об этом. Ext JS 4 полностью изолирован, что позволяет использовать четвертую версию наравне с третьей в пределах одной страницы! Чтобы продемонстрировать эту возможность на боевом примере, авторами фреймворка был создан пример, добавляющий в Ext JS 3 приложение новые диаграммы четвертой версии. Итак, что для этого нужно?