27 декабря 2009 г.

GWT. Взаимодействие с Django

Вся работа в GWT имеет подробную документацию. В ней все понятно и прозрачно. Но наше дело тормозится тем, что в качестве бекенда у нас выступает Django. То есть стандартный GWT RPC нам не подходит. Встает вопрос о том, как обмениваться данными между GWT и Django.

Я долго раздумывал, какой интерфейс взаимодействия выбрать. Технология-то одна - ajax, а вот какой инструмент более удобен? Можно попробовать использовать RequestBuilder, но этот метод не совсем удобен и не совсем универсален. Поэтому я выбрал json-rpc. Для него уже все создано, как на стороне django, так и на стороне GWT.

Json-rpc, это легкий протокол удаленного вызова процедур, использующий для своего функционирования формат Json.
Пример запроса и ответа:

--> { "method": "echo", "params": ["Hello JSON-RPC"], "id": 1}
<-- { "result": "Hello JSON-RPC", "error": null, "id": 1}

Начнем с django. Добавляем поддержку json-rpc в наш проект.

Импортируем django-json-rpc и добавляем точку входа в urls.py.
 

from jsonrpc import jsonrpc_site
import myproj.myapp.views # подключаем файл, в котором буду храниться rpc функции

urlpatterns += patterns('',
url(r'^json/', jsonrpc_site.dispatch, name="jsonrpc_mountpoint"),
)

Возьмем пример с readme:
 

from jsonrpc import jsonrpc_method

@jsonrpc_method('myapp.sayHello')
def whats_the_time(request, name='Lester'):
return "Hello %s" % name

Запускаем сервер, запускаем шел django
 

./manage.py runserver 8080
./manage.py shell

И тестируем:
 

>>> from jsonrpc.proxy import ServiceProxy
>>> s = ServiceProxy('http://localhost:8080/json/')
>>> s.myapp.sayHello('Sam')
{u'error': None, u'id': u'jsonrpc', u'result': u'Hello Sam'}

В общем, в документе все написано. Также в приложении есть своей браузер, зайти на него можно по адресу http://localhost:8080/json/browse/ , добавив в urls.py, например так:
 

if settings.DEBUG:
urlpatterns += patterns('',
url(r'^json/browse/', 'jsonrpc.views.browse', name="jsonrpc_browser"), # for the graphical browser/web console only, omissible
)

urlpatterns += patterns('',
url(r'^json/', jsonrpc_site.dispatch, name="jsonrpc_mountpoint"),
)


Я нашел несколько неточностей в документации, так, там name="jsonrpc_browser" без буквы "r" на конце, плюс url браузера
идет после r'^json/', который перекрывает его вызов.

Итак, rpc в django у нас теперь есть. Переходим к клиентской части rpc в gwt.

Проделываем все операции, указанные в readme и... у меня не заработало.
 

09:36:42.942 [ERROR] [myapp] Errors in 'jar:file:/lovely.gwt.jsonrpc-0.7.jar!/lovely/gwt/jsonrpc/client/JSONServiceBase.java'
09:36:42.957 [ERROR] [myapp] Line 29: The type JSONServiceBase must implement the inherited abstract method ServiceDefTarget.setRpcRequestBuilder(RpcRequestBuilder)


Судя по всему, в GWT 2.0 изменились какие-то механизмы в сервисах JSON. Наверное класс JSONServiceBase раньше не требовал реализации метода ServiceDefTarget.setRpcRequestBuilder.
Что ж, давайте взглянем на исходники.
Действительно, функции setRpcRequestBuilder нет.

Проект не обновляется, разбираться времени нет, так что пробуем еще один вариант gwt-json-rpc.
По инструкции подключаем библиотеку. В инструкции написано что библиотека использует свой JSON кодер/декодер, поэтому можно использовать простые типы java: String, int, boolean, Array, HashMap, ArrayList, Vector, вместо классов GWT. В общем, она даже проще, чем lovely-gwt-jsonrpc.
У меня получился следующий код.

 

//Create a new JsonRpc instance
JsonRpc jsonRpc = new JsonRpc();

//Create a callback handler
AsyncCallback callback = new AsyncCallback() {

public void onFailure(Throwable caught) {
SC.say(caught.toString());
};

public void onSuccess(Object result) {
SC.say(result.toString());
};
};
jsonRpc.request(
"http://localhost:8080/json/",
"myapp.sayHello",
null,
callback);

Что такое SC смотрим здесь.

После запуска мы обнаруживаем, что все результаты попыток вызова функции попадают в onFailure. Обусловлено это скорее всего тем, что сервер Django и сервер gwt находятся на разных портах, а это противоречит Same Origin Policy.
Далее, я скомпилировал проект, чтобы скопировать его в статический путь в проекте Django, и запустить под сервером Django, чтобы не нарушать SOP. И обнаружил, что CsrfMiddleware не дает скомпилированному gwt приложению делать POST запросы. Но мы знаем, что фрейморки, вроде jQuery позволяли это с легкостью делать. А все потому, что gwt-json-rpc при создании RequestBuilder не создает заголовок вида "X-Requested-With: XMLHttpRequest", поэтому django (точнее middleware) считает, что запрос сделан с другого домена, и возвращает ошибку 403. Значит надо сообщить ему об этом. AJAX запросы считаются безопасными и не нуждаются в проверке, так как современные браузеры придерживаются SOP. Придется добавить данный заголовок в код библиотеки и пересобрать ее. Разработчику проблему описал. Может быть на момент прочтения статьи в ней будет прописан данный заголовок (функция JsonRpc.request):

builder.setHeader("X-Requested-With", "XMLHttpRequest");

Я его добавил сам и сделал новый jar. Компилируем проект, копируем в путь для статики в django, и проверяем - все должно работать.
Остался один ньюанс - работа в дебаг режиме и ajax запросы. Не будем же мы каждый раз компилировать проект, тем более терять все прелести дебага. Воспользуемся HTTP proxy servlet.
Качаем сервлет, копируем в папку WEB-INF/lib, правим web.xml, у меня примерно следующее:


HttpProxy
com.jsos.httpproxy.HttpProxyServlet

host
http://localhost:8080/json/




HttpProxy
/json/


Меняем путь запроса:

jsonRpc.request(
"/json/",
"myapp.sayHello",
null,
callback);


и проверяем работу в дебаг режиме.

Вот и все. Удачной разработки.

22 декабря 2009 г.

GWT. Передача параметров в GWT

Этой серией буду учиться вместе с вами, как работать с GWT в виде фронтенда и Django в виде бекенда. Пишу простым языком, так как сам разбираюсь в процессе.

Для начала надо научиться передавать параметры в GWT. Первая и основная причина - идеология django - нельзя жестко использовать url адреса. Django для этого предоставляет множество средств, как то и специальный тег url в шаблонах, и специальную функцию reverse для использования в коде. То есть смысл определяется тем, что нельзя использовать url напрямую где бы-то ни было, кроме определения его в файле url.py. Любое изменение конфигурации url'ов в url.py не должно приводить к поломке приложения. В общем, для запуска GWT фронтенда нам необходим набор url-ов определенных в бекенде для ajax запросов.

На стороне Django мы используем тег {% url %}, и выводим url'ы ajax запросов с помощью него, с этим все понятно. Но как их передать в GWT?

Так как GWT и находится в клиентском окружении javascript окна, то мы можем передать параметры в темплейте Django как словарь javascript:



И получить эти url'ы в GWT:


public void useURLsDictionary() {
Dictionary URLsDict = Dictionary.getDictionary("ajaxsUrls");

String ajaxUrl1 = URLsDict.get("ajaxUrl1");
String ajaxUrl2 = URLsDict.get("ajaxUrl2");

}

16 декабря 2009 г.

Google Web Toolkit 2, Eclipse, SmartGWT

Google Web Toolkit - В Google Web Toolkit (GWT) интерфейс AJAX пишется на языке программирования Java, а затем GWT кросс-компилирует его в оптимизированный JavaScript, автоматически работающий во всех основных браузерах. При разработке можно быстро проходить по привычному для разработчиков JavaScript циклу "изменить – обновить – посмотреть", а также отлаживать код Java построчно.

Eclipse (/iˈklɪps/, от англ. затмение[1]) — свободный фреймворк для разработки модульных кроссплатформенных приложений. Разрабатывается и поддерживается Eclipse Foundation.
Наиболее известные приложения на основе Eclipse Platform — различные «Eclipse IDE» для разработки ПО на множестве языков (например, наиболее популярный «Java IDE», поддерживавшийся изначально, не полагается на какие-либо закрытые расширения, использует стандартный открытый API для доступа к Eclipse Platform).

SmartGWT - Полная библиотека виджетов, основана на JS библиотеке SmartClient. Главная особенность- позволяет связывать пользовательские виджеты с серверными компонентами. Что позволяет делать управление данными на стороне сервера. Серьезный конкурент библиотеке Ext GWT. Распространяется как по платной так и бесплатной лицензиям. В платной лицензии есть возможность использования Enterprise объектов и визуального редактора виджетов.

Смысл ясен. Надо соединить все это вместе.

1. Скачиваем eclipse для java.
http://www.eclipse.org/downloads/

2. Ставим поверх Web Tools Platform (WTP) Project.
http://www.eclipse.org/webtools/

3. Ставим GWT plugin для eclipse.
http://code.google.com/intl/ru/eclipse/docs/getting_started.html

4. Создаем проект Web Application Project.


5. Скачиваем SmartGWT.
http://code.google.com/p/smartgwt/

6. Заходим в свойства проекта, добавляем в Java Build Path -> Libraries - Add External JARs библиотеки:
smartgwt.jar
smartgwt-skins.jar (если вы планируете изменить скин, в обратном случае, скин по умолчанию находится в основной библиотеке)

7. Заходим в директорию war, добавляем в главном html файле перед основным подключенным js файлом следующее (для указания пути статики SmartGWT):



8. Добавляем в ModuleName.gwt.xml:



9. В классе EntryPoint (точка входа нашего приложения) ищем функцию onModuleLoad();
Пробуем SmartGMT, дописывая следующее:

SC.say("Привет, мир!");

Плюс импорт в начало:

import com.smartgwt.client.util.SC;

10. Жмем Debug, переходим по адресу, который отображает консоль Develompment Mode, устанавливаем плагин для Вашего браузера.
Видим примерно следующее:

Далее работает в обычном режиме - точки останова, дебаггинг и прочее.

11. Компиляция для опубликования.


12. Ну и пощупать SmartGWT online можно здесь, а gwt - здесь.

ps. К сожалению плагина для Google Chrome под linux нет. Выражены некоторые надежды на появлении его в пятой версии браузера.
К счастью разработку это не затормозит, так как есть версия плагина для Firefox.

8 декабря 2009 г.

CppCMS — C++ Web Framework

Нашел довольно интересный проект. Называется CppCMS. Несмотря на название - это не CMS - это фреймворк. Многие идеи взяты из django, как ни странно. Как я понял, разрабатывает его один человек.

Что может:
- Разные API веб серверов – FastCGI, SCGI, CGI
- Разные рабочие модели: single thread, thread pool, prefork.
- URL маппинг.
- Система шаблонов.
- Кешировние (в памяти, в расширяемой памяти и распределенном режиме)
- Простая обработка HTML форм и верификация данных с них.
- Интернационализация, включая поддержку языков RTL (справа налево).
- Библиотека простого доступа к SQL.
- Простое конфигурирование.
- Прозрачное управление сессиями, используя различные механизмы: зашифрованные куки, кэш, базу данных, распределенные по сети и их различные комбинации.

Довольно-таки неплохой наборчик.

А что будет в версии 1 (выйдет через месяца три, как я понял)?
А вот что:
- Стабильное и обратно совместимое API и ABI между минор релизами.
- Полная документация на Doxygen.
- Сокращение зависимостей от сторонних библиотек.
- JSON - теперь формат внутреннего представления данных и управления конфигурацией.
- Поддержка событий
- Поддержка технологии Comet/Server Push.
- Поддержка синхронного и асинхронного JSON-RPC, как главного формата коммуникации между приложениями фреймворка.
- Поддержка Win32 через Mingw.
- Внутренний Веб сервер для разработки или запуска через http-прокси.

3 декабря 2009 г.

Google открыл публичные DNS серверы

Раньше как-то пользовался OpenDNS (провайдер не мог добиться стабильной работы своих DNS серверов). Но он кое чем меня не устраивал.

Теперь google открыл свои публичные DNS сервера. Их адреса:

8.8.8.8
8.8.4.4

Ну и статья как их использовать.