OrgaMon-next

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
  • OrgaMon setzt wo immer möglich die Programmiersprache Object-Pascal ein.
  • Als Compiler werden Free Pascal (Open Source), Delphi (Kommerziell)
  • der eCommerce-Kernel soll Schritt für Schritt Kopplungspunkte bekommen wobei Kunden dann Anpassungen machen können. Das Customizing sollte aber auch wieder Open-Source sein und auch Test-Cases beinhalten so dass es für andere Kunden Regeressionsfrei bleibt. Lazarus soll auch für Kunden eine Möglichkeit sein, auf den Code einfluss zu nehmen.

OrgaMon UI

Aussehen

UI Ideen

ein Projekt, das zum Ziel hat den OrgaMon mit einer Plattform-übergreifenden GUI anzubieten

farbige Tabs

  • Tab sind erst mal nicht da, können aber aus einem Suchbegriff oder einem Befehl frisch erzeugt werden. Wird z.B. ein Vertrag angewendet entstehen ev. ganz viele neue Beleg, ein Beleg wir als ein einzelner Tab angezeigt.
  • Standard-Aktionen sind auf Tabs anwendbar und können als transaktion auf Gruppen von TAbs angewendet werden.
  • Eine aktuell eingerichtete Tab-Gruppe (3 Personen und 2 Beleg und 1 Vertrag) kann in einer Tab-Historie gespeichert werden.
  • Tab-Favoriten gibt es auch, auf die "Umgeschaltet" werden kann aber auch "dazugeladen" werden kann.
  • man kann mehrere Belege öffnen und gleichzeitig bearbeiten. Dazu "Zieht" man sich einen neuen Tab. Tabs aus der selben Gruppe haben die gleiche Farbe und sind immer zusammen angeordnet (Gruppe schliessen).
  • Es gibt einen Neu Tab.
  • Ein Langer gehaltener Klick auf einen Tab erzeugt einen "Drag"-Event

Tab-Funktionen

Anklicken: Der Tab-Inhalt kommt nach vorne, jetzt erst wenn der TabInhalt sichtbar ist wird das kleine "close" sichtbar.

Progressbereich

  • zeigt zentral aktuelle Wartezeiten an, im Hilfehinweis oberhalb laufen Log meldungen
  • ich bin unsicher, ob dies durchführbar ist, aber ich will eine Unstoppable GUI die einfach nur Anforderungen an eine Exekutive weitergibt. In dem Progressbereich stapeln sich einfach Aufgaben, die im Moment am laufen sind und noch nicht abgeschlossen (Beispiele Dafür: Tagwache auf einem Server, Tagesabschluss auf einem Server, Anwendung von Verträgen usw.)

Suchbereich

OrgaMon ist (wieder) über Hotkeys steuerbar: <ctrl>PN macht "Person" "neu" der Focus steht beim Vornamen usw.

blauer Aqua-Button

der Start-knopf des OrgaMon, hier kommen die ganzen früheren Menü Möglichkeiten


Implementierung als https://

  • 22.12.2016: Das Konzept des OrgaMon 9 steht:
  • GUI ist ...
  • immer ein Firefox-Client ab Rev. 50+
  • Server ist cOrgaMon, er bietet ausschliesslich
  • immer systemd Socket Aktiviert
  • immer https:// (https/2)
  • immer html5 und JavaScript, immer generiert aus eigenen Quellen, nach Möglichkeit keine Meta-Ebene auf dem Client, alles direkt und "nativ"
  • immer eine lang stehende Keep-Alive TCP Verbindung, mit Full Reconnect und Client-IP-Change Möglichkeit
  • kein HTTPS Server wie Apache oider nxing
  • eigene Session Verwaltung über die Datenbank
  • Die Bedienelemente sollen ganz einfach beginnen und dann Schritt für Schritt mächtiger werden
  • Der Server soll ETAG fähif sein, insbesondere für Daten-Requests, Also: Der Client frägt ein Dataset ab, ist es unverändert bekommt er nur das ETAG

offene Fragen:

  • Wie das lokale Dateisystem angesprochen werden soll weiss ich noch nicht
  • Wie das Design der Fomulare erfolgen soll weiss ich noch nicht (also mit welcher IDE, XML Definitionen, ...) Formulare sollen jedoch in der Datenbank stehen
  • In einer Übergangsphase soll ein Webkit in den OrgaMon.exe integriert werden (der OrgaMon wird z.B. auch einen Magnetstreifen scannen müssen, oder Datensicherung machen, oder den Computernamen abfragen, oder?)
HTML5-
Client  <--https/2--> systemd Socket Activation <---sd_listen_fds()---> hOrgaMon Web Server    <--fbclient----> FirebirdSQL
                                                                        (links libsystemd.so)   +--file I/O---> .\OrgaMon\

UI Benutzer-Grundgesetz

Im Zentrum einer GUI müssen unverhandelbare Grundrechte des Benutzers / Bedieners stehen. Auswüchse die es im Moment gibt (Wir sind immer noch in der IT-Steinzeit) müssen verhindert werden.

§1 Fokus

Der Eingabefokus darf niemals programmgesteuert dem aktuell sichbaren Eingabefeld entzogen werden. Das Einblenden eines Meldungsfensters während der Benutzer eine Eingabe tätigt ist ein solcher Fokusentzug. Ein Notifikationsbereich ist erlaubt.

§2 Sichtbarkeit

Eingabebereiche dürfen nicht unmotviert überdeckt oder verschoben werden. Bei einer Grössenänderung muss das Zentrum (=Position des Eingabe-Cursors) beibehalten werden.

§3 Verfälschen

Direktes Abändern der Eingabe, also automatisches vervollständigen, automatisches Setzen eines Punktes usw. ist nicht erlaubt.

§4 Klicksichtbarkeit

Ein Klick auf Controls, die erst wenige ms sichtbar sind, darf nicht als eingabe gewertet werden.

§5 Reaktivität

Die GUI darf niemals auf Ergebnisse des Arbeitsprozesses warten, der Job wird an der Theke abgegeben, die GUI ist sofort wieder aktiv.

§6 Feedback

Ausgelöste Aktionen muss ein Feedback auf der GUI erzeugen

§7 Pausen

Jede Eingabe muss zurückgestellt werden können. Eingaben auf anderen Formularen müssen dann möglich sein

§8 Variante

Jedes Formular muss dupliziert werden können. Es muss Testeingabe / Versuche verkraften ohne dass eine Aktion durchgeführt wird, erst anschließendes "Buchen" führt zur Aktion oder eben "Abbruch"

§9 Rückgängig

Jede lokale Eingabe die noch nicht "abgeschickt" ist, muss rückgängig gemacht werden können

ServerSide-ClientSide

  • Es ist mir klar dass Clientside Code in JavaScript bekommen muss, ich will aber dennoch in .pas Modulen diesen Code in Pascal Programmieren.
  • Motto: "Es gibt nur ein Rudi Völler"
    • Es muss also der Pascalcode in JavaScript umgewandelt werden
    • Es muss klar sein, dass dieser Code auf der ServerSeite ga nicht ausführbar ist, bzw. erreichbar ist
    • Ich hab noch keine Ahnung wie genau das funktionieren soll
    • Es soll alles in der Lazarus IDE programmierbar sein
    • Es soll alles auch in der Lazarus IDE mit Break-Points programmierbar sein, die IDE soll ein Verständnis haben welche Zeile welchen Code verbirgt
program SimpleCalculator;

var
 Panel : TPanel;
 Button1 : TButton;
 Button2 : TButton;
 
procedure Panel.OnClick;
begin
 beep; // This goes to JavaScript Client Code
end;

procedure Button1.OnClick;
begin
 Button2.Disable; // This goes to JavaScript Client Code
end;

procedure Button1.OnClick;
begin
 Button2.Disable; // This goes to JavaScript Client Code
end;

begin
 App.add(Panel);
 App.add(Button1);
 App.add(Button2);
end.


  • die IDE soll ein Verständnis haben dass auf Client-Seite nicht "alles" Programmierbar ist
  • aus den JavaScript Parts soll über einen Dispatcher der nonGUI Code aufbar gemacht werden
  • In einer Datenbank soll das Know-How für die Web Objekte gespeichert sein

Interface-Caching

sagen wir mal, wir haben:

type
 DataModuleeCommerce = class(GhostAbleInterface)
 
 published
  TodaySettings : TStringList;
 end;

wir sagten ja ein lokaler OrgaMon kann auf TodayStrings zugreifen, als wäre das lokal

Paralleles Arbeiten

  • Klar ist: Ein OrgaMOn Prozess ist für eine TCP/Connection zuständig
  • Intel Parallel Building Blocks (PBB)
  • OpenMP

Links