-
Gebiet der Erfindung
-
Die
vorliegende Erfindung bezieht sich allgemein auf eine elektrische
Datenverarbeitung und spezifischer bezieht sie sich auf Verfahren,
Computerprogrammprodukte und Systeme für eine Client-Server Kommunikation.
-
Hintergrund der Erfindung
-
Auf
einige Softwareanwendungen kann durch einen Benutzer unter Verwendung
eines konventionellen Web-Browsers, wie dem Microsoft Internet Explorer
zugegriffen werden. Typischerweise stellen derartige Anwendungen
eine Mehrzahl von Seiten zur Verfügung. Eine Seite beinhaltet
relevante Information für
ein graphisches Benutzer-Interface (GUI), durch welches der Benutzer
mit der Anwendung interagieren bzw. Wechselwirken kann. Die Seite
kann mehrere Komponenten beinhalten. Die Seite wird typischerweise
auf einem Server generiert und dann zu einem Client übertragen.
Bei dem Client ist bzw. wird die Seite für einen Benutzer bzw. Verwender
durch den Browser visualisiert. Wenn der Benutzer mit dem Client über das
GUI wechselwirkt, um die Seite zu erneuern bzw. zu aktualisieren,
wird das gesamte Verfahren wiederholt. Das allgemein akzeptierte
Programmdesignmuster für
das oben beschriebene Verfahren bzw. die oben beschriebene Prozedur
ist das sogenannte MVC (Model-View-Controller) Designmuster. Das
Modell, welches Anwendungsdaten für ein Sehen und Handhaben verkapselt
bzw. einschließt,
wird durch die Steuer- bzw. Regeleinrichtung bzw. den Controller
manipuliert und ist in die Ansicht gerendert. Die Ansicht entspricht
einer Seite, welche einen mit dem Browser kompatiblen Inhalt bzw.
Content beinhaltet. Es kann zahlreiche Ansichten und Controller
für jedes
Modell geben. Beispielsweise kann eine Ansicht verwendet werden,
um Daten des Modells als eine Tabelle zu visualisieren bzw. darzustellen,
während
eine andere Ansicht verwendet werden kann, um dieselben Daten als eine
Pie- bzw. "Tortenecken"-Darstellung zu visualisieren
bzw. sichtbar zu machen. All dies wird auf dem Server durchgeführt und
die komplette Ansicht wird zu dem Client gesendet. Daher erfordert
das MVC Designmuster zahlreiche CPU Zyklen und eine hohe Bandbreite
des Computernetzwerks, welches eine Kommunikation zwischen dem Client
und dem Server ermöglicht,
da die gesamte Seite (Layout Information und Daten) auf dem Server
regeneriert wird und die resultierende Ansicht von dem Server zu
dem Client über
das Netzwerk neuerlich übertragen
wird. Weiterhin ist der Benutzer mit unerwünschten Effekten konfrontiert,
wie Wartezeiten und Schirmflimmern, bis die neuerlich frisch hergestellte
Seite endgültig
dem Client präsentiert
wird.
-
Einige
konventionelle Browser, wie der Microsoft Internet Explorer IE 6.0,
beinhalten ein Feature bzw. Merkmal für ein flimmerfreies Rendern
bzw. Wiedergeben. Wenn der Client eine modifizierte Seite erhält, identifiziert
der Browser modifizierte Komponenten der Seite und ersetzt lediglich
diese Komponenten statt der gesamten Seite, beispielsweise durch
dynamische HTML Injektion bzw. Eingabe in das Dokument-Objektmodell (DOM)
der Seite. Dies führt
zu einer Reduktion eines Schirmflimmerns für den Benutzer, verbraucht
jedoch immer noch CPU Zeit (CPU Zyklen) für eine Seitengenerierung bzw.
-erstellung und erfordert weiterhin eine Bandbreite für eine Übertragung
der gesamten Seite von dem Server zu dem Client. Weiterhin erfordert
jede Benutzerwechselwirkung mit dem Client einen Serverrundgang
und ver ursacht daher eine hohe Serverlast aufgrund einer Seitengenerierung
und -übertragung.
-
Es
besteht ein fortlaufendes Bedürfnis
zum Reduzieren eines CPU Zeitverbrauchs und von Bandbreitenerfordernissen
in einer Client-Server Kommunikation und zum Reduzieren von unerwünschten
Effekten für den
Benutzer zur selben Zeit.
-
International
Business Machines Corporation: "Updating
Live HTML Pages Incrementally With Data From Webservers" Research Disclosure,
Kenneth Mason Publications, Hampshire, GB. Vol. 433, Nr. 95, Mai 2000
offenbart ein Verfahren zum Aktualisieren von lebenden HTML Seiten,
wobei, wenn eine HTML Seite aktualisiert wird, nicht der gesamte
Code und Inhalt bzw. Content der HTML Seite dem Browser übersandt
werden.
-
In
dem Dokument Lee K. et al.: "Incremental
Maintenance For Dynamic Database-Derived HTML Pages In Digital Libraries", Proceedings of
the 1998 ACM CIKM International Conference an Information and Knowledge
Management. CIKM-98, Bethesda, MD, November 3–7, 1998, ACM CIKM International
Conference an Information and Knowledge Management, New York, NY:
ACM, US, Vol. Conf. 7, 3. November 1998, Seiten 20 bis 29, XP 000895348
ISBN: 1-58113-061-9 ist ein Verfahren zum inkrementellen Aktualisieren
einer materialisierten Ansicht in einer Web- bzw. Netzumgebung geoffenbart,
wobei ein Schnappschuß der
Ansicht zu einer speziellen Referenz- bzw. Bezugszeit, beinhaltend
Ansichtsänderungen
seit der letzten Aktualisierung angezeigt ist bzw. wird.
-
Zusammenfassung der Erfindung
-
Daher
ist es ein Gegenstand bzw. Ziel der vorliegenden Erfindung, Verfahren,
Computerprogrammprodukte und Computersysteme zur Verfügung zu
stellen, um Bandbreitenerfordernisse in einer Client-Server Kommunikation
zu reduzieren, wenn Seiten erneuert bzw. überarbeitet werden.
-
Um
dieses Ziel zu erreichen, stellt in einer Ausbildung der vorliegenden
Erfindung ein Rechner- bzw. Computersystem zum Handhaben von inkrementellen
Daten gemäß Anspruch
1 die folgenden Merkmale zur Verfügung:
- a)
ein Server-Controller bzw. eine Server-Steuer- bzw. -Regeleinrichtung
empfängt
eine Modifikationsanfrage von einem Client, und modifiziert in Antwort
auf die Modifikationsanfrage ein ursprüngliches bzw. Originalmodell
einer Anwendungskomponente, welche auf einem Server gespeichert
ist, in ein modifiziertes Modell der Anwendungskomponente;
- b) ein Server-Renderer generiert wenigstens ein Browser-Inkrement, welches
dem Unterschied bzw. der Differenz zwischen dem ursprünglichen
Modell und dem modifizierten Modell entspricht;
- c) ein Client-Assembler erhält
bzw. empfängt
das wenigstens eine Browser-Inkrement von dem Server und aktualisiert
an dem Client eine Originaldokument-Objektmodellkomponente (DOM)
mit dem wenigstens einen Browser-Inkrement. Die Original-DOM-Komponente
entspricht dem Originalmodell und die Aktualisierung resultiert
in einer modifizierten DOM Komponente, welche mit dem modifizierten
Modell übereinstimmt;
- d) die Modifikationsanfrage wird durch einen Client-Controller
generiert.
-
Weitere
Ausbildungen der Erfindung sind ein Server gemäß Anspruch 10, ein Client gemäß Anspruch 11,
ein serverseitiges Verfahren gemäß Anspruch
15, ein clientseitiges Verfahren gemäß Anspruch 16, ein serverseitiges
Computerprogrammprodukt gemäß Anspruch
20 und ein clientseitiges Computerprogrammprodukt nach Anspruch
21.
-
In
einer bevorzugten Ausbildung instruiert der Client-Controller (100-2)
den Client-Assembler (100-1), die ursprüngliche oder modifizierte DOM
Komponente (300-T1, 300-T2) nach bzw. bei einem
Empfangen einer Rücksetzanfrage
zurückzusetzen.
-
Wenn
sie mit dem MVC-Muster gemäß dem Stand
der Technik verglichen wird, wo ein Modell, eine Ansicht und ein
Controller gespeichert und durch den Server bearbeitet sind bzw.
werden, verwendet die vorliegende Erfindung ein Muster, wo die Ansicht
und der Controller in serverseitige und clientseitige Abschnitte geteilt
sind. Der serverseitige Abschnitt der Ansicht ist der Server-Renderer.
Der clientseitige Abschnitt der Ansicht ist der Client-Assembler. Der serverseitige
Abschnitt des Controllers ist der Server-Controller und der clientseitige
Abschnitt des Controllers ist der Client-Controller.
-
Es
ist ein Effekt der vorliegenden Erfindung, daß die erforderliche Bandbreite
für eine
Netzwerkkommunikation niedriger ist, wenn sie mit Systemen gemäß dem Stand
der Technik verglichen wird, wo die gesamte Seite zwischen dem Server
und dem Client statt einem Browser-Inkrement ausgetauscht wird.
Häufig
wird lediglich ein kleinerer Abschnitt der Seite modifiziert. In
diesem Fall erfordert die Browser-Inkrement-Übertragung signifikant weniger
Bandbreite als die Übertragung
einer gesamten Seite.
-
Es
ist ein weiterer Effekt der vorliegenden Erfindung, daß ein Benutzer,
welcher mit dem Client wechselwirkt bzw. interagiert, einen augenerfreuenden
Effekt erfährt,
da die Aktualisierung einer DOM Komponente der Browserkomponente
mit einem Browser-Inkrement in einer flimmerfreien Änderung
des graphischen Benutzer-Interface resultiert.
-
Es
ist ein weiterer Effekt der vorliegenden Erfindung, daß der Server
es nicht erfordert, den Zustand einer Anwendung zu halten, da der
Server die Statusinformation, die er braucht, von dem Client empfängt.
-
Diese
Aspekte der Erfindung werden mittels der Elemente und Kombinationen
realisiert und erreicht, die insbesondere in den beiliegenden Ansprüchen ausgeführt sind.
Auch ist die beschriebene Kombination der Merkmale der Erfindung
nicht als eine Beschränkung
zu verstehen, und alle Merkmale können in anderen Konstellationen
kombiniert sein bzw. werden. Es ist auch zu verstehen, daß sowohl
die vorhergehende, allgemeine Beschreibung als auch die nachfolgende,
detaillierte Beschreibung lediglich exemplarisch und erläuternd sind, und
nicht für
die Erfindung, wie sie beschrieben ist, beschränkend sind.
-
Kurze Beschreibung der Zeichnungen
-
1 illustriert
ein vereinfachtes Blockdiagramm eines exemplarischen bzw. beispielhaften
Computersystems, welches Ausbildungen der vorliegenden Erfindung
implementiert;
-
2A bis 2D illustrieren
eine Implementierung eines graphischen Benutzer-Interface gemäß einer
Ausbildung der vorliegenden Erfindung;
-
3 illustriert
eine Wechselwirkung eines Client mit einem Server, wenn er gemäß einer
Ausbildung der Erfindung betätigt
wird;
-
4A, 4B illustrieren
Details einer clientseitigen Handhabung eines Browser-Inkrements
in einer Ausbildung der Erfindung;
-
5 illustriert
zwei komplementäre
Computerprogrammprodukte und ihre wesentlichen funktionellen Blöcke, welche
in einer Ausbildung der vorliegenden Erfindung verwendet werden
können;
-
6 illustriert
ein vereinfachtes Flußdiagramm
eines serverseitigen Verfahrens zum Handhaben von inkrementellen
Daten gemäß der Erfindung;
und
-
7A, 7B illustrieren
ein vereinfachtes Flußdiagramm
eines clientseitigen Verfahrens zum Handhaben von inkrementellen
Daten gemäß der Erfindung.
-
Detaillierte Beschreibung der Erfindung
-
Wo
immer dies möglich
ist, werden dieselben Bezugszeichen in den Zeichnungen verwendet,
um dieselben oder ähnliche
Teile zu bezeichnen.
-
Definitionen
von Ausdrücken,
wie sie nachfolgend hierin verwendet sind bzw. werden:
-
Client:
-
Ein
Client ist eine Computervorrichtung, die konfiguriert ist, um auf
einen Service bzw. Dienst zuzugreifen, welcher(s) beispielsweise
durch eine Softwareanwendung zur Verfügung gestellt ist bzw. wird.
Typischerweise lassen Clients für
ein Zugreifen auf Webanwendungen Web-Browser laufen, wie Netscape
Navigator, welcher auf einem PC läuft, Pocket Internet Explorer,
der auf einem PDA läuft,
oder einen WAP-Browser, der auf einem Mobiltelefon läuft.
-
Server:
-
Ein
Server ist eine Computervorrichtung, auf welcher die Anwendung läuft, auf
welche durch den Client zugegriffen ist bzw. wird.
-
Page bzw. Seite:
-
Eine
Seite beinhaltet Inhalt bzw. Content (Layout und Daten), welcher
ein graphisches Benutzer-Interface einer Webanwendung (siehe Definition
unten) definiert. Eine Seite ist bzw. wird typischerweise auf dem Server
in einem mit einem Browser kompatiblem Format, wie HTML oder WML,
gerendert bzw. wiedergegeben.
-
Komponente:
-
Eine
Komponente ist ein grundsätzlicher
Baublock einer Seite. Die Komponente existiert immer innerhalb einer
Seite. Eine Komponente kann weitere Komponenten beinhalten. In diesem
Fall wird die Komponente als eine "Eltern- bzw. Mutter-Komponente" bezeichnet und die
weiteren Komponenten werden als "Kinder-Komponenten" bezeichnet. Eine
Komponente einer Seite, welche keine Eltern-Komponente innerhalb
der Seite aufweist, wird als eine Root- bzw. Wurzel-Komponente bezeichnet.
Gemäß der Erfindung
hat eine Komponente einen serverseitigen Abschnitt, welcher auch
als eine "Anwendungs-Komponente" bezeichnet wird. Die
Anwendungskomponente existiert während
der Ausbildung bzw. Erzeugung einer Komponenten-Beschreibungseinheit
und eines Browser-Inkrements. Dies erlaubt es jemandem, einen zustandslosen
Server zu besitzen, da die Anwendungskomponente lediglich für ein beschränktes Zeitintervall
existieren kann und notwendige Statusinformation von einem Client
empfängt.
Die Komponente hat auch einen clientseitigen Abschnitt, welcher
als eine Browser-Komponente bezeichnet wird. Die Browser-Komponente
hält den
Status der entsprechenden Komponente.
-
Komponenten-Beschreibungseinheit
bzw. -Descriptor: Wenn eine Seite in ein mit einem Browser kompatibles
Format gerendert wird, wird jede Anwendungskomponente der Seite
in das mit dem Browser kompatible Format gerendert. Eine gerenderte
Anwendungskomponente wird als "Komponenten-Beschreibungseinheit" bezeichnet. Eine
Komponenten-Beschreibungseinheit kann als ein Namen-Wert-Paar implementiert
werden.
-
Webanwendung:
-
Eine
Webanwendung, wie sie nachfolgend verwendet wird, beinhaltet einen
Satz von Seiten. Ein spezifisches Merkmal einer Webanwendung ist
jenes, daß es
keinen Zustand an dem Server hält
bzw. beibehält. Mit
anderen Worten erzeugt für
jede Anfrage, die der Server empfängt, er einen Status der zugegriffenen
Webanwendung von Null bzw. Anfang an. Nachdem die Web-Anwendung
eine Ausgabe generiert bzw. erzeugt hat, wird üblicherweise der Zustand bzw.
Status verworfen.
-
Dokumenten-Objekt-Modell:
-
Gemäß der entsprechenden
W3C Definition stellt das Dokumenten-Objekt-Modell (DOM) einer Seite einen
geparsten Mechanismus zur Verfügung,
um auf einen geparsten bzw. aufgeteilten HTML und XML Inhalt bzw.
Content zuzugreifen und diesen zu manipulieren.
-
Klassenname:
-
Ein
Klassenname einer Komponente spezifiziert den Namen einer serverseitigen
Komponenten-Klasse (beispielsweise Java Klasse, Java-Server-Seiten-Klasse,
Servlet-Klasse, Pascal-Klasse, C Klasse, C++ Klasse oder Business-Server-Seiten-Klasse), welche
die Anwendungskomponente der Komponente implementiert. Die Anwendungskomponente
ist eine Instanz bzw. ein Fall der Komponenten-Klasse, welche ein
entsprechendes Modell, einen Server-Controller oder einen Server-Renderer
beinhalten kann.
-
Script-Klassen-Name:
-
Der
Script-Klassen-Name einer Komponente spezifiziert den Namen einer
clientseitigen Komponenten-Script-Klasse (beispielsweise JavaScript
Klasse, Java Applets Klasse oder VisualBasic Script Klasse), welche
eine Browser-Komponente implementiert, welche einer Anwendungskomponente
entspricht. Die Komponenten-Script-Klasse und die Komponenten-Klasse können identische
Hierarchien besitzen. Die Browser-Komponente ist eine Instanz bzw. ein
Fall der Komponenten-Script-Klasse
und kann einen entsprechenden Client-Controller, Client-Assembler
und DOM Komponente der gegenwärtigen
Seite beinhalten. Eine DOM Komponente kann einen oder mehrere DOM
Knoten beinhalten, welche(r) durch den Browser verwendet wird bzw.
werden, um die entsprechende Komponente zu visualisieren bzw. sichtbar
zu machen.
-
1 ist
ein vereinfachtes Blockdiagramm eines exemplarischen bzw. beispielhaften
Computersystems, welches Ausbildungen der vorliegenden Erfindung
implementiert. Ein Computersystem 999 beinhaltet Computer 900 und
hat eine Mehrzahl von weiteren Computern 901, 902 (oder 90q mit
q = 0...Q-1, Q irgendeine Zahl).
-
Der
Computer 900 kann mit weiteren Computern 901, 902 über ein
Computer-Netzwerk 990 kommunizieren. Der Computer 900 hat
einen Prozessor 910, Speicher 920, Bus 930 und
fakultativ eine Eingabevorrichtung 940 und Ausgabevorrichtung 950 (I/O
Vorrichtungen, Benutzer-Interface 960). Wie dargestellt
bzw. illustriert, ist die Erfindung durch ein Computerprogrammprodukt 100 (CPP),
Programmträger 970 oder
Programmsignal 980 implementiert.
-
In
bezug auf den Computer 900 wird der Computer 901/902 manchmal
als "Remote Computer" bzw. "entfernter Computer" bezeichnet, der
Computer 901/902 ist beispielsweise ein Server,
eine gleichrangige bzw. Peer-Vorrichtung oder ein anderer gemeinsamer
Netzwerkknoten, und hat typischerweise zahlreiche oder alle der
Elemente, die in bezug auf den Computer 900 beschrieben
sind.
-
Der
Computer 900 ist beispielsweise ein konventioneller Personal
Computer (PC), ein Desktop oder eine in der Hand gehaltene Vorrichtung,
ein Multiprozessor-Computer, ein Stift-Computer, eine auf einem
Mikroprozessor basierende oder programmierbare Konsumenten-Elektronik-Vorrichtung,
ein Mini-Computer, ein Mainframe-Computer, eine persönliche mobile
Computer-Vorrichtung, ein Mobiltelefon, ein tragbarer oder stationärer Personal
Computer, ein Palmtop Computer oder dgl.
-
Der
Prozessor 910 ist beispielsweise eine zentrale Verarbeitungseinheit
(CPU), eine Mikro-Controller-Einheit (MCU), ein digitaler Signalprozessor
(DSP) oder dgl.
-
Der
Speicher 920 symbolisiert Elemente, welche temporär oder permanent
Daten und Instruktionen bzw. Anweisungen speichern. Obwohl der Speicher 920 als
Teil des Computers 900 dargestellt bzw. illustriert ist,
kann eine Speicherfunktion auch in dem Netzwerk 990, in
den Computern 901/902 und in dem Prozessor 910 selbst
(beispielsweise Cache, Register) oder sonstwo implementiert sein
bzw. werden. Der Speicher 920 kann ein Nur-Lese-Speicher
(ROM), ein Direktzugriffsspeicher (RAM) oder ein Speicher mit anderen
Zugriffsoptionen sein. Der Speicher 920 ist physikalisch
durch durch einen Computer lesbare Medien implementiert, wie magnetische
Speichermedien, optische Speichermedien, Halbleiter-Speichermedien
oder durch irgendein anderes, durch einen Computer lesbares Speichermedium.
-
Der
Speicher 920 kann Supportmodule, wie beispielsweise ein
grundsätzliches
bzw. Basis-Eingabe-Ausgabe-System (BIOS), ein Betriebssystem (OS),
eine Programmbibliothek, einen Compiler, einen Interpreter bzw.
eine Interpretationseinrichtung oder ein Textbearbeitungswerkzeug
speichern.
-
CPP 100 implementiert
Programminstruktionen bzw. -anweisungen und – gegebenenfalls – Daten, welche
den Prozessor 910 veranlassen, Verfahrensschritte der vorliegenden
Erfindung auszuführen.
Mit anderen Worten kann das CPP 100 den Betrieb des Computers 900 steuern
bzw. regeln, so daß er
in Übereinstimmung
mit der Erfindung arbeitet. Beispielsweise und ohne die Erfindung
zu begrenzen, kann das CPP 100 als ein Quellcode in irgendeiner
Programmiersprache verfügbar
sein, und als ein Objektcode ("Binärcode") in einer kompilierten
Form.
-
Obwohl
das CPP 100 als in dem Speicher 920 gespeichert
illustriert ist, kann das CPP 100 anderswo angeordnet sein.
Das CPP 100 kann auch in einem Carrier bzw. Träger 970 eingebettet
bzw. verkörpert
sein.
-
Der
Träger 970 ist
außerhalb
des Computers 900 dargestellt bzw. illustriert. Für ein Kommunizieren des
CPP 100 zu dem Computer 900 wird der Träger 970 üblicherweise
in die Eingabevorrichtung 940 eingesetzt. Der Carrier 970 ist
als irgendein durch einen Computer lesbares Medium implementiert,
wie ein Medium, das grob oben erklärt ist (siehe Speicher 920).
Allgemein ist der Träger 970 ein
Gegenstand einer Herstellung, welcher ein computerlesbares Medium
verkörpert,
welches einen durch einen Computer lesbaren Programmcode besitzt,
welche verwendet werden kann, um einen Computer zu verlassen, Verfahren
der vorliegenden Erfindung durchzuführen. Weiterhin kann ein Programmsignal 980 auch
das CPP 100 verkörpern.
-
Die
Eingabevorrichtung 940 stellt Daten und Instruktionen für ein Bearbeiten
durch den Computer 900 zur Verfügung. Die Vorrichtung 940 kann
beispielsweise eine Tastatur, eine Zeigevorrichtung (beispielsweise Maus,
Trackball, Cursor-Richtungstasten),
Mikrophon, Joystick, Gamepad, Scanner oder Diskettenantrieb sein.
Obwohl die Beispiele Vorrichtungen mit menschlicher Wechselwirkung
sind, kann die Vorrichtung 940 auch ohne menschliche Wechselwirkung
arbeiten, wie beispielsweise ein drahtloser Empfänger (beispielsweise mit Satellitenschüssel oder
terrestrischer Antenne), ein Sensor (beispielsweise ein Thermometer),
ein Zähler
(beispielsweise Warenzähler
in einem Geschäft
bzw. in einer Fabrik). Die Eingabevorrichtung 940 kann
zum Lesen des Trägers 970 dienen.
-
Die
Ausgabevorrichtung 950 präsentiert die Instruktionen
und Daten, welche bearbeitet wurden. Beispielsweise kann dies ein
Monitor oder eine Anzeige sein, beispielsweise eine Kathodenstrahlröhre (CRT)
oder eine Flachbildanzeige oder Flüssigkristallanzeige (LCD),
ein Lautsprecher, Drucker, Plotter oder eine Vibrationswarnvorrichtung. Ähnlich wie
oben kann die Ausgabevorrichtung 950 mit dem Benutzer kommunizieren, jedoch
kann sie auch mit weiteren Computern kommunizieren.
-
Die
Eingabevorrichtung 940 und die Ausgabevorrichtung 950 können zu
einer einzigen Vorrichtung kombiniert sein. Jegliche Vorrichtung 940 und 950 kann
fakultativ zur Verfügung
gestellt werden.
-
Der
Bus 930 und das Netzwerk 990 stellen logische
und physikalische Verbindungen beim Fördern bzw. Transportieren von
Instruktionen und Datensignalen zur Verfügung. Während Verbindungen innerhalb des
Computers 900 üblicherweise
als ein "Bus 930" bezeichnet
werden, werden Verbindungen zwischen Computern 900–902 als "Netzwerk 990" bezeichnet.
Fakultativ beinhaltet das Netzwerk 990 Gateways, welche Computer
sind, welche auf Datenübertragung
und Protokollumwandlung spezialisiert sind.
-
Die
Vorrichtungen 940 und 950 sind bzw. werden mit
dem Computer 900 durch den Bus 930 (wie illustriert)
oder durch das Netzwerk 990 (fakultativ) gekoppelt.
-
Netzwerke
(wie das Netzwerk 990) sind in Büros, firmenweiten Computernetzwerken,
Intranets und dem Internet üblich.
Das Netzwerk 990 kann ein verdrahtetes oder ein drahtloses
Netzwerk sein. Beispiele von Netzwerkimplementierungen können Local
Area Netzwerke (LAN), Wide Area Netzwerke (WAN), öffentlich
geschaltete Telefonnetzwerke (PSTN) und integrierte Service-Digital-Netzwerke
(ISDN) sein. Andere Beispiele von Netzwerkimplementierungen sind
in der Technik bekannt.
-
Eine
Vielzahl von Übertragungsprotokollen
und Datenformaten ist bekannt, beispielsweise das Transmission-Control-Protocol/Internet-Protokoll
(TCP/IP), Hypertext-Transfer-Protokoll
(HTTP), sichere HTTP (HTTPS) oder drahtlose Anwendungsprotokoll
(WAP).
-
Interfaces
bzw. Schnittstellen, die zwischen den Elementen gekoppelt sind,
sind ebenfalls in der Technik gut bekannt. Der Einfachheit halber
sind Interfaces nicht illustriert. Ein Interface kann beispielsweise
ein Interface mit seriellem Port, ein Interface mit parallelem Port,
ein Spielport, ein Universal Serial Bus (USB) Interface, ein internes
oder externes Modem, ein Videoadapter oder eine Tonkarte sein.
-
Computer
und Programm sind eng miteinander in Bezug. Wie dies nachfolgend
verwendet wird, sind Phrasen, wie "der Computer stellt zur Verfügung" und "das Programm stellt
zur Verfügung" übliche Abkürzungen, um Tätigkeiten
durch einen Computer auszudrücken,
welcher durch ein Programm gesteuert bzw. geregelt wird.
-
2A bis 2D illustrieren
eine Implementierung eines graphischen Benutzer-Interface 955 gemäß einer
Ausbildung der vorliegenden Erfindung an vier aufeinanderfolgenden
Zeitpunkten T1, T2, T3 und T4.
-
Das
folgende Beispiel einer Benutzerwechselwirkung mit dem graphischen
Benutzer-Interface 955 wird durch die gesamte Beschreibung
verwendet, um weiter die vorliegende Erfindung zu erklären. Jedoch kann
irgendein graphisches Benutzer-Interface
gemäß der vorliegenden
Erfindung implementiert sein bzw. werden. Beispielsweise wird ein
GUI 955 dem Benutzer auf der Ausgabevorrichtung 950 (siehe 1)
des Client-Computers 900 (siehe 1) präsentiert
und der Benutzer interagiert mit dem GUI 955 unter Verwendung der
Eingabevorrichtung 940.
-
Das
GUI 955 ist ein graphisches Benutzer-Interface, welches
es dem Benutzer ermöglicht,
mit hierarchischen Daten wechselzuwirken bzw. zu interagieren, welche
durch Knoten eines Baums 955-1 visualisiert sind. Beispielsweise
sind bzw. werden die hierarchischen Daten auf dem Server-Computer 901 (siehe 1) gespeichert.
Jedoch können
die Daten auf irgendeiner Speichervorrichtung des Computersystems 999 (siehe 1)
gespeichert sein. Der Benutzer kann auch den Baum 955-1 durch
Verwendung eines RESET (-Knopfs) 955-2 zurücksetzen.
Der Status von jedem Knoten des Baums 955-1 wird durch
ein Minus-Vorzeichen (–)
oder ein Plus-Vorzeichen (+) angedeutet. Das Minus-Vorzeichen zeigt
an, daß der
Status eines Knotens erweitert ist. Das Plus-Vorzeichen zeigt, daß der Status
eines Knotens kollabiert bzw. zusammengefallen ist. Beispielsweise
kann durch ein Anklicken eines Knotens der Benutzer den Status des
Knotens von zusammengefallen (+) zu expandiert (–) oder umgekehrt verändern.
-
In 2A wird
bei T1 der Benutzer mit dem Baum 955-1 aufgefordert, wobei
die Zustände
der verschiedenen Knoten sind:
Wurzelknoten R1: expandiert
(–); Kindknoten
FL1, FL2; Knoten FL1 ersten Niveaus: expandiert (–); Kindknoten:
SL1, SL2;
Knoten FL2 ersten Niveaus: zusammengefallen; und
Knoten
SL1, SL2 zweiten Niveaus: zusammengefallen (+).
-
Beispielsweise
wählt der
Benutzer den Knoten SL2 zweiten Niveaus für ein Expandieren (beispielsweise
durch ein Anklicken des Knotens) aus. Nachdem er die Auswahl des
Benutzers empfangen hat, wird der Baum 955-1 entsprechend
verändert.
-
In 2B wurde
bei T2 der Status des Knotens SL2 zweiten Niveaus verändert in:
expandiert (–); Kindknoten
TL1. Der Knoten TL1 dritter Schicht wird zu dem Baum 955-1 als
ein Kindknoten des Knotens SL2 zweiter Schicht hinzugefügt. Dann
wählt beispielsweise
der Benutzer neuerlich den Knoten SL2 zweiten Niveaus für ein Zusammenfallen
bzw. Kollabieren (beispielsweise durch ein Anklicken des Knotens)
aus. Nachdem die Auswahl des Benutzers empfangen wurde, verändert der
Client 900 den Baum 955-1 entsprechend.
-
In 2C wurde
bei T3 der Status des Knotens SL2 zweiten Niveaus zurück verändert zu:
zusammengefallen (+). Der Knoten TL1 dritter Schicht ist in dem
Baum 955-1 versteckt und nicht als ein Kindknoten des Knotens
SL2 zweiter Schicht sichtbar. Beispielsweise klickt der Benutzer
dann auf den RESET- bzw. Rücksetz-Knopf 955-2,
um den Baum 955-1 zu seinem ursprünglichen bzw. Anfangszustand
zurückzu setzen. Nachdem
er die RESET Anfrage erhalten hat, verändert der Client 900 den
Baum 955-1 dementsprechend.
-
2D zeigt
bei T4 ein Beispiel des anfänglichen
Zustands des Baums 955-1. Der Wurzelknoten R1 hat den Status
zusammengefallen (+) und keiner seiner Kindknoten ist visualisiert
bzw. sichtbar gemacht. Ein alternativer Anfangszustand des Baums 955-1 ist:
Wurzelknoten R1 expandiert (–);
Kindknoten: FL1, FL2 zusammengefallen (+). Ein weiterer alternativer
Anfangszustand ist: alle Knoten expandiert (+). In der folgenden Beschreibung
sind bzw. werden Ausbildungen der Erfindung geoffenbart, um ein
GUI Verhalten, wie dies unter 2A bis 2D beschrieben
ist, mit niedrigen Netzwerkbandbreiten-Erfordernissen und reduziertem Schirmflimmern
für den
Benutzer zu implementieren, wenn sich das Aussehen von GUI 955 bei,
vor oder nach den Zeitpunkten T1 bis T4 verändert.
-
3 illustriert
eine Wechselwirkung des Client 900 mit dem Server 901,
wenn sie entsprechend einer Ausbildung der vorliegenden Erfindung
betätigt
werden. Wie dies in 1 beschrieben ist, kommuniziert
der Client 900 mit dem Server 901 über das
Netzwerk 990.
-
Der
Server 901 beinhaltet eine Anwendungskomponente, welche
einen Server-Controller 101-1 und einen Server-Renderer 101-2 aufweist.
In dem Beispiel beinhaltet eine Instanz der Anwendungskomponente weiterhin
ein ursprüngliches
bzw. Originalmodell 200-T1. Beispielsweise sind der Server-Controller 101-1 und der
Server-Renderer 101-2 Teile bzw. Abschnitte des CPP 101 (siehe 1),
welches in dem Speicher 921 des Servers 901 gespeichert
ist. Der Server-Controller 101-1 empfängt 410 eine
Modifikationsanfrage des Client 900. Nach einem Empfangen
der Modifikationsanfrage modifiziert 10 der Server-Controller 101-1 das
Originalmodell 200-T1 in ein modifiziertes Modell 200-T2.
In dem Fall von mehrfachen Anwendungskomponenten lassen entsprechende
Server-Controller die Anwendungskomponenten einander beeinflussen.
Mit anderen Worten kann beispielsweise der Server-Controller 101-1 ein
Ereignis bewirken, das einen weiteren Server-Controller ein weiteres
Modell modifizieren läßt.
-
Das
Originalmodell 200-T1 und modifizierte Modell 200-T2 der
Anwendungskomponente sind bzw. werden durch dasselbe Kreissymbol
illustriert. Indem neuerlich auf das Beispiel von 2A Bezug
genommen wird, wird das Originalmodell 200-T1 als Baum 955-1 bei
T1 sichtbar gemacht. Die Modifikationsanfrage entspricht der Benutzerwechselwirkung,
um den Knoten SL2 des zweiten Niveaus zu expandieren. Das modifizierte
Modell 200-T2 wird als Baum 955-1 bei T2 sichtbar
gemacht.
-
Eine
Ausbildung der Erfindung verwendet ein objektorientiertes Komponenten-Architekturnetzwerk (auch
als Netzwerk nachfolgend bezeichnet) mit Vererbung. Das Netzwerk
hat einen serverseitigen Abschnitt und einen clientseitigen Abschnitt.
Das Netzwerk kann als ein Funktionspool implementiert werden, wie
ein Satz von Verfahren bzw. Methoden von einer oder mehreren Klasse(n).
Beispielsweise implementieren Komponenten standardmäßige, graphische
Benutzer-Interface-Elemente,
wie Knöpfe
(beispielsweise RESET 955-2),
Bäume (beispielsweise
Baum 955-1), Tabellen, Tabellenstreifen oder irgendein
anderes Interface-Element in einem graphischen Benutzer-Interface,
wie GUI 955. Weiterhin kann eine Komponente Eigenschaften besitzen
und Dienste an bieten, wie eine Ausbildung bzw. Erzeugung eines graphischen
Benutzer-Interface von einem graphischen Benutzer-Interface-Beschreibungsfile,
Drag- und Drop-Wechselwirkungshandhabung und Komponenten-Administration.
Das Netzwerk unterstützt
eine Komponenten-Ausbildung und -Löschung zur Laufzeit, ebenso
wie einen Zugriff zu allen Eigenschaften einer Komponente zur Laufzeit.
Zusätzlich
kann das Netzwerk allgemeine Dienste zur Verfügung stellen, wie einen Übertragungsereignismechanismus,
eine Modifikation des graphischen Benutzer-Interface und einen Serverzugriff
ohne Seitenersatz.
-
Eine
Komponente kann ohne ein spezielles Registrierungsverfahren ähnlich zu
Verfahren bzw. Prozeduren installiert werden, die durch Servlet-Maschinen
verwendet werden, wie Tomcat. Mit anderen Worten macht ein Installieren
einer Komponente automatisch die Komponente für das Framework bzw. Rahmenwerk verfügbar.
-
Beispielsweise
ist eine Anwendungskomponente einer Komponente durch eine Komponenten-Klasse definiert,
wie eine Java Klasse, eine Java Server Pages Klasse, eine Servlet
Klasse, eine Pascal Klasse, eine C Klasse, eine C++ Klasse oder
eine Business Server Pages Klasse. Die Komponenten-Klasse läuft auf
einem Server 901. Beispielsweise implementiert die Komponenten-Klasse
das Modell (beispielsweise Modell 200-T1) ebenso wie den
Server-Renderer (beispielsweise Server-Renderer 101-2)
und den Server-Controller (beispielsweise Server-Controller 101-1)
der Komponente.
-
Um
das ursprüngliche
Modell 200-T1 zu visualisieren, generiert der Server-Renderer 101-2 einen
mit einem Browser kompatiblen Code, wie HTML, XHTML oder WML. Anfänglich generiert
der Server-Renderer 101-2 eine Komponenten-Beschreibungseinheit
aus dem ursprünglichen
Modell 200-T1 und sendet die Komponenten-Beschreibungseinheit
zu dem Client 900. Die Komponenten-Beschreibungseinheit
entspricht einer mit einem Browser kompatiblen Beschreibung des
Baums 955-1 in dem Beispiel von 2A (bei
T1). Fachleute wissen, wie die Komponenten-Beschreibungseinheit,
beispielsweise auf der Basis einer Java Seite, einer Java Server
Seite oder alternativen serverseitigen Beschreibungen des Originalmodells 200-T1 zu
generieren ist. Beispielsweise generiert eine Komponenten-Script-Klasse,
wie eine JavaScript Klasse, eine JavaApplets Klasse oder eine VisualBasic
Script Klasse, eine originale Browser-Komponente 300-T1 basierend
auf der entsprechenden Komponenten-Beschreibungseinheit des Originalmodells 200-T1.
-
In
einer Ausbildung beinhalten Komponenten Eigenschaften als einen
Satz von Namen-Wertpaaren, wobei die Eigenschaften Teil einer entsprechenden
Komponenten-Beschreibungseinheit sind. Standardeigenschaften einer
Komponente sind: eine Identifikationseinheit bzw. ein Identifier,
ein Klassenname, ein Script-Klassen-Name und ein Eltern-Komponenten-Name.
Die Identifikationseinheit ist einzigartig auf einer Seite, welche
die Komponente beinhaltet. Der Klassenname und der Script-Klassen-Name
spezifizieren die Namen der Komponenten-Klasse und der Komponenten-Script-Klasse
der Komponente. Der Eltern-Komponenten-Name ist die Identifikationseinheit
der Eltern-Komponente der Komponente. Beispielsweise kann der Script-Klassen-Name
von dem Klassennamen abgeleitet sein bzw. werden. Die Script-Klasse
kann verwendet werden, um eine Browser-Komponente zu erzeugen, welche
mit der Anwendungskomponente der Komponente übereinstimmt bzw. dieser entspricht.
-
Wenn
eine Seite anfänglich
auf dem Server 901 generiert ist, wird die Komponenten-Klasse
von jeder Anwendungskomponente der Seite mit den entsprechenden
Eigenschaften der Anwendungskomponente genannt bzw. aufgerufen.
Die Eigenschaften beinhalten die gesamte Information betreffend
die Anwendungskomponente, welche auf dem Server 901 bekannt
ist. Die Komponenten-Klasse schreibt eine Komponenten-Beschreibungseinheit
der Anwendungskomponente an die Seite, indem beispielsweise eine
oder mehrere Funktion(en) des Interface der Komponenten-Klassen
benutzt wird bzw. werden. Beispiele dieser Funktionen sind:
- • prolog(...)
- • base(...)
- • epilog(...)
-
In
dem Beispiel haben alle die Funktionen einen Satz von Parametern.
Beispielsweise ist ein Parameter "Eigenschaften" ein Satz von Namen-Wert-Paaren, welche
die Anwendungskomponente beschreiben. Ein weiterer Parameter "Ausgabe" wird verwendet,
um Daten in die Seite zu schreiben, wobei die Daten zu dem Client
in einem ausgegebenen bzw. Ausgabestrom übersandt werden. Ein Schreiben
von Daten auf eine Seite, welche zu dem Client in einem Ausgabestrom
gesandt wird, wird auch als ein Schreiben oder Rendern von Daten
zu dem Ausgabestrom bezeichnet werden.
-
Die
Funktion prolog(...) schreibt einen Komponenten-Beschreibungseinheits-Kopf
bzw. -Header zu dem Ausgabestrom. Der Komponenten-Beschreibungseinheits-Header
ist eine mit einem Browser kompatible Beschreibung von Namen-Wert-Paaren, welche die
Anwendungskomponente beschreiben.
-
Die
Funktion base(...) rendert einen Basisinhalt bzw. -content der Komponente
zu dem Ausgabestrom. Der Basisinhalt wird als der ursprüngliche
bzw. Anfangsinhalt einer Komponente definiert, welche dem Benutzer
präsentiert
wird. Das Netzwerk ist fähig,
die Basisinhalte von mehreren Komponenten innerhalb einer Seite zu
kombinieren. Dies resultiert in einer Beschreibung eines GUI 955.
Beispielsweise beinhaltet der Basisinhalt einer Komponente weitere
Namen-Wert-Paare, wie ein Inhaltsnamen-Wert-Paar, welche eine mit
einem Browser kompatible Beschreibung des anfänglichen Inhalts der Komponente
oder ein Bezug auf den anfänglichen Inhalt
sind, welcher dem Benutzer präsentiert
wird. Ein Typ- bzw. Artbeschreibungs-Namen-Wert-Paar kann einen
Referenz- bzw. Bezugstyp für
den Anfangsinhalt beschreiben. Beispielsweise enthält, wenn
das Typ- bzw. Artspezifikations-Namen-Wert-Paar "HTML" beinhaltet,
dann das entsprechende Inhaltsnamen-Wert-Paar den Anfangsinhalt
als einen HTML String. Beispiele von anderen Referenzarten sind "DOM", "WML" und "link" (Link bzw. Verbindung
zu einer anderen Seite).
-
In
dem Fall, daß das
Typspezifikations-Namen-Wert-Paar die Bezugsart "DOM" beinhaltet,
beinhaltet das Inhaltsnamen-Wert-Paar
eine einzigartige Identifikationseinheit eines entsprechenden DOM
Knotens der Seite. Beispielsweise kann zur Seitenbildungszeit bzw.
-generierungszeit der Server 901 einen HTML Code in der
Seite generieren, wo der HTML Code ein ID Attribut aufweist, welches
die einzigartige Identifikation des DOM Knotens als den Wert des
ID Attributs beinhaltet. Dasselbe gilt für andere Referenzarten.
-
Die
Funktion epilog(...) beschreibt ein clientseitiges Script in den
Ausgabestrom, um die Komponente in dem Framework zu registrieren.
-
Einige
Funktionen zum Schreiben der Komponenten-Beschreibungseinheit in
den Ausgabestrom können
durch eine Super-Klasse
der Komponenten-Klasse gehandhabt werden. Mit anderen Worten kann
eine Super-Klasse Eigenschaften, welche dieselben für eine Mehrzahl
von Komponenten sind (beispielsweise eine Klasseneigenschaft), in
den Ausgabestrom schreiben. Die Komponenten-Klasse, welche eine
Unter- bzw. Subklasse der Super-Klasse ist, kann Eigenschaften einer
spezifischen Komponente zu dem entsprechenden Ausgabestrom hinzufügen.
-
Der
folgende Codierblock ist ein vereinfachtes HTML-Code-Beispiel einer Komponenten-Beschreibungseinheit
einer Baumkomponente:
-
Der
Tabellen-Abschnitt des Codierblocks beinhaltet den Komponenten-Beschreibungseinheits-Header
(beispielsweise Identifikationseinheit, Parent bzw. Eltern, Klasse
(class), PositionX, PositionY, Breite (Width), Höhe (Height)), die beispielsweise
durch die Funktion prolog() generiert wurden, und beinhaltet weiterhin
den Komponenten-Basisinhalt (beispielsweise Inhaltsart (contentType),
Inhalt (content)), die beispielsweise durch Funktion base() generiert
wurden. Indem neuerlich auf das Beispiel von 2A Bezug
genommen wird, entspricht die Komponenten-Beschreibungseinheit einer
Beschreibung des Baums 955-1 bei T1.
-
Der
JavaScript Abschnitt des Codierblocks kann durch die Funktion epilog()
generiert bzw. erzeugt werden.
-
Wenn
der Client-Controller 101-1 das Originalmodell 200-T1 in
das modifizierte Modell 200-T2 modifiziert 10,
generiert 420 der Server-Renderer 101-2 wenigstens
ein Browser-Inkrement 300-I in einem mit einem Browser
kompatiblen Format. In Abhängigkeit
von der Modifikation 10 kann mehr als ein Browser-Inkrement
durch den Server-Renderer 101-2 generiert werden. In dem
Beispiel entspricht das Browser-Inkrement 300-I dem Unterschied
zwischen dem Originalmodell 200-T1 und dem modifizierten
Modell 200-T2. Indem neuerlich auf das Beispiel von 2B Bezug
genommen wird, entspricht das Browser-Inkrement 300-I dem Knoten
TL1 dritten Niveaus. Der Server 901 sendet dann 430 wenigstens
das Browser-Inkrement 300-I zu
dem Client 900.
-
Beispielsweise
hat das Interface der Komponenten-Klasse eine weitere Funktion increment(...).
Die Funktion increment(...) kann Parameter "Eigenschaften" ("properties") und "Ausgabe" ("output") aufweisen, welche
dieselben wie für
die zuvor beschriebenen Funktionen des Interface sein können. Es
kann einen weiteren Parameter "Parameter" ("parameters") aufweisen, welcher
ein weiterer Satz von Namen-Wert-Paaren ähnlich zu dem Parameter "Eigenschaften" ist. Die Funktion
increment() kann aufgerufen werden, wenn eine Benutzer-Wechselwirkung
(beispielsweise wenn der Benutzer anzeigt, den Knoten SL2 zweiten
Niveaus zu expandieren), welche das Modell der Anwendungskomponente
beeinflußt
(beispielsweise Originalmodell 200-T1), eine Änderung
in wenigstens einem Teil der entsprechenden Browser-Komponente für seine
Visualisierung erfordert. Die Funktion increment() hat die Aufgabe,
ein entsprechendes Browser-Inkrement (beispielsweise Browser-Inkrement 200-T1)
zu generieren 420 und es in den Ausgabestrom zu schreiben.
Die Namen-Wert-Paare, die mit dem Parameter "Parameter" zur Verfügung gestellt sind bzw. werden,
spezifizieren das exakte Format des Browser-Inkrements, das zu generieren
ist.
-
Indem
neuerlich auf das Beispiel von
2B Bezug
genommen wird, kann ein HTML Beispiel eines Browser-Inkrements
300-I das
folgende Statement beinhalten:
<div id= '/R1/FL1/SL2/TL1'>node
label</div>.
-
Die
Identifikationseinheit '/R1/FL1/SL2/TLI' beschreibt den Pfad
des Browser-Inkrements, welcher dem Knoten TL1 dritten Niveaus bei
T2 entspricht. Die Knotenmarkierung kann ein Icon bzw. Bildzeichen
sein (beispielsweise "+" in einem Kreis),
welches den Knoten oder einen Text oder irgendeine andere graphische Darstellung
visualisiert bzw. sichtbar macht.
-
In
einer alternativen Ausbildung kann eine einzige Funktion (beispielsweise
Funktion all_in_one (...)) oder irgendeine andere Zahl von Funktionen
verwendet werden, um die vorher beschriebenen Aufgaben durchzuführen, welche
erforderlich sind, um die entsprechenden Daten in den Ausgabestrom
zu schreiben.
-
Um
zusammenzufassen, hat in einer Ausbildung der Erfindung die serverseitige
Komponenten-Klasse zwei Aufgaben:
- (a) Auf Anfrage
Schreiben einer Komponenten-Beschreibungseinheit zu dem Ausgabestrom,
wobei die Komponenten-Beschreibungseinheit alle Komponenten-Eigenschaften
auflistet. Weiterhin Generieren des Komponenten-Basisinhalts und
Schreiben in den Ausgabestrom. Weiterhin Schreiben des Codes zu
dem Ausgabestrom, welcher die Komponente mit dem Rahmenwerk registriert.
- (b) Auf Anfrage Generieren eines Browser-Inkrements, wie dies
durch die Parameter beschrieben ist. Schreiben des Browser-Inkrements
in den Ausgabestrom.
-
Der
Client 900 beinhaltet eine Browser-Komponente, welche der
Anwendungskomponente entspricht und welche einen entsprechenden
Client-Assembler 100-1 und einen Client-Controller 100-2 aufweist.
Beispielsweise sind der Client-Controller 100-2 und
der Client-Assembler 100-1 Teile bzw. Abschnitte des CPP 100 (siehe 1),
welches in dem Speicher 920 des Client 900 gespeichert
ist. Eine Instanz der Browser-Komponente (beispielsweise ein JavaScript Objekt)
wird von der entsprechenden Komponenten-Script-Klasse eingesetzt. Beispielsweise verwendet
der clientseitige Abschnitt des Rahmenwerks eine Konstruktionseinrichtung
bzw. ein Konstruktionselement, welche(s) einen Anzeiger zu der Komponenten-Beschreibungseinheit
empfängt.
Die Browser-Komponente extrahiert Eigenschaften und entsprechende
Eigenschaftswerte von der Komponenten-Beschreibungseinheit und addiert
diese zu der Instanz der Browser-Komponente.
Die Instanz der Browser-Komponente beinhaltet die ursprüngliche
DOM Komponente 300-T1.
-
Nachdem
das ursprüngliche
bzw. Originalmodell 200-T1 modifiziert wurde, erhält 520 der
Client-Assembler 100-1 das Browser-Inkrement 300-I und
aktualisiert 530 die originale bzw. ursprüngliche
DOM Komponente 300-T1 (welche dem Originalmodell 200-T1 entspricht)
mit wenigstens dem Browser-Inkrement 300-I. Dies
resultiert in einer modifizierten DOM Komponente 300-T2,
welche dem modifizierten Modell 200-T2 entspricht. Die
modifizierte DOM Komponente 300-T2 und die originale DOM
Komponente 300-T1 sind durch dieselbe Ellipse illustriert.
Beispielsweise sind die modifizierte DOM Komponente 300-T2 und
die originale DOM Komponente 300-T1 Instanzen (beispielsweise
JavaScript Objekte) der entsprechenden Komponenten-Script-Klasse.
In einer Ausbildung der Erfindung läuft die Komponenten-Script-Klasse,
welche der Komponenten-Klasse einer Komponente entspricht, auf dem
Client 900 und implementiert beispielsweise den Client-Assembler 100-1 und
den Client-Controller 100-2. Beispielsweise beinhaltet
das Interface des Client-Assemblers 100-1 eine Funktion
handleResponse(...).
-
In
einer Ausbildung der Erfindung wird die Funktion handleResponse()
aufgerufen, wenn der Client-Assembler 100-1 das Browser-Inkrement 300-I von
der Funktion increment() der Komponenten-Klasse erhält 520.
Beispielsweise leitet das Rahmenwerk den Parameter "Ausgabe" ("output") der Funktion increment() zu
einem Parameter "Antwort" ("response") der Funktion handleResponse().
Weiterhin ist ein Parameter "target" ("Ziel") der Funktion handleResponse()
ein Wert, welcher zu dem Server 901 in dem Empfangsschritt 410 zugeleitet
wird. Wenn die Funktion handleResponse() aufgerufen wird, nachdem
sie das Browser-Inkrement 300-I erhalten hat 520,
zeigt der Parameter "target" dem Client den Empfänger (Browser-Komponente)
des Browser-Inkrements 300-I an. Der Empfänger kann
derselbe wie der originale Anfrager sein, jedoch kann er auch von
dem ursprünglichen
Anfrager bzw. Fragesteller unterschiedlich sein.
-
Ein
erstes Beispiel zum Entnehmen des Browser-Inkrements 300-I von
dem Server 901 ist durch Verwendung eines Script Tag. Ein
zweites Beispiel ist durch Verwenden eines versteckten bzw. verborgenen HTML
iFrame Elements.
-
Um
ein Browser-Inkrement unter Verwendung eines Script Tag (beispielsweise
JavaScript) zu entnehmen, führt
der clientseitige Abschnitt des Rahmenwerks bzw. Frameworks die
folgenden Schritte durch.
-
Zuerst
wird eine entsprechende URL Anfrage generiert. Beispielsweise entnimmt
der clientseitige Abschnitt des Rahmenwerks eine von einem Server
generierte grundlegende Anfrage URL von der Seite, die von dem Server
empfangen ist, und bringt anfragespezifische Parameter an.
-
Dann
wird ein Script Tag (beispielsweise stag) generiert, welches ein
SCR Attribut aufweist. Dafür kann
man bei spielsweise ein JavaScript Statement verwenden, wie beispielsweise:
var
stag = createNode("script").
-
Dann
wird die Anfrage URL dem SRC Attribut des Script Tag zugewiesen
(stag.SRC = request bzw. Anfrage URL).
-
Dann
wird das Script Tag zu dem DOM der Seite hinzugefügt. Beispielsweise
kann dies erzielt werden, indem das JavaScript Statement document.
body. appendChild (stag) verwendet wird.
-
Sobald
das Script Tag zu dem DOM hinzugefügt ist, sendet der Client die
Server-Anfrage an den Server. Der Server generiert ein Script Statement,
welches die Antwort auf die Anfrage beinhaltet. Beispielsweise kann
der Server einen Anruf zu dem clientseitigen Abschnitt des Rahmenwerks
erzeugen, wobei die Ergebnisse der Serveranfrage als ein Parameter
zugeleitet werden:
Framework. handleResponse (result)
-
Die
Funktion handleResponse(...) interpretiert das Ergebnis an dem Client
und leitet das Ergebnis für jede
Komponente zu den entsprechenden Komponenten weiter.
-
Andere
Scriptsprachen, wie beispielsweise VBScript, können in gleicher Weise verwendet
werden, um eine Browser-Inkrement-Entnahme unter Verwendung von
Script Tags zu implementieren.
-
Das
zweite Beispiel verwendet iFrames statt Script Tags für eine Browser-Inkrement-Entnahme.
In diesem Beispiel beinhaltet die Seite, die von dem Server empfangen
bzw. er halten wurde, einen versteckten iFrame bzw. iRahmen, welcher
in die Seite durch den serverseitigen Abschnitt des Rahmenwerks
generiert wird. Der clientseitige Abschnitt des Netzwerks generiert
dann eine entsprechende Anfrage URL, wie dies in dem ersten Beispiel
beschrieben ist.
-
Dann
wird die Anfrage URL dem SRC Attribut des versteckten iFrame zugewiesen.
-
Sobald
die Anfrage URL dem SRC Attribut zugewiesen ist, sendet der Client
die entsprechende Anfrage an den Server. Der Server kann ein Script
generieren, wie dies in dem ersten Beispiel beschrieben ist, oder
er kann eine Beschreibung generieren, welche Tätigkeiten an dem Client erforderlich
sind. In dem letzteren Fall interpretiert das clientseitige Rahmenwerk
die Beschreibung und arbeitet bzw. agiert entsprechend.
-
Wenn
der Client-Assembler 100-1 feststellt, daß eine Aktualisierung
der Browser-Komponente (beispielsweise durch Benutzer-Wechselwirkung)
angefragt ist, generiert der Client-Controller 100-2 die
Modifikationsanfrage, welche zu dem Server 901 gesandt
wird 510. Weitere Funktionen des Client-Controllers 100-2 sind
in 4A, 4B und 5 erklärt.
-
Wenn
lediglich ein Browser-Inkrement 300-I statt der gesamten
modifizierten Browser-Komponente von dem Server 901 zu
dem Client 900 gesandt wird, ist weniger Bandbreite für die Client
Server Kommunikation über
das Netzwerk 990 erforderlich und es wird weniger CPU Zeit
des Servers verbraucht, um das Browser-Inkrement 300-I zu
generieren, statt für
das Regenerieren der vollständigen
Seite.
-
Wenn
die originale DOM Komponente 300-T1 mit dem Browser-Inkrement 300-I durch
den Client-Assembler 100-1 aktualisiert wird, ist ein Schirmflimmern,
welches häufig
auftritt, wenn eine vollständige
Seite ersetzt wird, reduziert.
-
4A, 4B illustrieren
weitere Details einer clientseitigen Handhabung des Browser-Inkrements 300-I in
einer Ausbildung der Erfindung. Vorzugsweise speichert, nachdem
das Browser-Inkrement 300-I empfangen wurde 520,
der Client-Controller 100-2 das
Browser-Inkrement 300-I in einem Cache-Speicher 920-C des
Client 900.
-
4A illustriert
die Deaktivierung des Browser-Inkrements 300-I nach einem
Empfangen einer Deaktivierungs-Anfrage DAR. Die Deaktivierungs-Anfrage
DAR kann durch den Benutzer generiert werden, der mit dem Client 900 wechselwirkt,
wie dies in 2A, 2B beschrieben
ist, oder sie kann durch einen anderen Computer in dem Computersystem 999 generiert
werden. Beispielsweise wird die Deaktivierungs-Anfrage DAR durch den Client-Controller 100-2 empfangen.
Dann instruiert 610 der Client-Controller 100-2 den
Client-Assembler 100-1,
um das Browser-Inkrement 300-I in der modifizierten DOM
Komponente 300-T2 zu deaktivieren 550, was in
einer deaktivierten DOM Komponente 300-T3 resultiert. Beispielsweise
kann das Browser-Inkrement 300-I durch Festlegen bzw. Einstellen
eines entsprechenden Deaktivierungsflags deaktiviert werden. In
der deaktivierten DOM Komponente 300-T3 wird das Browser-Inkrement 300-I unterdrückt (beispielsweise
durch Löschen
oder Festlegen eines Deaktivierungsflags; durch ein Auskreuzen illustriert).
Die modifizierte DOM Komponente 300-T2 und die deaktivierte
DOM Komponente 300-T3 sind durch dieselbe Ellipse illustriert.
Indem neuerlich auf das Beispiel von 2B, 2C Bezug
genommen wird, entspricht die modifizierte DOM Komponente 300-T2 dem
Baum 955-1 bei T2, wobei der Knoten SL2 zweiten Niveaus
expandiert ist und der Knoten TL1 dritten Niveaus beinhaltet ist.
Die deaktivierte DOM Komponente 300-T3 entspricht dem Baum 955-1 bei
T3, wobei der Knoten TL1 dritten Niveaus unterdrückt ist und der Knoten SL2 zweiten
Niveaus zusammengefallen ist. Obwohl das Sichtbarmachen des Baums 955-1 bei
T1 identisch mit seiner Visualisierung bei T3 ist, ist der Status
des Client 900 bei T1 unterschiedlich von dem Status bei
T3, da das Client-Inkrement 300-I im Cache 920-C bei
T3 verfügbar
ist, jedoch nicht bei T1. Dies beeinflußt das Verhalten des Client 900 im
Fall einer Reaktivierungs-Anfrage, wie dies unter Bezugnahme auf 4B erklärt ist.
-
Beispielsweise
können
Browser-Komponenten an dem Client 900 Wechselwirken, ohne
den Server 901 zu kontaktieren. Indem neuerlich auf das
Beispiel von 2D rückverwiesen wird, hat bei T4
der Benutzer den RESET Knopf 955-2 verwendet, welcher eine
Reset Anfrage generiert, um den Baum 955-1 zu dem Wurzelknoten
R1 zusammenfallen zu lassen. Entsprechend wirkt am Client 900 eine
RESET Browser-Komponente (nicht gezeigt), welche einer RESET Anwendungskomponente
(nicht gezeigt) an dem Server 901 entspricht, mit der Browser-Komponente,
die den Baum 955-1 sichtbar macht bzw. visualisiert, derart
zusammen, daß alle weiteren
Browser-Inkremente (nicht gezeigt) der Browser-Komponente in der
entsprechenden DOM Komponente (beispielsweise deaktivierte DOM Komponente 300-T3)
mit Ausnahme eines Browser-Inkrements deaktiviert werden, welches
dem Wurzelknoten R1 entspricht.
-
4B illustriert
die Reaktivierung des Browser-Inkrements 300-I, nachdem
der Client-Controller 100-2 die Reaktivierungs-Anfrage
RAR erhalten hat. Der Client-Controller 100-2 entnimmt
das Browser-Inkrement 300-I von dem Cache-Speicher 920-C und
instruiert 620 den Client-Assembler 100-1, das
Browser-Inkrement 300-I in der deaktivierten DOM Komponente 300-T3 zu
reaktivieren. Die Reaktivierung resultiert in einer reaktivierten
DOM Komponente 300-T3'.
Indem neuerlich auf das Beispiel von 2A zurückgegriffen wird,
wirkt der Benutzer mit dem Client 900 in derselben Weise
wie bei T1 zusammen. Jedoch statt einer Anfrage, daß das Browser-Delta 300-I von
dem Server 901 an der modifizierten DOM Komponente 300-T2 ankommt,
welche der Visualisierung eines Baums 955-1 bei T2 entspricht,
entnimmt der Client 900 einfach das Browser-Inkrement 300-I von
seinem eigenen Cache 902-C und reaktiviert 570 das
Browser-Inkrement 300-I in
der deaktivierten DOM Komponente 300-T3. Die resultierende
reaktivierte DOM Komponente 300-T3' ist identisch mit der modifizierten
DOM Komponente 300-T2.
-
Indem
Browser-Inkremente am Client 900 gespeichert werden und
eine Wechselwirkung von Browser-Komponenten am Client 900 erlaubt
wird, wird die Last des Servers 901 reduziert, weil die
Anzahl von Anfragen an den Server reduziert ist bzw. wird, wenn
der Client 900 spezifische Ereignisse auf seinem eigenen handhaben
kann, ohne den Server 901 zu kontaktieren.
-
5 illustriert
zwei komplementäre
Computerprogrammprodukte CPP 101 (Server-Programm), CPP 100 (Client-Programm)
und ihre wesentlichen funktionellen Blöcke, welche in einer Ausbildung
der vorliegenden Erfindung verwendet werden können. Beispielsweise kann CPP 100 ein
Browser sein.
-
Das
Rahmenwerk wird in einem serverseitigen Abschnitt 101-10 als
ein Teil von CPP 101 und in einem clientseitigen Abschnitt 100-10 als
ein Teil von CPP 100 implementiert. Wie dies früher erklärt wurde,
stellt das Rahmenwerk generische Funktionen zur Verfügung, welche
an mehreren Komponenten angewandt werden können.
-
DOM 100-9 wird
verwendet, um das graphische Benutzer-Interface einer Anwendung
dem Benutzer zu präsentieren.
In dem Beispiel repräsentiert
DOM 100-9 eine Seite, beinhaltend eine Baum-Komponente 955-1 (siehe 2A)
und eine Reset-Komponente 955-2 (siehe 2A).
Wenn der Benutzer mit CPP 100 wechselwirkt (beispielsweise
durch Anzeigen, daß ein
spezifischer Baumknoten expandiert werden soll), so daß das Modell 200-Tn (n
= 1, 2,..., N) am Server 901 betroffen sein wird, wird
der entsprechende Client-Controller 100-2 von der Benutzer-Wechselwirkung
verständigt 701 und
sendet 702 eine entsprechende Anfrage an CPP 101,
welches auf dem Server 901 läuft. Beispielsweise kann der
Client-Controller 100-2 spezifische Browser-Ereignisse
abonnieren und wird verständigt,
wenn ein entsprechendes Browser-Ereignis durch die Benutzer-Wechselwirkung
aufgeworfen wird.
-
In
dem Fall, daß die
Benutzer-Wechselwirkung durch den Client-Controller 100-2 ohne
Kontaktieren des Servers 901 gehandhabt werden kann, kann
der Client-Controller 100-2 entsprechend den Client-Assembler 100-1 instruieren 702', um DOM 100-9 der
Seite zu aktualisieren 803, welche gegenwärtig durch
den Browser visualisiert ist, um die Visualisierung von DOM 100-9 gemäß der Benutzer-Wechselwirkung
einzustellen.
-
In
dem Fall, daß die
Benutzer-Wechselwirkung erfordert, daß der Server 901 involviert
ist, sendet 702 CPP 100 eine entsprechende Anfrage
an CPP 101. Die Anfrage veranlaßt den Server-Controller 101-1,
das entsprechende Modell 200-Tn entsprechend zu modifizieren 703.
Der Server-Renderer 101-2 rendert/generiert 801 das
Modell 200-Tn, nachdem es modifiziert wurde 703.
Das Ergebnis des Renderns 801 ist eine Beschreibung des
Modells, welches für
seine Sichtbarmachung verwendet werden kann. Diese Beschreibung wird
dann zu dem Client 900 übersandt.
-
In
einer Ausbildung der Erfindung wird die Beschreibung von dem Server-Renderer 101-2 zu
dem Client-Assembler 100-1 gesandt 802. Der Client-Assembler
verwendet die Beschreibung, um DOM 100-9 entsprechend durch
ein Ändern
eines entsprechenden Knotens von DOM 100-9 zu aktualisieren 803.
-
In
einer weiteren Ausbildung der Erfindung kann die Beschreibung von
dem Server-Controller 101-1 zu dem Client-Controller 100-2 gesandt
werden 702, welcher dann den Client-Assembler 100-1 instruiert 702', DOM 100-9 entsprechend
zu aktualisieren 803.
-
In
noch einer weiteren Ausbildung der Erfindung wird die Beschreibung
von dem serverseitigen Rahmenwerk 101-10 zu dem clientseitigen
Netzwerk 100-10 gesandt, wo sie an den entsprechenden Client-Controller 100-2 geliefert
wird.
-
6 faßt serverseitige
Aspekte der Erfindung durch ein vereinfachtes Flußdiagramm
eines serverseitigen Verfahrens 400 zusammen, welches durch
eine Ausbildung der Erfindung durchgeführt werden kann. Beispielsweise
kann das Verfahren 400 zum Handhaben von inkrementellen
Daten auf dem Server 901 im Computersystem 999 durch
das Computerprogrammprodukt 101 durchgeführt werden,
das Instruktionen aufweist, daß,
wenn es in den Speicher 921 des Servers 901 geladen
wird, es wenigstens einen Prozessor 911 des Servers 901 verlaßt, das
Verfahren 400 durchzuführen.
Das Verfahren 400 beinhaltet die Schritte Empfangen 410,
Generieren 420 und Senden 430.
-
In
dem Empfangsschritt 410 empfängt der Server-Controller 101-1 eine
Modifikations-Anfrage von dem Client-Controller 100-2.
Der Client-Controller 100-2 läuft auf dem Client 900 des
Computersystems 999. Die Modifikations-Anfrage läßt den Server 901 das
ursprüngliche
bzw. Originalmodell 200-T1 in das modifizierte Modell 200-T1 modifizieren,
welche beide beispielsweise in dem Speicher 921 des Servers 901 gespeichert sind
bzw. werden.
-
In
dem Generierungs- bzw. Ausbildungsschritt 420 generiert
der Server-Renderer 101-2 wenigstens ein Browser-Inkrement 300-I,
welches dem Unterschied zwischen dem Originalmodell 200-T1 und
dem modifizierten Modell 200-T2 entspricht.
-
In
dem Sendeschritt 430 sendet der Server 901 das
wenigstens eine Browser-Inkrement 300-I zu dem Client-Assembler 100-1 des
Client 900. Der Client 900 verwendet das Browser-Inkrement 300-I,
um die ursprüngliche
DOM Komponente 300-T1 mit dem wenigstens einen Browser-Inkrement 300-I zu
aktualisieren. Die Aktualisierung resultiert in der modifizierten
DOM Komponente 300-T2, welche dem modifizierten Modell 200-T1 entspricht,
während
die ursprüngliche
DOM Komponente 300-T1 dem ursprünglichen bzw. Originalmodell 200-T1 entspricht.
-
7A faßt clientseitige
Aspekte der Erfindung durch ein vereinfachtes Flußdiagramm
eines clientseitigen Verfahrens 500 zusammen, welches durch
eine Ausbildung der Erfindung durchgeführt werden kann. Beispielsweise
kann das Verfahren 500 zum Handhaben von inkrementellen Daten auf
dem Client 900 in dem Computersystem 999 durch
das Computerprogrammprodukt 100 durchgeführt werden,
welches Instruktionen besitzt, daß, wenn es in den Speicher 920 des
Client 900 geladen ist, es wenigstens einen Prozessor 910 des Client 900 veranlaßt, das
Verfahren 500 auszuführen.
Das Verfahren 500 beinhaltet die Schritte Senden 510, Empfangen 520 und
Aktualisieren 530.
-
In
dem Sendeschritt 510 sendet der Client-Controller 100-2 eine
Modifikations-Anfrage zu dem Server-Controller 101-1. Der
Server-Controller 101-1 ist bzw. wird auf dem Server 901 des
Computersystems 999 implementiert.
-
In
dem Empfangsschritt 520 empfängt der Client-Assembler 100-1 wenigstens
ein Browser-Inkrement 300-I von dem Server 901 als
eine Antwort auf die Modifikations-Anfrage.
-
In
dem Aktualisierungsschritt 530 aktualisiert der Client-Assembler 100-1 die
ursprüngliche
DOM Komponente 300-T1 mit dem wenigstens einen Browser-Inkrement 300-I,
was in einer modifizierten DOM Komponente 300-T2 resultiert.
Die originale DOM Komponente 300-T1 entspricht dem Originalmodell 200-T1 und
die modifizierte DOM Komponente 300-T2 entspricht dem modifizierten
Modell 200-T1.
-
7B setzt
das vereinfachte Flußdiagramm
von 7A fort. Die Schritte, die durch punktierte Quadrate
bzw. Rechtecke dargestellt bzw. illustriert sind, können durch das
Verfahren 500 in verschiedenen Ausbildungen der Erfindung
durchgeführt
werden. Die Schritte erfordern nicht notwendigerweise, daß die Schritte 510 bis 530 vorher
durchgeführt
werden. Im Fall eines Verwendens eines alternativen Basismechanismus
zum Handhaben von inkrementellen Daten können die Schritte, die in 7B illustriert
sind, unverändert
für eine clientseitige
Ereignishandhabung verwendet werden.
-
In
einem Deaktivierungsbeispiel beinhaltet das Verfahren 500 die
weiteren Schritte eines Speicherns 540 und Deaktivierens 550.
-
In
dem Speicherschritt 540 speichert der Client 900 das
wenigstens eine Browser-Inkrement 300-I in seinem Cache-Speicher 920-C.
-
In
dem Deaktivierungsschritt 550 hat der Client-Controller 100-2 die
Deaktivierungs-Anfrage DAR empfangen und als eine Konsequenz deaktiviert
der Client-Assembler 100-1 das Browser-Inkrement 300-I in der
entsprechenden DOM Komponente.
-
In
einem Reaktivierungsbeispiel beinhaltet das Verfahren 500 gemäß der Erfindung
die weiteren Schritte eines Entnehmens 560 und Reaktivierens 570.
Jedoch erfordert dies nicht, daß der
Aktivierungsschritt 550 vorher durchgeführt wird.
-
In
dem Entnahmeschritt 560 entnimmt der Client 900 das
wenigstens eine Browser-Inkrement 300-I von dem Cache-Speicher 920-C,
wo es unter Verwendung des Speicherschritts 540 gespeichert
wurde. Beispielsweise kann dies durch die Reaktivierungs-Anfrage
RAR initiiert werden, welche durch den Client-Controller 100-2 empfangen
ist bzw. wird.
-
Dann
reaktiviert in dem Reaktivierungsschritt 570 der Client-Assembler 100-1 das
Browser-Inkrement 300-I in der entsprechenden DOM Komponente.
