Frage nach den richtigen Werkzeugen und dem Vorgehen

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Benutzeravatar
sparrow
User
Beiträge: 4195
Registriert: Freitag 17. April 2009, 10:28

Hallo liebes Forum,

ich bin gerade dabei ein Projekt zu starten. Jetzt habe ich Angst, dass ich vielleicht ein Werkzeug, ein Modul, irgend etwas übersehen habe, weil mir einfach der Überblick fehlt.

Es geht darum, dass an verschiedenen Stellen (im Sinne von Orten) Daten erfasst werden sollen. Dafür würde ich gerne ein Qt basierte Oberfläche verwenden, weil die mit dem Designer recht schnell erstellt sind und die klassischen GUI-Elemte damit ganz gut so auf das Layout gesetzt werden können, dass im Zweifelsfall Tastatur- und Touchbedienung möglich sind (es handelt sich nicht um mobile Geräte).

Die erfassten Daten müssen in einer Datenbank gespeichert werden.

Zusätzlich muss es noch eine Art "Leitstand" geben, den man verwenden kann um Informationen über die Daten zu erhalten.
Da schwebte mir eine Webbasierte Oberfläche vor, weil man mit Hilfe der Hyperlinks sehr schön durch die Daten navigieren könnte.

Die Frage ist was ich wofür nehme. Ich habe an Django für die Weboberfläche gedacht. Der Vorteil wäre, dass ich damit auch die Datenmodelle definieren könnte und mir Anfangs die Programmierung deren Oberfläche zum Pflegen sparen könnte, weil ich die Pflege einfach über die Admin-Oberfläche erledigen könnte.

Was mache ich mit den Qt-Clients? Benutze ich SQLAlchemy um mit der Datenbank zu sprechen? Dann pflege ich die Modelle doppelt. Verwende ich die Modelle aus dem Django-Paket? Oder setze ich requests an den Webserver ab, weil der ja eh die Datenbasis verwaltet?

Ich sehe im Moment folgende mögliche Optionen:
  • Qt-Clients als Erfassungsprogramme mit SQLAlchemy auf der Datenbank
  • Weboberfläche mit Bottle über SQLAlchemy auf der Datenbank
  • Nachteil: Ich muss die Oberflächen zum Verwalten der Stammdaten von Anfang an selbst bauen
  • Qt-Clients holen sich die Daten via HTTP-Requests aus der Webanwendung
  • Weboberfläche mit Django.
  • Hat den Vorteil, dass ich die Admin-Oberfläche von Django für die Datenpflege nutzen kann.
  • Hat den Nachteil, dass die Kommunikation vom Qt-Client über HTTP-Requests einige Vorteile der direkten Kommunikation mit der Datenbank kaputt macht. Zum Beispiel das kurzfristige Sperren von Datensätzen auf der Datenbankebene.
Welches Vorgehen würdet ihr empfehlen? Habe ich etwas übersehen?

Gruß
Sparrow
Sirius3
User
Beiträge: 17754
Registriert: Sonntag 21. Oktober 2012, 17:20

Hallo sparrow,

das Datenbankmodell zwei mal in Python nachzubilden ist umständlich.
Man kann sowohl in Django ein SQLAlchemy-Modul einbinden als auch
das Django-Modell ohne Webserver als DB-Client verwenden.

Je nach Anzahl der Anwender und Komplexität der Dateneingabe würde
ich aber auf eine komplett Browser-basierte Umgebung setzten.
Warum sich die Mühe machen, sowohl einen Server als auch einen QT-Client
zu warten?

Grüße
Sirius
Benutzeravatar
sparrow
User
Beiträge: 4195
Registriert: Freitag 17. April 2009, 10:28

Vielen Dank für deine Antwort!

Das hatte ich mir zwischenzeitlich auch gedacht, allerdings bräuchte ich für den Client, also dort wo die Dateneingabe geschieht, eine Oberfläche, die sich gut auf einem Touch-Bildschirm bedienen lässt.
Rein vom Gefühl her habe ich die schneller im QT-Designer gebaut, als mir die Funktionalität in Javascript nachzubauen, damit es große Buttons gibt.

Außerdem muss der Client drucken können. Das macht mir im Moment noch Bauchschmerzen bei einer Browser-basierten Lösung. Mehr oder weniger automatisch sollen zum Beispiel Etiketten gedruckt werden. Das wird aus dem Browser heraus schwierig. Ich könnte den Drucker über das Netz ansprechen, und vom Server den Druckauftrag senden... aber richtig fühlt sich das nicht an.
BlackJack

@sparrow: Es gibt ja JavaScript-Bibliotheken um für Smartphones Anwendungen zu entwickeln. Die müssten ja auch „touch-freundlich” sein.

Was bedeutet „mehr oder weniger automatisch” beim Drucken? Könnte man die Webanwendung PDFs erzeugen lassen, die der Anwender dann druckt?
Benutzeravatar
sparrow
User
Beiträge: 4195
Registriert: Freitag 17. April 2009, 10:28

Das ganze dient der Kennzeichnung von Produkten.
Das ganze ist ein Touchscreen (um das Ganze möglichst simpel zu machen) und daneben ein Etikettendrucker. Der Anwender stellt nun am Touch verschiedene Parameter ein, die das System im Hintergrund erfasst.
Aus dem Drucker sollten dann die entsprechenden Etiketten kommen um den Artikel zu kennzeichnen. Kurzer Name und Barcode am Besten.
Eine PDF zu erstellen und die dann vom Anwender manuell drucken kommt glaube ich nicht in Frage. Wobei der tpyische Anwender wahrscheinlich auch niemand sein wird, der großartig viel Erfahrung am PC hat.
Das System fragt: Wieviel Etiketten, über Buttons wird die Anzahl ausgewählt, Drucker spuckt Etiketten aus.
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

Ich favorisiere eher Deinen 2. Vorschlag.

Zum Server:
Reicht Dir ein angepasstes Admin-Interface von Django für die Backendpflege, würde ich Django vorziehen.

Zu den Clients:
Da "full-featured" Browser offensichtlich ausscheiden - mit QWebkit könntest Du unter Qt auch einen abgewandelten Browser bauen, der das Drucken der Etiketten ohne PDF-Download vornimmt. Und ohne Browserfunktionalität ist mit einer JSON-Schnittstelle zum HTTP-Server auch ein Desktopclient schnell erstellt.
Sollen Smartphones als Clients herhalten, würde ich aber den Einsatz von Qt überdenken und eher auf die nativen Libs setzen. (was natürlich Entwicklungs- und Wartungskosten erhöht)
Sirius3
User
Beiträge: 17754
Registriert: Sonntag 21. Oktober 2012, 17:20

Eine zentrale Steuerung über einen Web-Service hätte den Vorteil, jederzeit die Aktivitäten der Nutzer mitloggen
zu können um schneller Probleme zu erkennen. Wird die ganze Kommunikation über eine RPC-Schnittstelle
abgewickelt, bist Du auch unabhängig von der eigentlichen Datenbank-Ebene.
Da die Datenbank nicht im ganze Netz offensteht, kann die Zugriffskontrolle auch einfacher ausfallen.

Von der Hardwareseite aus reicht für eine Web-Lösung das einfachste Android-Tablet als Client.
Kaum Konfigurations- und Wartungsaufwand, schnell austauschbar bei Defekt.

Zum Drucken kann ich nichts sagen, hängt sehr vom Modell und der Ansteuerungsmöglichkeiten ab.
Deine Vorbehalte gegen eine Zentrale Server-Ansteuerung teile ich nicht.
Benutzeravatar
sparrow
User
Beiträge: 4195
Registriert: Freitag 17. April 2009, 10:28

Guten Morgen,

vorab: vielen Dank für die vielen Gedankenstützen.

Ich habe mich dafür entschieden das Projekt webbasiert umzusetzen. Die Clients laufen also im Browser. Ich schätze die Arbeit, die ich dadurch spare, dass ich das Django-Admin-Interface benutzen kann um die Daten zu pflegen, gleicht die Mehrarbeit bei den Ansichten im Browser wieder aus.

Als großes Problem sehe ich noch das Drucken der Etiketten. Da ich noch immer auf der Suche nach einem passenden Drucker bin, konnte ich mich damit auch noch nicht ausreichend beschäftigen. Da es sich um eine Anwendung im lokalen Netz handelt, werde ich das wohl so umsetzen, dass der Server einfach auf dem Drucker druckt. Der muss dann halt über das Netz erreichbar sein.

Nochmal vielen Dank!

Sparrow
Antworten