Отлов серверных ошибок {success:false}

[khusamov]

А для Ext Direct есть какие-то готовые серверные библиотеки для Node.js и PHP? Чтобы не писать с нуля реализацию протокола.

REST настолько прост, что особо и писать там нечего. С RPC не все так просто оказалось.

[nohuhu]

А для Ext Direct есть какие-то готовые серверные библиотеки для Node.js и PHP? Чтобы не писать с нуля реализацию протокола.

Для Node.js есть модуль, который ведёт один из наших ребят: https://github.com/jurisv/nodejs.extdirect. Есть даже статейка в нашем уютном бложике: https://www.sencha.com/blog/writing-...nd-in-node-js/.

REST настолько прост, что особо и писать там нечего. С RPC не все так просто оказалось.

Ага, это все так думают. Сперва. С виду-то оно "настолько простое", но как только начинаешь влазить в детали, так оттуда черти и лезут - но обычно уже слишком поздно, потому как пол-проекта уже написано, и дедлайн... Сколько я видел реализаций Ajax транспорта с серверной стороны, так либо там глюк на хаке и костылём погоняет, либо что-то, подозрительно похожее на доморощенную RPC. Зачем вам доморощенная RPC, если всё уже украдено до вас?

[khusamov]

Я правильно понимаю, что в RPC в качестве маршрута используется имя функции? В данном случае "Server.Demo.Todo.create" (взято из примера https://github.com/jurisv/extdirect....el/TodoItem.js)
То есть по сути, я могу взять любую реализацию RPC?

[khusamov]

Он на вебсокетах сделан? Или такой же медленный как REST?

[nohuhu]

Я правильно понимаю, что в RPC в качестве маршрута используется имя функции? В данном случае "Server.Demo.Todo.create" (взято из примера https://github.com/jurisv/extdirect....el/TodoItem.js)
То есть по сути, я могу взять любую реализацию RPC?

Можете взять любую реализацию Ext Direct, клиент встроен в framework, а сервер вам нужен свой. RPC это общее название технологии, Ext Direct одна из реализаций.

Он на вебсокетах сделан? Или такой же медленный как REST?

Штатная реализация на Ajax, но гораздо быстрее REST из-за пакетных запросов. Реализацию на web sockets я видел где-то в форуме. Штатной такой нет, т.к. мы всё же стараемся быть платформонезависимыми и на серверную сторону чересчур уж не лезть, а с web sockets такой фикус не прокатывает - там при любом раскладе надо окапываться на сервере по уши.

В любом случае web sockets уже потеряли смысл, ибо грядет царствие HTTP/2.0 и чем скорее оно приидет, тем лучше будет всем.

[khusamov]

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

[nohuhu]

Вам же надо было отлавливать все ошибки централизованно? Ext.direct.Manager на каждую ошибку стреляет событие exception, на себе и по шине Direct. Ловите контроллером и обрабатывайте, как нужно.

[khusamov]

Начал с этой темой разбираться. Смотрю пример. Не смог найти определение переменной Server.API (строка 40)
https://github.com/jurisv/extdirect....Application.js

где она определена???

[khusamov]

хехе я правильно понял, что переменная Server.API определяется вот таким хитрым способом?

{
            "path": "/directapi",
            "remote": true
        }

взято из файла https://github.com/jurisv/extdirect....extjs/app.json со строки 111

[nohuhu]

{
            "path": "/directapi",
            "remote": true
        }

Это один из возможных вариантов. Декларация Direct API это просто набор вложенных объектов JavaScript с перечислением классов и методов, которые сервер поддерживает. Такой объект можно создавать разными способами; каноническим подходом является генерирование куска JavaScript кода на сервере с последующим включением URI к этому коду на клиенте, как и сделано в данном примере.

Есть и более интересные варианты с динамической загрузкой деклараций и созданием Providers по необходимости. В KitchenSink есть раздел с примерами на эту тему.

Можно даже включать этот код в сборку приложения, клиенту в сущности важно лишь чтобы к моменту создания Provider объект с декларацией уже существовал.