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

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

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

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

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

1

outoftime, когда сервер работает по схеме запрос-ответ, то передаваемые данные за стейт не считаются. А уточнять то, что база - хранилище состояния смысла не имеет, это и ежу понятно)

Хранение "открытых документов" на сервере создаст ненужные сложности на самом сервере и, в большинстве случаев, просто не нужно.

0

Limor, короче, помощь я предложил, но сам тянуть ничего не буду.

0

outoftime, я понял. То, что мы тут обсуждали насчет web интерфейса - это пока все чисто гипотетически. Сейчас актуальнее разобраться с "инфраструктурой" вокруг проекта, понять, что не надо, а что надо и как это делать.
Вот думаю, что для конечных пользователей надо сайт, форум и систему автоматического обновления. Может быть это все уже готовое есть так, что бы просто зарегистрироваться и все уже заработало?

1

Сообщение от Limor сайт, форум и систему автоматического обновления

Что-то более конкретное будет?

Сообщение от Limor Сейчас актуальнее разобраться с "инфраструктурой" вокруг проекта

Даже если не хотите делать отдельно сервер, можете выполнить event-driven архитектуру, после чего обработчик событий можно убдет поменять и слать уже запросы по HTTP вместо обработки команд in-place. Словом у вас сразу сервер получится без лишних усилий. Нужно будет добавить работу с HTTP.

0

Сообщение от outoftime Что-то более конкретное будет?

Да, давайте начнем с сайта с форумом. Сайт для документации, примеров и загрузок. Форум для обратной связи. Какой лучше провайдер, на каком движке?

Сообщение от outoftime Даже если не хотите делать отдельно сервер, можете выполнить event-driven архитектуру, после чего обработчик событий можно убдет поменять и слать уже запросы по HTTP вместо обработки команд in-place. Словом у вас сразу сервер получится без лишних усилий. Нужно будет добавить работу с HTTP.

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

1

Сообщение от Limor Сайт для документации, примеров и загрузок.

github pages

Сообщение от Limor Форум для обратной связи. Какой лучше провайдер, на каком движке?

Вот это прикол, я не пишу на PHP и понятия не имею какие форумы на пыхе лучше. Если брать python, тогда самый популярный это FlaskBB

Сообщение от Limor сабжевого

subject - звучит как "сабджект", сокращение может быть "сабж" ? Предметного чтоли? Т.е. текущего, обсуждаемого?

Сообщение от Limor появится некий слой, который будет принимать HTTP запросы, транслировать их в запросы к ядру приложения, затем принимать от него данные и формировать HTTP ответ?

"Да да, но - нет." Вам нужно разобраться в том, что из себя представляет event-driven architecture. Особенно на С++, так как это потребует множество шаблонных телодвижений, понять которые без понимания конечной цели будет очень затруднительно.

0

Сейчас я представляю себе архитектуру event-driven приложения как комбинацию одного объекта-диспетчера и набора обработчиков по одному на каждую форму, таблицу данных, кнопку и т.д. Диспетчер хранит описание текущего состояния каждого подключенного пользователя в каком-то массиве и в соответствии с этим состоянием и полученным запросом передает запрос на обработку конкретному обработчику. Обработчики "не знают" о пользователях и не хранят их текущего состояния, они просто получают от диспетчера параметры запроса и возвращают результат кому указано по единому каналу. При этом они должны, как мне кажется "уведомлять" о результате обработки (успех, ошибка) некий третий тип объекта, который отобразит результат в массиве, чтобы диспетчер потом действовал правильно.

1

Limor, не, это муть какая-то. Не надо изобретать никаких диспетчеров с массивами и "обработчиками на каждую кнопку".

0

Usaga, я так понял, что вы решили быть ко мне в оппизиции? Ну, тогда ваша версия event-driven архитектуры?

1

Limor, я не в оппозиции к вам) Я просто против "архитектуры" описанной в посте выше.

Вам нужно серверную часть приложения оформить в виде набора объектов-фасадов к бизнес-логике этого сервера (UserAccessFacade, InvoicesFacade, SetupFacade, CodeListFacade и т.д.). Каждый такой объект-фасад будет представлять из себя набор логически взаимосвязанных методов. Вся сумма этих методов и будет API сервера вашего приложения. Это API можно оформить как угодно: поверх HTTP (WebAPI) или собственным протоколом.

Состояние клиентов запоминать не нужно. Каждый клиент будет (при входе в систему) получать токен безопасности, который будет передавать серверу с каждым запросом, а сервер, по этому токену, уже поймёт кто к нему обратился и что ему можно. Это не моя придумка. Это - стандартный и очень широко распространённый приём. Даже данный форум по такой схеме работает.

Ваш настольный клиент будет состоять из набора прокси-объектов, которые и будут ломиться к API сервера. Эти прокси будут полным отражением фасадных объектов сервера (вполне себе будет хорошо, если они даже будут реализовывать общие контракты - наследоваться от одних абстрактных классов или реализовывать интерфейсы).

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

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

Классическая архитектура с MVC + Proxy самое оно.

1

Usaga, у вас личный опыт с использованием MVC, или это только так, теория?

1

Limor, личный опыт, конечно же.

0

Usaga, ну тогда наверное у вас есть подробные схемы и примеры, как работает ваша архитектура?

1

Limor, я, вроде бы, и так подробно расписал. Вас какой-то конкретный момент смутил? Или в общем не понятно?

0

Usaga, да, не понятно в общем. Мне бы картинки и примеры. Они у вас должны быть, если вы этим занимались лично.

1

Limor, откуда у меня должны взяться картинки и схемы?) Разве что самому нарисовать.

По MVC есть такая замечательная статья. Я её всем рекомендую к прочтению.

По более общим вопросам я настоятельно рекомендую Эспозито, Сальтарелло: Microsoft .NET. Архитектура корпоративных приложений. Не смотрите, что там про .NET - архитектура везде общая, не зависимо от языка.

Про разделение клиента и сервера с помощью прокси, отдельно ссылки искать не вижу смысла, так как это классический паттерн Proxy. У вас на клиенте вся бизнес-логика должна скрываться за набором классов выглядящими нормальным локальным хранилищем логики, но, на самом деле, делегирующих запросы серверу по любому выбранному вами каналу. Такой приём удобен даже, когда у вас нет фактического разделения на клиент и сервер. Но, логически, такое разделение будет даже в вашем приложении, внутри одного EXE-шника. В таком случае, растащить код на клиент и сервер будет проще простого.

1

Спасибо, поизучаю.

1

Всем привет!

Я топикстартер и я продолжаю развивать свой проект свободной кроссплатформенной учетной системы с открытым кодом QBalance. Он работает у меня уже давно и надежно, с различным оборудованием. Сейчас между делом занимаюсь его распространением. Процесс инсталляции уже вроде бы отлажен. Скачать можно здесь. Документацию буду выкладывать здесь. Сообщество ВК здесь.

1

0

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

1