Вы здесь

Desktop-клиент для управления контентом сайта

4

Приветствую.
Назрела мысль и необходимость сделать десктоп-клиент для сайта на drupal.
Универсальности не требуется - всё затачивается на конкретный сайт.
Основной объект редактирования - ноды разных типов.
Требуется также авторизация по учётным данным друпала и подгрузка прав.
Задача такая:
Пользователя авторизуется, ему показываются списки нод, к которым у него есть доступ и сгруппированные по типу. Пользователь может редактировать ноды или создать новые.

Есть опыт работы с Node-Webkit

Куда стоит копать (blog api, к примеру), есть ли какие-то материалы в сети, которые могут пролить свет на оптимальные варианты решения и хорошие практики. Стоит ли вообще затею реализовывать или легче забыть и не вспоминать?

Версия Drupal: 
7.x
Вопрос задан 30.08.2015 - 22:18

Ответы

3

На самом деле, есть смысл делать настольный клиент, например, для частичного ручного обновления интернет-магазина.

  • Парсишь файл с исходными данными
  • Выбираешь записи, которые необходимо обновить
  • Кормишь сервис только нужными данными (картинки + текст)

Сделать это можно и через веб-интерфейс, но там будут сложности, например, с загрузкой только нужных картинок.

Опыт разработки REST-сервиса для Drupal показывает, что универсального решения вообще не получается, так как все жестко завязано на модель данных и, что самое интересное, используемые для ввода данных виджеты.

Второе замечание - пример с drupal.org про rest-сервисы уже не работает - сейчас требуется csrf-токен добавлять.

Если есть необходимость - могу несколько своих разработок на эту тему опубликовать.

Ответ дан 31.08.2015 - 10:46

все жестко завязано на модель данных

Вы имеете ввиду, что для каждой друпал сущности надо вручную создавать свой класс на клиенте (то, что в папке beans, если я правильно разобрался)?

Комментарий оставлен 31.08.2015 - 13:39

Можно было обойтись JSONObject-ами или Map-ами, но я решил сделать штатными pojo-шками.
Но да, структура запроса к серверу зависит от того, какая там модель и какие используются виджеты.

Например, встал на грабли с commerce-овским productReferenct-полем. Если в форме ввода использовать combobox, то надо передавать id продукта, если использовать автодополнение, то sku продукта, если использовать inline form, то объект продукта целиком. Аналогично с множественными полями - добавляем язык/und и т.п.

Хуже всего то, что подробного описания нет.
Сильно надеялся на модуль soap-сервисов, но он не генерировал wsdl для commerce, поэтому пришлось на rest-е делать.

Комментарий оставлен 31.08.2015 - 13:50

И да) На каждую сущность я делал отдельный бин, проблема была в том, что именно надо в поля этого бина складывать и как их друг в друга вкладывать. Неочевидно совершенно, ошибки от drupal-а ни о чем не говорят, чтение логов тоже - методом тыка(((

Комментарий оставлен 31.08.2015 - 13:52

Эх, еще сразу расскажу))))
theme developer + view services глючат вместе при выводе вьюшки в json - значения зачем-то оборачиваются тегами от theme dev-а.

Комментарий оставлен 31.08.2015 - 13:54

Получается, более-менее серьезное приложение связывать очень трудозатратно с друпалом. Rest толком не проработан. Максимум - моб. приложение или клиент, где надо связать одну-две сущности.

Комментарий оставлен 31.08.2015 - 14:19

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

Комментарий оставлен 31.08.2015 - 14:59

Да, думаю статья очень полезная была бы)

Комментарий оставлен 31.08.2015 - 15:58
2

ЗАЧЕМ??? ЗАЧЕМ десктопный клиент? Все технологии постепенно переходят на WEB, так как не побоюсь сказать, что на сайты уже можно заходить даже с ЧАСОВ и некоторых МИКРОВОЛНОВОК!!!

Создайте кучу вьюшек под свои нужды и ПРОФИТ!

Если всё же по каким-то неведомым причинам Вы решили пилить клиент, то вот: https://www.drupal.org/project/services

Ответ дан 30.08.2015 - 22:51
Аватар пользователя SAM
SAM
212

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

Комментарий оставлен 30.08.2015 - 23:08

Причин несколько, одна из них - необходимо объединить локальные действия и возможность получать данные с сайта, изменять их.
Общая суть такова:
Сидит админ, смотрит камеры в одном приложении, контролирует таймер в другом, смотрит и обрабатывает заявки в третьем, уведомления ловит почтой в четвертом.

Хочется сделать единое приложение, объединяющее все эти функции в одном, висящее в трее и [условно] незакрываемое, а также сигнализирующее о важных событиях.
Конечно, всё это можно реализовать через сайт, но, как минимум, при слабом канале видео в 720p c 8 камер грузить через него нет смысла.

Ну и получить бесценный опыт, чтобы потом сделать из этого мобильный клиент.

Комментарий оставлен 31.08.2015 - 00:24