Ищу желающих поучаствовать в проекте по созданию учетной системы

Всем добрый день!

Кому интересно поучаствовать в доведении кроссплатформенной учетной системы с открытым кодом до состояния готового продукта, пишите.
Её особенности:
- Рабочая, разрабатывается с 2011 года. Эксплуатируется в настоящее время.
- Лицензия GPL
- Написана на С++/Qt4
- Взаимодействует с OpenOffice
- Поддерживает оборудование (сканер штрих-кодов, принтер этикеток, считыватель магнитных карт, фискальный регистратор, банковский терминал). Некоторое оборудование расшаривается по сети.

Проект находится здесь
Скачать дистрибутивы можно здесь

Добавлено через 12 часов 31 минуту
Добавлю:
- База данных - PostgreSQL
- Встроенный скриптовый язык ECMAScript (типа Java). Т.е. платформа и конфигурация (в терминах 1С) разделяются.

1

Сообщение от Limor Вообще, ребята, разочаровывает ваш уровень дискуссии. Вы не умеете читать то, что написано, выхватываете только то, на что можете что-то сказать и игнорируете остальное. Не умеете признавать свою неправоту. Мыслите чёрно-белыми категориями своих незрелых шаблонов и не видите основную мысль. Короче, это уровень мышления школоты, а не профессионалов.

Да, так и есть. Вот только вы и сами в этом болоте увязле, исходя из того что "дискусия" началась чуть ли не с первого поста и сейчас пошёл 4й десяток сообщений, что печально...

Архитектурные решения:
- Я бы не стал тянуть Qt если бы надо было подключать JS в качестве скриптового языка. С моей точки зрения куда проше сразу использовать Electron
- Если бы мне пришлось использовать Postgres для базы данных, что предполагает использование клиент-серверной архитектуры, я бы сразу разбил программу на клиент и сервер. При таком подходе я бы меньше кода писал на С++ что намного улучшит качество кода (чтобы там не говорили, но на С++ писать сложнее на порядок).

Я пока слабо представляю возможности которые сейчас есть и какие потребуются в будущем. Еще мне на много ближе WEB разработка. Исходя из этого, я бы сделал API сервер отдельно и клиент отдельно. Клиент, скорее всего, делал бы в вебе. Благо веб развивается семимильными шагами, по сравнению с native разработкой, и много чего можно будет сделать в вебе. Верояно, надо будет затратить больше усилий, но по времени должно выйти также.

Как open source проект, вы можете использовать github pages, нужно в настройках репозитория выбрать откуда будут браться файлы для статического сайта проекта. Как по мне, самый удобный вариант это держать 2 ветки - одну с исходниками и вторую "gh-pages" с собранным сайтом. Пример и итоговый результат

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

Добавлено через 31 минуту
https://www.opennet.ru/opennew... ?num=48422 в подтверждение слов о том что с веб проникает на десктоп всецело.

0

Сообщение от outoftime Я бы не стал тянуть Qt если бы надо было подключать JS в качестве скриптового языка. С моей точки зрения куда проше сразу использовать Electron

Qt - отличный фреймворк для разработки настольных приложений. JS тут как возможность простого расширения функционала малой кровью. Это нормальное решение. Использование JS в проекте не значит, что теперь весь проект нужно переводить на эти веб-рельсы с Electron-ом.

0

Сообщение от outoftime Вообще, я написал с целью предложить помощь в написании сервера, форума и прочего что касается веба.

Буду очень признателен за такую поддержку.

К сожалению, я не имею никакого опыта в разработке WEB-приложений, если не считать моих давнишних опытов с установкой WEB-сервера Apache и написания простеньких html страниц, поэтому о плюсах и минусах спорить не буду, потому как не знаю. Но было бы крайне интересно поэкспериментировать с целью попробовать заменить интерфейс имеющегося приложения на web-интерфейс, хотя бы просто вывести форму справочника для начала.
Может быть для этого в приложении между GUI и Kernel каким-то образом вставить web-сервер.

Остальная часть модулей клиентской части превратилась бы в сервер приложения, который работал бы вместе с postgres на мощном сервере. Это было бы крайне интересно. Правда, не совсем ясно, каким образом обеспечивалась бы многопользовательская работа. Запуском отдельных экземпляров для каждого соединения?

Что касается разделения функционала между клиентом и сервером, у меня значительная его часть выведена на postgres в хранимые процедуры и триггеры. Это в основном поддержка целостности БД, обеспечение транзакций бухгалтерских проводок (если мы с какого-то счета что-то списали, то обязательно дожны записать такую же сумму на другой счет - обеспечение принципа двойной записи). Тут нужен внимательный свежий взгляд, чтобы увидеть дополнительные возможности для оптимизации.

1

Usaga, спасибо за поддержку!

1

Limor, что бы реализовать посоветованное клиент-серверное приложение, вам придётся вынести ВСЮ бизнес-логику на сервер, который будет "торчать" в мир своим API (лучше всего WebAPI, удобнее всего, когда клиенты десктопные и вебные). Если в вашем приложении это не заложено, то делов будет много.

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

Разделить всё на клиент-сервер было бы очень правильно, ибо был бы один централизованный сервер, одна база данных. Это правильный подход. И обслуживать удобно и все данные в одном месте.

Но ударяться в веб не стоит) Хотя клиентам было бы удобно пользоваться таким ПО просто открыв браузер.

0

Usaga, я думаю, что в мир будет торчать не API приложения, а WEB-сервер.

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

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

1

Limor, WebAPI - это и есть API поверх веб-сервера (поверх протокола HTTP\HTTPS). Такой вариант удобен в первую очередь, когда есть (предполагаются) веб-клиенты. Но удобно и для десктопа (для декстопа вообще всё в кассу).

Иначе говоря, WebAPI - веб-приложение, без HTML-разметки)

Я имел в виду такую архитектуру:

C++\Qt Клиент --> Общий сервер приложения <-- Веб-приложение (клиент)

Т.е. сервер с логикой один, но клиентов (по типам) два: настольный и вебный. Естественно, одновременно подключенных клиентов может быть дофига. Ваше маленькое веб-приложение не должно само лезть в базу, оно должно работать через основной сервер, иначе вы начнёте дублировать код в двух приложения\клиентах.

0

Насчет WebAPI спорить не буду, не знаю, не вникал.

Насчет сервера с логикой. Каждый десктоп-клиент работает со своими открытыми справочниками и документами, т.е. с собственным сервером бизнес-логики. Если подключить web-сервер к единственному серверу бизнес-логики, то все пользователи начнут "пересекаться" на общих открытых справочниках и документах. Работать будет невозможно. Тут нужен принцип "для каждого web-клиента собственный сервер бизнес-логики".

1

Limor, Нет, вы не правы. Сервер должен быть stateless. В нём можно держать кеш чего-нибудь, а вот открытые документы и справочники будут храниться на клиенте. Никаких пересечений в работе не будет. Клиенты будут запрашивать у сервера данные и будут отправлять их на обработку (логика), но "открытие документы" будут открытыми только на клиентах.

А вот concurrency на уровне базы данных неизбежен, но это решается вполне себе отработанными приёмами, в том числе и на уровне самой базы.

Просто такая архитектура распространена везде и всюду и ни у кого не возникает проблем с "пересечением пользователей".

0

Возможно мы говорим о разных типах web-приложений.

Если делать то, о чем говорите вы, то придется писать бизнес-логику (скрипты) для двух клиентов - десктоп и web.
Я предлагаю вариант только отображения содержимого форм и таблиц и принятия кликов и нажатий клавиш у клиента. Вся их обработка происходит на сервере. Клиент ничего не вычисляет, это "тонкий клиент". Вы предлагаете вариант "толстого клиента".

1

Limor, в том-то и дело, что я говорю о едином сервере для обоих типов клиентов: для настольного и вебного. И да, я предлагаю "тонкие" клиенты. Эти клиенты будут хранить только минимальное состояние, которое будет редактироваться пользователем и отправляться серверу на обработку (валидацию, сохранение, отправку куда-то, вычисление чего-то и т.д.)

Основная идея в том, что сервер будет делать всё, но помнить будет минимум. И использовать этот сервер могут разные типы клиентов (веб, десктоп, ещё что).

0

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

1

Limor, а в чём разница, если веб-сервер - есть сервер приложения?

Или вы думаете, что раз сервер работает по HTTP, то это обязательно веб-приложение на PHP? Это точно так же может быть ваше текущее приложение на С++\Qt прослушивающее порт №80 и умеющее в HTTP для обработки запросов от клиентов любых типов, но веб-сервером не являющееся.

А веб-клиент может работать со своим веб-сервером (уже настоящим веб-сервером, с PHP и блэкджеком), и просто делегировать запросы центральному серверу.

Добавлено через 3 минуты
И общаться с таким сервером вы можете в любом удобном для вас формате, а не с помощью HTML-разметки. Это может быть JSON, XML, Plain Text или ваш собственный формат. Т.е. у вас руки развязаны, то, что сервер поверх HTTP (если мы говорим о WebAPI) вообще никаких сложностей десктопу не несёт - там всё равно будет логика вся и общение не будет сложным.

Добавлено через 5 минут
Ещё раз уточню: ваш сервер приложения не обязан быть вебным (крутиться за Apach-ем или работать поверх HTTP)! Просто это было бы самым удобным решением, если есть вебные клиенты. Но вы можете работать и по собственному протоколу поверх TCP или UDP или использовать миллион других вариантов. Главное, чтобы сервер был один для всех типов клиентов.

0

Ну видимо да, что-то подобное я и имею в виду для случая web-клиента. А в случае десктопа работать нужно не через браузер, а напрямую с приложением.

Добавлено через 2 минуты
Короче, я запутался в web технологиях.

Добавлено через 1 минуту
Я так понял, что приложение само могло бы формировать HTML страницу в ответ на запрос по 80-му порту. Либо на другой порт, чтобы не занимать 80-й, оставить его для WEB-сервера.
Но можно, чтобы приложение на запрос по этому порту выдавало не HTML страницу, а данные для наполнения страницы, данные из справочника. А страницу сформирует уже WEB-сервер и затем отправит ее клиенту.

1

Сообщение от Limor А в случае десктопа работать нужно не через браузер, а напрямую с приложением.

Да блин))) Я вам уже третий пост растолковать не могу, что "сервер" не значит веб-сервер.

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

Т.е. вы можете использовать стандартные средства Qt (или сторонние) для работы с WebAPI (по сути - это общение через TCP по протоколу HTTP). И общаться любым форматом данных удобных вам, а не диктуемых чем-то.

0

Видимо лыжи у меня сегодня не едут

1

Limor, ничего страшного. Разберётесь.

0

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

Сообщение от Limor Можно сделать простенький вебный клиент только для просмотра справочников и документов, например. Без использования сторонних вещей и оборудования.

Именно так. Если веб клиент не имеет доступа к оборудованию, то и производить он с ним ничего не убдет. Но часть с LibreOffice всё же можно вынести в веб. Версия получится как мобильные версии многих сайтов, где часть функционала урезана в силу того что неудобно пользоваться на мобильном или в силу других причин.

Сообщение от Limor Каждый десктоп-клиент работает со своими открытыми справочниками и документами, т.е. с собственным сервером бизнес-логики. Если подключить web-сервер к единственному серверу бизнес-логики, то все пользователи начнут "пересекаться" на общих открытых справочниках и документах. Работать будет невозможно. Тут нужен принцип "для каждого web-клиента собственный сервер бизнес-логики".

Вот вы здесь путаетесь. Для каждого пользователя свой набор конфигураций. Как в linux, у каждого своя домашняя папка и никто не видит мою домашнюю папку, если я не даю им права.

Сообщение от Usaga Сервер должен быть stateless. В нём можно держать кеш чего-нибудь, а вот открытые документы и справочники будут храниться на клиенте.

Кхм, а база это не state разве? Почти всё можно хранить либо в postgres либо в другом хранилище (redis например), которое будет обеспечивать нужные возможности.

Сообщение от Limor десктопу ни к чему использовать web-сервер

Кхм, с точки зрения ахритектуры, если вы знаете что будете одни на сервере, может вы захотите развернуть сервер на машине где и будет desktop приложение. Но интегрировать логику сервера в клиент это тот еще гемор, проще написать один сервер как говорит Usaga, и у desktop версии будет просто больше возможностей, больше публичных URL которые будет иметь смысл дёргать.

Сообщение от Limor Я так понял, что приложение само могло бы формировать HTML страницу в ответ на запрос по 80-му порту.

Нет. Есть сервер. Просто сервер, который делает всё. Он слушает порт 80/433 и работает по протоколу HTTP/HTTP2. Всё, никаких HTML файлов, JS или CSS он не отдает. Всем этим занимается nginx.

Когда вы открываете страницу https://my.site.com/ nginx отдает гланвую страницу и набор JS скриптов (на Vue, к примеру). После чего браузер запускает эти скрипты и именно они формируют веб клиент. Они отвечают за отображение всего.

Desktop клиент встраивается аналогично, только он уже сам рендерит формы и прочие элементы управления и обращается опять на порт 80/433 и общается по протоколу HTTP/HTTP2.

0

Сообщение от outoftime Кхм, а база это не state разве?

Но сервер не база.

0

Сообщение от Usaga Но сервер не база.

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

Сервер то да, но я специально выделил всю цитату а не только часть о сервере. Да и сервер подрывается на каждый разпрос инициализируется данными с БД и опять всё туда ложит при завершении работы. Можно сказать что сервер всё таки имеет state но он "decoupled" в виде БД. И все тонкости в виде открытых документов вовсе не проблема хранить на сервере.

0