Willkommen bei WebRocketX©. Entwickeln Sie Single-Page-Webanwendungen (SPA) zehnmal effizienter mit diesem superleichten und superschnellen Content-Delivery-System. WebRocketX ist so intuitiv und effektiv, dass sich jeder, der es nutzt, sofort fragt, wo sich die HTML-Injection all die Jahre versteckt hat.
Was ist WebRocketX?
WebRocketX ist eine browserseitige Javascript-API, über die alle asynchronen Aufrufe an den Server erfolgen. Der Hauptmechanismus zum Aktualisieren der Seite besteht in der DOM-Einfügung von HTML-Snippets mithilfe der innerHTML-Eigenschaft. Da der Entwickler über einen einzigen Interaktionspunkt mit dem Server verfügt, stehen ihm die folgenden von der API bereitgestellten Funktionen zur Verfügung.
- Bietet ein Single Page Application (SPA)-Frontend für jede Technologie, die HTML vom Backend liefert, wie Springboot, PHP, Laravel, Django, Rails usw.
- Browserseitige Steuerung der Benutzerinteraktion während des asynchronen Aufrufs
- Browserseitige Fehlerbehandlung von serverseitigen Ausnahmen
- Browser-Seitenansicht-Caching ~ Sorgen Sie ganz einfach dafür, dass die Zurück-Schaltfläche perfekt funktioniert.
- Navigation in der Browser-Seitenansicht
Eine ausführlichere Beschreibung der Vorteile der Verwendung eines WebRocketX SPA finden Sie hier: Vorteile der Verwendung eines WebRocketX SPA
Warum das X? WebRocketX ist ein Hybrid. Es ist eine Lösung auf halbem Weg zwischen der alten Welt der Websites zur vollständigen Seitenaktualisierung und neueren JSON-JSMVC-Lösungen wie Angular.
- Wie bei der Vollseitenarchitektur erwartet WebRocketX, dass das Layout vom Server Daten enthält. Dies unterscheidet sich von der JSMVC-Architektur, bei der Daten getrennt vom Layout in JSON-Objekten bereitgestellt werden. WebRocketX unterstützt jedoch bei Bedarf JSON, ist jedoch kein JSON-zentriertes Paradigma.
- Wie die JSMVC-Architektur ist WebRocketX eine Single Page Web Application (SPA) und verlässt sich auf AJAX-Aufrufe, um Daten zu übermitteln und neue Ansichten einzubringen.
Weitere tolle Dinge über WebRocketX Geschrieben
komplett in Javascript Da es Jquery als API für den Browser verwendet, läuft es auf allen gängigen Browsern und sogar auf mobilen Geräten.
Ermöglicht einem Webanwendungsentwickler die einfache Erstellung einer umfassenden Benutzererfahrung
Standard-HTML und Javascript, ähnlich der Erfahrung bei der Verwendung eines großen Desktop-Betriebssystems wie Apple oder Windows. Dennoch ist es extrem
geringes Gewicht Es führt eine kleine Menge Code aus und speichert einen Großteil des Benutzerstatus im Browser
Minimierung des Kommunikationsbedarfs mit dem Server.
Bietet dem Webanwendungsentwickler eine
strukturierte Plattform um Inhalte im Browser bereitzustellen und zu verwalten. Obwohl es strukturiert ist, lässt es dem Entwickler dennoch völlig die Freiheit, die Leistungsfähigkeit und den Komfort von Standard-HTML und Stylesheets zu nutzen und Widget-Bibliotheken von Drittanbietern zu verwenden.
Von Natur aus sicher weil das serverseitige HTML-Rendering-Paradigma die Autorisierung des Benutzers in einer Serversitzung speichert, wo es für einen Benutzer schwierig ist, sie zu manipulieren. Da ungenutzte und nicht autorisierte Ansichten nicht clientseitig zwischengespeichert werden, steht einem böswilligen Akteur außerdem keine Angriffsfläche zur Verfügung. Frameworks wie Vue, Angular und React bieten allen Benutzern standardmäßig die Angriffsfläche für das Administratorkonto als zwischengespeicherte Ansichten, es sei denn, die Administrator-Webanwendung wird heruntergeladen und als separate Anwendung verwaltet.
Was WebRocketX nicht ist Keine serverseitige Lösung , da seine Front-End-Komponenten (Browser) nicht mit Back-End-Speicherkomponenten (Server) gekoppelt sind. Die einzige Beziehung zwischen dem, was vom Server geliefert wird, und dem WebRocketX-Framework sind einige einfache Konventionen für die Bereitstellung des HTML-Codes an den Browser. Diese entkoppelte Architektur lässt dem Entwickler die Freiheit, jedes gewünschte Backend-Framework wie Django, Ruby on Rails, Spring MVC, PHP, Asp, Struts usw. zu verwenden. Inhalte werden vom Server als HTML bereitgestellt und von WebRocketX als Formularparameter gesendet. So einfach ist das.
Keine CSS- oder Layoutlösung . Es handelt sich um eine Inhalts-Caching- und Bereitstellungs-API, mit der Sie Ihre dynamische Webanwendung ganz einfach in eine SPA umwandeln können. Es steht einem Entwickler frei, seine Webanwendung nach seinen Wünschen zu gestalten. Das Erscheinungsbild dieser Informationswebsite gibt keinen Aufschluss darüber, wie Ihre Website bei Verwendung von WRX aussehen wird.
Nicht SEO-konform für statische Websites . Die Verwendung von WRX für statische Websites ist in erster Linie eine konzeptionelle Verwendung und leider sind die Suchmaschinen nicht für die Indexierung von SPA-Websites bereit. Keines der Single-Page-Frameworks wie React, Angular oder Vue ist SEO-konform, abgesehen von ihren Landingpages. Andererseits eignet sich WRX sehr gut für dynamische Webanwendungen, insbesondere für Websites, bei denen sich ein Benutzer anmelden muss, um Konten oder Geschäfte jeglicher Art zu verwalten.
Wenn Ihnen WebRocketX gefällt. Geben Sie uns hier in Github einen Stern. Danke!
Installation Ihrer Single-Page-Anwendung
Erstellen Sie eine Landing-/Willkommensseite wie unten gezeigt und fügen Sie die folgenden Bibliotheken ein. Die Zielseite befindet sich normalerweise am besten hinter der Anmeldeseite Ihres Formulars. Mit anderen Worten: Sie leiten den Benutzer nach der Anmeldung dorthin weiter. Alles außer der JQuery-Bibliothek ist im oben gefundenen WebRocketX-Stammquellcode-Ordner verfügbar.
jquery[latest version].js including the draggable library from jquery UI
domUtil.js
desktopContext.js
webapi.js
webRocketXStyles.css
Einfaches HTML-Beispiel für eine dynamische Single-Page-Webanwendung (SPA)
Ausführbare Beispielvorlagen für PHP und Django finden Sie im Vorlagenordner im Quellcode.
Landing-/Willkommensseite
Die Begrüßungsseite ist die Zielseite Ihrer Webanwendung, normalerweise hinter Ihrer Anmeldeseite. Auf der Willkommensseite beginnt Ihr SPA. Zu den wichtigsten Bestandteilen der Bibliothek gehören die Einstellungen der Framework-Variablen, das Startziel und die Kommunikationsfehlerwarnung.
<!DOCTYPE html >
< html >
< head >
< title > Welcome </ title >
<!-- The jquery UI library should include draggable if you want to implement draggable modals-->
< script language =" javascript " type =" text/javascript " src =" javascripts/jquery/jquery-ui-1.11.4.custom/external/jquery/jquery-1.12.4.min.js " > </ script >
< script language =" javascript " type =" text/javascript " charset =" iso-8859-1 " src =" javascripts/webRocketX/v1_10_1/domUtil.js " > </ script >
< script language =" javascript " type =" text/javascript " charset =" iso-8859-1 " src =" javascripts/webRocketX/v1_10_1/desktopContext.js " > </ script >
< script language =" javascript " type =" text/javascript " charset =" iso-8859-1 " src =" javascripts/webRocketX/v1_10_1/webapi.js " > </ script >
< link rel =" stylesheet " type =" text/css " href =" javascripts/webRocketX/v1_10_1/webRocketXStyles.css " >
< script type =" text/javascript " >
var asyncDebugMode = true ;
var signInPageURI = "" ;
var pageLoadTimeStamp = "" ;
var modalTargetSpacing = 10 ;
var staticPage = false ;
var disableNavigation = false ;
</ script >
< link rel =" stylesheet " type =" text/css " href =" styles/demo/styles.css " >
< link rel =" stylesheet " type =" text/css " href =" styles/demo/menu.css " >
< meta name =" viewport " content =" width=device-width " >
</ head >
< body >
<!-- header -->
< table class =" bodytext " >
< tr >
< td width =" 20 " > </ td >
< td >
My Header
</ td >
< td width =" 20 " > </ td >
</ tr >
< tr >
< td width =" 20 " > </ td >
< td class =" menuBar " >
< div id =" menu " > </ div >
</ td >
< td width =" 20 " > </ td >
</ tr >
</ table >
< div id =" errorSpan " style =" color:red;text-align:center; " > </ div >
< div id =" winMain " class =" startingTarget bodytext " >
<!-- Unused or default capsule attributes do not need to be included. They are just included here for teaching purposes. -->
< div id =" welcome " class =" metaCapsule " capsuleType =" inline " targetId =" winMain " jsOnload ="" reloadPage =" false " saveOriginalRequest =" false " saveResponse =" false " trackPage =" true " windowTitle =" welcome " errorPage =" false " >
Hello World
< br /> < br />
< a href =" # " onclick =" test1();return false; " > Test1 </ a >
</ div >
</ div >
<!-- footer -->
< table class =" bodytext " >
< tr >
< td width =" 20 " > </ td >
< td class =" menuBar " style =" padding: 10px 10px 10px 10px; " >
Powered By < a target =" _blank " href =" http://www.webrocketx.com " style =" text-decoration: none; " > < span style =" color:black;background-color:white;font-weight:bold; " > WebRocket </ span > < span style =" color:red;background-color:white;font-weight:bold; " > X </ span > </ a >
</ td >
< td width =" 20 " > </ td >
</ tr >
</ table >
< div id =" communicationErrorAlertWrapper " style =" display:none; " >
< div id =" communicationErrorAlert " class =" metaCapsule " capsuleType =" modal " >
< div id =" dialogLayer " class =" BDT_Dialog_Layer " >
< div class =" BDT_Dialog_Center " >
< div class =" BDT_Dialog_Decoration " >
< table class =" expand " >
< tr >
< td >
< div id =" communicationErrorMessage " > </ div >
< br /> < br />
< a href =" # " onclick =" $('#communicationErrorAlertWrapper').hide(); return false; " > Ok </ a >
</ td >
</ tr >
</ table >
</ div >
</ div >
</ div >
</ div >
</ div >
</ body >
</ html > Beispiel einer injizierten Seite
Diese Seite ersetzt den Hauptinhalt. Wir werden es in einer Datei namens test1.html ablegen. Der Inhalt wird in eine Kapsel (div-Tag) verpackt, die mit Metadaten-XML-Attributen konfiguriert ist. Bei den Metadaten handelt es sich um eine Art deklarative Programmierung, mit der das Framework entscheidet, was mit Ihren Inhalten geschehen soll.
< div id =" test1 " class =" metaCapsule " capsuleType =" inline " targetId =" winMain " windowTitle =" Test 1 " >
Hello World Test 1.
</ div > Beispiel für eine Javascript-Funktion
Dieser Aufruf ersetzt den Inhalt in winMain. Das wirklich Coole ist, dass die Zurück-Schaltfläche des Browsers perfekt zur vorherigen Seite zurücknavigiert, Sie sich aber immer noch die ganze Zeit auf einer SPA-Seite befinden. Dies gilt für jede Navigation im Framework, und Sie haben die vollständige und einfache Kontrolle, wenn Sie möchten, dass eine Seite immer vom Server aktualisiert wird, wenn Sie zu ihr zurücknavigieren, und nicht aus dem Browser-Cache. Wenn Sie die Kapsel einer Seite mit dem reloadPage-Attribut gleich „true“ markieren, wird die Seite mit denselben Parametern, mit denen sie ursprünglich angefordert wurde, erneut an den Server übermittelt und sogar derselbe Callback aufgerufen, der ihr ursprünglich zugewiesen wurde, in ihrem ursprünglichen Schließungsbereich.
function test1 ( ) {
var successfulCallback = function ( innerHTMLObject ) {
alert ( "this my callback" ) ;
}
var webapi = new Webapi ( ) ;
webapi . setSuccessCallbackReference ( successfulCallback ) ;
webapi . setUrl ( "test1.html" ) ;
webapi . submitAsync ( ) ;
} Kann es vielleicht noch einfacher werden?
Vollständige Liste der im dynamischen Web-App-Modus verfügbaren Kapselattribute
Die WebRocketX-Kapselarchitektur ermöglicht es dem Entwickler, einen Großteil des Ansichtsverhaltens deklarativ zu steuern.
Unten sind alle möglichen Kapselattribute aufgeführt. Dadurch erhalten Sie eine Vorstellung von einem Großteil der Framework-Funktionalität und davon, wie es die meisten Anwendungsfälle der Benutzernavigation abdeckt.
Attribute, die nicht in der Kapsel enthalten sind, werden auf ihre Standardwerte gesetzt. Erforderliche Attribute sind mit einem Sternchen* gekennzeichnet.
- id* – Wird verwendet, um die Seite im WebRocketX-Framework zu verfolgen. Weitergegeben über den CapsuleId-Parameter im Vorlagenbeispiel. Die Verwendung von Vorlagen ist nicht erforderlich.
- class* – Muss auf den Wert „metaCapsule“ gesetzt werden. Wird vom Framework verwendet, um das Kapsel-Div zu lokalisieren.
- CapsuleType* – Kann auf die folgenden vier Werte eingestellt werden, die bestimmen, wie und ob die Kapsel injiziert wird.
- inline – Der Inhalt wird in das durch das targetId-Attribut angegebene Div eingefügt.
- modal – Inhalte werden in eine schwebende modale Ebene eingefügt.
- Daten – Inhalte werden vom Framework nicht für die Navigation verfolgt. Der Entwickler kann entscheiden, ob er eine Ziel-ID angibt, den Inhalt selbst platziert oder den Inhalt sogar verwendet, ohne ihn auf der Seite zu platzieren. Der Inhalt wird im Rückruf als erster Parameter in Form eines DOM-Objekts der Kapsel und der darin enthaltenen Inhalte an den Entwickler zurückgegeben. Dies ist der ideale Kapseltyp für aktualisierbare kleinere Teile der Seite, die nicht als ganze Seiten navigiert werden. Zum Beispiel Suchergebnisse, Ticker usw.
- json – Rendern Sie einfach den JSON-Text auf der Kapselserverseite und er wird im browserseitigen Callback bereitgestellt, der bereits in ein JSON-Objekt umgewandelt wurde. Das Senden von JSON-Parametern an den Server kann erfolgen, indem der Wert eines Parameters mithilfe des AsyncParametersList-Objekts auf eine JSON-Zeichenfolge festgelegt wird.
- targetId (*erforderlich, wenn CapsuleType „Inline“ ist) – Gibt den Ort an, an dem eingehendes HTML eingefügt wird, wenn der Kapseltyp „Inline“ ist.
- jsOnload – Gibt eine Javascript-Methode an, die aufgerufen wird, wenn die Injektion abgeschlossen ist. Sehr nützlich für die Registrierung von Autovervollständigern, JQuery-UI-Komponenten und anderen Arten von Seitenladevorgängen. Ein Handle für die Kapsel, in der die jsOnload-Funktion deklariert wurde, wird immer als einzelner Parameter an Ihre js-Funktion gesendet.
- jsReturn – Gibt eine Javascript-Methode an, die aufgerufen wird, wenn zu dieser Seite zurückgekehrt, aber nicht neu geladen wird. Die Rückkehr zu einer Seite kann durch die Verwendung der Zurück-Schaltfläche oder den Aufruf von dtSetCapsuleById ausgelöst werden. Dieser Mechanismus ist nützlich, wenn der Entwickler möchte, dass ein Teil der Ansicht aktualisiert wird oder ein anderer Code ausgeführt wird, wenn er entweder bedingt oder bedingungslos angezeigt wird. Da die Anwendung auf einer einzelnen Seite ausgeführt wird, können Bedingungen als globale Variablen zwischen den Seiten weitergegeben werden. Ein Handle für die Kapsel, in der die jsReturn-Funktion deklariert wurde, wird immer als einzelner Parameter an Ihre js-Funktion gesendet.
- reloadPage (Standard: false) – Wenn dies wahr ist, führt die Navigation zu dieser Seite im Browser-Stack dazu, dass eine neue Version dieses Inhalts vom Server abgerufen wird. Die ursprüngliche Anfrage wird mit allen ursprünglichen Parametern erneut gesendet und die ursprüngliche Rückrufmethode wird aufgerufen.
- skipReloadPageOnPrevious (Standard: false) – Wenn dies wahr ist, blockiert eine Navigation von dieser Seite zu einer Seite im Browser-Stack, die mit einem Neuladen markiert ist, das Neuladen dieser Zielseite. Dies ist besonders nützlich, da der Entwickler steuern kann, ob unterschiedliche Rückflüsse zu einer Neuladeseite dazu führen, dass diese neu geladen wird oder nicht. Beispielsweise ist es beim Zurücknavigieren von einem Modal zu einer Hintergrundseite oft unerwünscht, dass diese Hintergrundseite neu geladen wird. Es kann jedoch dennoch wünschenswert sein, dass dieselbe Hintergrundseite neu geladen wird, wenn von einer Seite, die sie ersetzt hat, zu ihr zurück navigiert wird.
- saveOriginalRequest (Standard: false) – Wenn auf true gesetzt, wird die ursprüngliche Anfrage gespeichert, auch wenn es sich nicht um ein erneutes Laden handelt.
- saveResponse (Standard: false) – Wenn auf true gesetzt, wird das Antwortobjekt im injizierten Kapsel-Div gespeichert. Dies kann später verwendet werden, um den eingefügten Inhalt nach Bearbeitungen durch den Benutzer in seinem ursprünglichen Zustand wiederherzustellen, indem er „restoreAsyncResponse(id)“ aufruft. Der häufigste Fall, in dem diese Funktion gewünscht wird, ist, wenn die Seite über eine Schaltfläche zum Abbrechen verfügt.
- trackPage (Standard: true) – Der Standardwert ist true und gibt an, dass diese Seite zur weiteren Referenz im hinteren Stapel platziert wird. Diese Einstellung ist für die Kapseltypen Daten und JSON nicht relevant, da diese Typen zunächst nicht navigierbar sind. Der Entwickler kann festlegen, dass diese Seite nicht im Backstack platziert werden soll, indem er dieses Attribut auf „false“ setzt. Das Setzen von „trackPage“ auf „false“ ist eine ideale Lösung für Seiten, zu denen der Benutzer nicht zurückkehren und sie dann erneut übermitteln soll, wie z. B. eine „Erstellen“-Seite. Wenn der Benutzer zu einer nicht verfolgten Seite zurückkehrt, überspringt er diese und landet auf der zuvor verfolgten Seite.
- windowTitle – Gibt den Titel an, der oben im Browser festgelegt werden soll. Notwendig, da wir nie Seiten ändern und daher auch nie den Title-Tag im HTML-Header aktualisieren.
- errorPage – Markiert diese Seite als typisierte Ausnahme, die dazu führt, dass der vom Entwickler definierte erfolgreiche Rückruf übersprungen und der vom Entwickler definierte fehlgeschlagene Rückruf aufgerufen wird.
Vorteile der Erstellung einer Django Single Page Application (SPA)
Während SPAs im Allgemeinen mit einem umfangreichen clientseitigen Javascript-Framework in Kombination mit JSON-Diensten gleichgesetzt werden, ist es mit unserem leichten Javascript-SPA-Framework dennoch durchaus möglich, die Vorteile eines SPA zu nutzen und gleichzeitig HTML serverseitig zu rendern.
- Vorteile von Micro Requests bei der Wartung des UI-Status : Das Aktualisieren nur eines Teils der Seite bedeutet, dass nicht jedes Mal eine ganze Seite abgerufen werden muss. Es muss lediglich ein HTML-Snippet oder ein JSON-Objekt vom Server abgerufen werden. Dies erleichtert die Arbeit des UI-Entwicklers erheblich, da er sich nicht um die Vorlage von Kopf-, Menü- und Fußzeilen auf jeder Seite kümmern oder sich um den Status anderer Daten in den Teilen der Seite außerhalb des Aktualisierungsbereichs kümmern muss. Selbst Benutzereingaben, die nicht an den Server übermittelt wurden, sind sicher, solange sie sich außerhalb des aktualisierten Bereichs befinden. Ein Großteil des Aufwands bei der UI-Entwicklung verschwindet durch Mikroanfragen.
- Vorteile von Micro Requests bei Diensten : Da nur bestimmte Teile einer Seite abgerufen werden, werden die an diesen Stellen benötigten Daten spezifischer. Dadurch wird die in Diensten benötigte Geschäftslogik reduziert, was auch den Abruf aus externen Anwendungen wie Datenbanken und Cloud-Diensten vereinfacht.
- Speichern von mehr Status im Browser – Die Kombination aus dem Zwischenspeichern von Ansichten und dem Aktualisieren nur von Teilen der Seite führt dazu, dass viel mehr Status im Browser gespeichert wird. Daher muss der Entwickler nicht so viele Fahrten zum Server unternehmen, um diesen bereits vorhandenen Status zu erhalten. Dies ist selbst bei so einfachen Dingen wie der Formularübermittlung ein großer Vorteil, denn wenn der Server übermittelte Benutzereingaben ablehnt, bleibt die Seite mit dem Formular einfach clientseitig bestehen, wobei alle Benutzereingaben weiterhin vorhanden sind. Wir haben die Seite nie verloren. Andererseits gehen bei einem abgelehnten Formular bei einer vollständigen Seitenaktualisierung alle Benutzereingaben verloren, da der Browser gerade die nächste Seite anzeigt und die Formularseite nicht mehr vorhanden ist. Bei einer abgelehnten vollständigen Seitenaktualisierung müsste die Eingabe also an den Server gesendet und erneut angezeigt werden, wobei das gesamte Formular neu gerendert und die nicht gespeicherte Benutzereingabe wiederhergestellt werden müsste. Die Formularparameter wurden aus der Anfrage wiederhergestellt, jedoch nicht aus der Datenbank, da die Übermittlung ungültig war und die Daten es nie so weit geschafft haben. Wenn Ihnen Ihre Benutzer egal sind, könnten Sie ihnen eine Fehlermeldung anzeigen und sie dazu bringen, alles noch einmal einzugeben, was manchmal geschieht und sehr unfreundlich ist. Im Fall einer einseitigen Django-Anwendung, die Mikroanfragen verwendet, wurde die Seite von Anfang an nie verlassen, und es steht uns frei, eine Fehlermeldung als schwebenden modalen Dialog zurückzusenden.
- Strukturierte Ansichtsnavigation – Zu zuvor gerenderten Ansichten kann mithilfe ihrer Ansichtskennungen navigiert werden. Mithilfe von Kapselattributen können Ansichten als zwischenspeicherbar angegeben oder ein Neuladen erzwungen werden (damit sie nicht veraltet sind).
- Benutzerinteraktionskontrolle – Hatten Sie jemals Probleme damit, dass ein Benutzer eine Taste zweimal drückte? Probleme dieser Art treten nicht mehr auf, da WebRocketX bei Roundtrips zum Server eine transparente Schicht über die Benutzeroberfläche legt, die eine Benutzerinteraktion verhindert. Das Framework zeigt auch einen schönen Sanduhr-Cursor an, um den Benutzer darüber zu informieren, dass etwas passiert.
- Strukturierte Fehlerbehandlung – Serverseitige Fehler und Sitzungszeitüberschreitungen können ein echtes Problem sein, wenn ein Entwickler erwartet, dass Layout oder Daten von einem asynchronen Rückruf stammen. WebRocketX standardisiert die Fehlerbehandlung und das Sitzungs-Timeout-Verhalten, sodass nichts Unvorhersehbares passieren kann. Alle Antworten werden vorab überprüft, bevor der Rückruf an den Entwickler-Rückruf gesendet wird, um etwaige Probleme zu beheben. Es werden auch Hooks bereitgestellt, die es dem Entwickler ermöglichen, benutzerdefiniertes Verhalten für Rückruffehler zu definieren.
Besuchen Sie unsere Website für weitere Details und Dokumentation
Besuchen Sie WebRocketX
