CMS на десктопе

[безграмотный]

У типичной системы управления контентом (например ABOCMS) административная часть находится на сервере. Возникла идея вынести административную часть на десктоп путём создания обычного GUI приложения на C++, а на сервере оставить только скрипты ответственные за вывод информации. На десктопе будет приложение которое будет работать с локальной БД, после выполнения необходимых действий и нажатия кнопки __синхронизировать__ выполнять отсылку порции инфы с необходимыми изменениями.

Как вам кажется, насколько такая схема жизнеспособна, удобна и практична?

 

[AmdY]

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

 

[fixxxer]

Я вижу смысл только для совсем уж глубинки, куда даже ADSL не дотянулся, а диалап почасовой.

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

 

[безграмотный]

безграмотный
потому что не обеспечивают кросплатформенности и требуют скачивать клиент. а веб интерфейс подойдёт даже для работы с айфона.

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

 

[безграмотный]

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

Меня последнее время почта того же яндекса стала раздражать, слишком много javascript. На нетбуке например неудобно использовать, вместо перемотки страницы, по странице перемещается выделение сроки и т.д.

Собственно идея в том, чтобы разделить CMS на конструктор сайта (будет на десктопе) и скрипты отображения на серваке. Нативный конструктор может теоритически предоставить больше возможностей для обработки инфы и интеграции в различные интранет-системы т.е. не придётся писать алгоритмы выгрузки инфы их того же 1C и т.п. Всё будет делаться путём кликов в конструкторе и по таймеру можно отправлять на сервак. Наличие конструктора на десктопе это 100% гарантия сохранности эталонной копии данных и файлов/изображений и т.д. Плюсы на мой взгляд есть...

 

[AmdY]

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

не придётся писать алгоритмы выгрузки инфы их того же 1C и т.п

почему?

Всё будет делаться путём кликов в конструкторе и по таймеру можно отправлять на сервак

а сразу изменения на серваке не кул? надо ждать, пока набежит разница между двумя-тремя правками разных пользователей, а затем на серваке делать скрипт который будет мержить. ведь ты предлагаешь работать с копией данных, которую нужно постоянно синхронизировать?

Наличие конструктора на десктопе это 100% гарантия сохранности эталонной копии данных и файлов/изображений и т.д.

сейчас бэкапы делаются в один клик и заливаются на облачный сторадж. А то что ты описываешь не даст нужных вариантов, если файлы загружаемые пользователями, есть разные уровни доступа и т.д. получаем кучу проблем с синхронизацией и никаких плюсов (бэкапы всё равно нужны)

 

[AmdY]

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

 

[безграмотный]

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

Опыт в разработке CMS нормальный, разрабатывал ABOCMS.ru

 

[безграмотный]

почему?

Можно наделать кнопок с логическими примитивами и кликами по ним составить план запроса т.е. вместо написания логики будет последовательность кликов по кнопкам: извлечь->объединить->группировать и т.д.. Думаю это более менее понятно.

а сразу изменения на серваке не кул? надо ждать, пока набежит разница между двумя-тремя правками разных пользователей, а затем на серваке делать скрипт который будет мержить. ведь ты предлагаешь работать с копией данных, которую нужно постоянно синхронизировать?

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

В противном случае, при работе через web cms получается, что работа идёт по живому, что если два человека на серваке откроют для редактирования один и тот же документ? На клиенте это можно перехватить и обработать.

сейчас бэкапы делаются в один клик и заливаются на облачный сторадж. А то что ты описываешь не даст нужных вариантов, если файлы загружаемые пользователями, есть разные уровни доступа и т.д. получаем кучу проблем с синхронизацией и никаких плюсов (бэкапы всё равно нужны)

Уровни доступа это вопрос разработки, это решаемо.
Вот допустим нужно будет сделать из сайта каталог и записать на диск, придётся закачивать сайт в виде статического контента, а так можно просто выгрузить на десктопе в cтатический контент.

 

[AmdY]

безграмотный
1. никто не мешает конструктор делать и в веб интерфейсе, хотя для пользователей cms это мегасложно и не юзабельно.
2. при работе с одними данными можно ставить флаг занято, либо мержить потом, либо .... при твоём варианте мы имеем несколько вариантов и два пути - мержить, либо один из них не накатывать.
3.ты же писал, что данные дл вывод будут всё же на сервере, а на клиенте только управление. так что описанного тобой плюса нет. а дл вебинтерфейса нужно всего то всунуть на диск денвер и написать батник, на форуме это обсуждалось.

учитывая твой опыт мне нечем крыть, но описанный тобой подход не решает никаких проблем, добавляет только минусы и смотрится очень по нубски. ещё во времена до gear и html могли бы решаться некоторые проблемы, а сейчас локальный сторадж с лёгкостью превращает систему в оффлайн, экономит трафик и т.д., но как правило это не нужно.

p.s. у меня был опыт работы с такой cms, очень неудобно, админку нельзя было кустомизировать и дописывать свои модули без знания си и доплаты по лицензии.

 

[безграмотный]

1. никто не мешает конструктор делать и в веб интерфейсе, хотя для пользователей cms это мегасложно и не юзабельно.

В веб интерфейсе сделать конструктор сложнее, меньше возможностей, есть объективные ограничения броузера.
На счёт сложно, мне кажется кликать по кнопкам более привычно и проще чем код на php и sql писать __для пользователей__...

3.ты же писал, что данные дл вывод будут всё же на сервере, а на клиенте только управление. так что описанного тобой плюса нет. а дл вебинтерфейса нужно всего то всунуть на диск денвер и написать батник, на форуме это обсуждалось.

На серваке будут __только__ скрипты вывода информации, на клиенте будет конструктор который будет содержать весь контент, файлы, изображения и т.д, и те же самые скрипты, что на серваке.
Т.е. чтобы построить страницу на десктопе нужен будет просто php.exe, к нему прописывается путь и обработаная им страницы выводится на десктопе в броузере.

учитывая твой опыт мне нечем крыть, но описанный тобой подход не решает никаких проблем, добавляет только минусы и смотрится очень по нубски. ещё во времена до gear и html могли бы решаться некоторые проблемы, а сейчас локальный сторадж с лёгкостью превращает систему в оффлайн, экономит трафик и т.д., но как правило это не нужно.

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

p.s. у меня был опыт работы с такой cms, очень неудобно, админку нельзя было кустомизировать и дописывать свои модули без знания си и доплаты по лицензии.

Скрипты вывода можно как угодно писать, переписывать. Админку можно написать с возможностью формирования её кофигурации и т.д. Т.е. конструктор конструктора...

 

[vovanium]

такие CMS есть и сейчас, может для каких-то специализированных сайтов и будет удобно, но для большинства имхо не очень. сейчас народ старается наоборот отказываться от админки, т.е. правка контента прямо на фронте.

 

[AmdY]

1. по первому пункту приведи конкретное ограничение веб интерфейса мешающее делать такой же конструктор как и для декстоп.
2. php.exe не заменит веб сервер, а вот в варианте с денвером всё легко и будет 1 в 1 и не надо ничего устанавливать, никаких лишних действий.
3. в том же wp есть возможность предварительного просмотра. в ORM нужно просто завести плагин virsionable и у тебя будет действительно адекватный предосмотр, а не изменения поверх последнего слепка системы, который уже может устареть пока вносилась правка.
4. ага, можно, только это вразы сложнее чем сделать веб интерфейс лишённый всех недостатков вашего подхода и имеющий кучу плюсов.

самая страшна проблема - синхронизация и безопасноть, ведь клиент очень уязвим, получается что придётся делать ещё кучу серверных скриптов для проверки прав, синхронизаций и т.д. Я пока не увидел ни одного плюса вашего подхода.

 

[безграмотный]

1. по первому пункту приведи конкретное ограничение веб интерфейса мешающее делать такой же конструктор как и для декстоп.

Вот допустим буду я формировать структуру сайта путём построения дерева из привязанных страниц, буду использовать drag&drop для перетаскивания страницы в нужное место прикрепления и так же полотно на котором будет строится дерево хочу иметь возможность мышкой двигать и т.д.
Т.е. если это и можно будет на javascript сделать это будет однозначно тормозить при более менее большом уже построенном дереве страниц. А возможно мне захочется ещё и вращать построенное дерево, масштабировать и т.д.

2. php.exe не заменит веб сервер, а вот в варианте с денвером всё легко и будет 1 в 1 и не надо ничего устанавливать, никаких лишних действий.

На клиенте web сервер в принципе не нужен, обработку регулярок и его правил можно самому сделать, но можно и сам апач запускать, это вопрос реализации.
Суть в том, что человеку который апач не настраивал раньше и первый раз решил сделать сайт непонятно будет, что там в денвере прописать и т.д. ...

3. в том же wp есть возможность предварительного просмотра. в ORM нужно просто завести плагин virsionable и у тебя будет действительно адекватный предосмотр, а не изменения поверх последнего слепка системы, который уже может устареть пока вносилась правка.

Данные системы не могут устареть т.к. на клиенте хранятся актуальные данные которые заливаются на сервак, они могут быть просмотрены в том ввиде в котором будут видны посетителям сервака ещё до заливки на сервак.

самая страшна проблема - синхронизация и безопасноть, ведь клиент очень уязвим, получается что придётся делать ещё кучу серверных скриптов для проверки прав, синхронизаций и т.д. Я пока не увидел ни одного плюса вашего подхода.

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

p.s. Возможно я несколько туманно тут выразил мысли...

 

[AmdY]

безграмотный
я работал в проекте в котором было дерево в 2-3 тысячи элементов, даже ослик 6-й справлялся. да и вообще, в случае чего проще внедрить flash или java апплет, чем писать всё на сях, не говоря уже о том, сколько времени и денег понадобится лишь на ОДИН такой специфичный компонент на сях.
про денвер ты не понял, но сайт на cd сверхредкое требование и сделать его не проблема.
последний пункт про права, ты действительно не понимаешь какие опасности возникают при наличии декстоп клинта, который можно легко видоизменить или подделать передаваемый данные?

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

 

[безграмотный]

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

Сможешь подделать мне https соединение?

 

[phprus]

безграмотный
А в чем проблема? AmdY говорит не о MitM атаке, а о поддельной версии самого клиента.
Никто не мешает внедрить в этот клиент вредоносный код, который будет делать какие-либо деструктивные действия. В этом случае с сайтом будет общаться оригинальный клиент, только патченый немного.

Так-что действительно, идея с переносом админки сайта в десктопное приложение сейчас провальна. Браузеры уже достаточно быстры, чтобы отображать даже сложные интерфейсы, но самое главное преимущество в том, что браузер есть везде, а десктопный клиент можно установить только на конкретную машину с Windows, которой под рукой может и не быть.

 

[безграмотный]

безграмотный
А в чем проблема? AmdY говорит не о MitM атаке, а о поддельной версии самого клиента.
Никто не мешает внедрить в этот клиент вредоносный код, который будет делать какие-либо деструктивные действия. В этом случае с сайтом будет общаться оригинальный клиент, только патченый немного.

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

Браузеры уже достаточно быстры, чтобы отображать даже сложные интерфейсы, но самое главное преимущество в том, что браузер есть везде, а десктопный клиент можно установить только на конкретную машину с Windows, которой под рукой может и не быть.

Напоминает рекламу windows...
В топике я уже писал, что кросплатформенное приложение написать просто и речь я не веду конкретно о windows, я думаю про реализацию на windows, linux, android.
И вот скажем с планшетки или с нетбука броузер тоже сможет без тормозов сложный интерфейс отрисовать? Нет, не сможет. На планшетках под андроид браузеры "обрезанные" стоят типа opera mini, там нельзя сложный интерфейс сделать, как на десктопе...

 

[phprus]

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

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

Зачем делать так сложно, когда можно значительно проще?

 

[безграмотный]

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

Проверка идёт на серваке присланного ключа который генерится на клиенте на основе значения полученного с сервака. Каждую сессию сервак высылает новый ключ на основе которого нужно сгенерировать и выслать свой ключь. Здесь всё решаемо, это технический вопрос.

Зачем делать так сложно, когда можно значительно проще?

Проще, как у всех, сделать очередную рядовую cms? Уже сделали. Теперь хочется более серьёзную вещь сделать...