OrgaMon-next: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Zeile 42: Zeile 42:
  Server: "valid"
  Server: "valid"


=== 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


== OrgaMon-GUI (Ausblick) ==
== OrgaMon-GUI (Ausblick) ==

Version vom 3. November 2010, 18:32 Uhr

OrgaMon-Sprach-Basis

  • OrgaMon soll einen Kernel haben, der auf "C" oder "C++" basiert - ich will vom Delphi wegkommen, da es kein OpenSource ist
  • ECommerce und Verarbeitung soll in einer IDE+Debug fähigen sprache verfasst sein, welche ist eigentlich egal. Doch der Kunde drausen um einen Break-Point setzen können und neben einem "grauen" Sprachbereich seinen eigenen COde eintragen können. Dazu öffenet das OrgaMon System Kopplungspunkte.


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

OrgaMon-Web

OrgaMon Ghost

(1:1 instanzierung des Applikationsserver)

Mit einem OrgaMon-Client kann man auch eine extra gestartete Ghost Instanz (1:1 Beziehung) des OrgaMon über eine TCP/IP Verbindung konnektieren. Ein Dispatcher hilft dabei bei der Konnektierung zwischen Client und Ghost, ev. auch mal bei einem Re-Connect.

Buisiness-Logik Funktionen werden auf dem Migrationsweg zunehmend über "Interfaceable" Datenmodule abgewickelt. Im OrgaMon müssen nun Datenmodule entweder ...

  • lokal konnektieren, dann läuft die Funktion über die lokale CPU ab, sie operiert dabei mit der angegebenen Datenbank und dem angegebenen Dateisystem.
  • remote konnektieren, die Funktionsaufrufe werden sequenzialisiert und zum remote übertragen. Dieser führt den Code unter veränderung der dortigen Datenbank und des dortigen Dateisystems aus. Der Rückgabewert wird wiederum über TCP versendet.

Es ist möglich dass im Rahmen der Codeausführung Syncronisationsaufgaben (Serverdateisystem<->Clientdateisystem) vorgenommen werden müssen. Entsprechende Anfragen muss die entsprechende Routine dem Interface mitteilen, da VOR Zurückkehren der Routine auch das Dateisystem sychronisiert sein muss!

während der Laufzeit muss eigentlich das Interface nahtlos austauschbar sein.

Entstehen nun auf dem Remote neue Dateien, so wir als Funktionsergebnis das initiieren eines FTP Downloades gefordert, der Client holt sich also die Ergebnisse über FTP ab, und spiegelt sie auf der lokalen Platte nun wieder.

lokale Aktionen

Datenbank-Caching

Da Datenbankabfragen mit teilweise sehr grossen Antworten "select * from" einhergehen in Verbindungs damit dass ofmals ein "Refresh" notwendig ist. Ist das Caching von Datenbank-Werten erlaubt und wird durch eine besondere Technik unterstützt.

Client->Server: SQL-Anfrage
Server->Client: Cache_ID & Antwort-Paket
später
Client->Server: SQL-Anfrage (identisch)
Server: Cache_ID

oder auch
Client->Server: Cache_ID?
Server: "valid"

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

OrgaMon-GUI (Ausblick)

farbige Tabs

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).

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

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 Möglichkeiten

Technologie Review

aktuelle Tendenz

OrgaMon versucht wie OpenOffice eine ganz normale Anwendung zu sein die für verschiedene Plattformen compiliert werden kann. Ev. macht sie auch Gebrauch von den jeweiligen Möglichkeiten des Betriebssystems ...

veraltet

GUI ist immer im Browser als Web 3.0 Anwendung, es gibt einen passiven Content-Provider, ev. eine PHP Apache-Kombination. Aktuelle Formulare sollen jedoch rein aus einem JSON Interface gewonnen werden, die Kommunikation erfolgt direkt zwischen XMPRequest und dem aufgebohrten cXMLRPC (der ja auch mal unter Linux laufen soll).

  • Wie das Design der Fomulare erfolgen soll weiss ich noch nicht (also mit welcher IDE, XML Definitionen, ...)
  • Die Bedienelemente sollen ganz einfach beginnen und dann Schritt für Schritt mächtiger werden
  • 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?)