Bienvenue sur WebRocketX©. Développez des applications Web d'une seule page (SPA) 10 fois plus efficacement avec ce système de diffusion de contenu ultra léger et ultra rapide. WebRocketX est si intuitif et efficace que quiconque l'utilise se demande immédiatement où se cache l'injection HTML toutes ces années.
Qu'est-ce que WebRocketX ?
WebRocketX est une API javascript côté navigateur par laquelle tous les appels asynchrones vers le serveur sont effectués. Le principal mécanisme de mise à jour de la page consiste à insérer dans le DOM des extraits de code HTML à l'aide de la propriété innerHTML. En ayant un point d'interaction unique avec le serveur, le développeur dispose des fonctionnalités suivantes fournies par l'API.
- Fournit un frontal d'application monopage (SPA) à toute technologie qui fournit du HTML à partir du backend, comme Springboot, PHP, Laravel, Django, Rails, etc.
- Contrôle côté navigateur de l'interaction de l'utilisateur pendant l'appel asynchrone
- Gestion des erreurs côté navigateur des exceptions côté serveur
- Mise en cache de la vue latérale du navigateur ~ Faites fonctionner facilement le bouton de retour parfaitement.
- Navigation dans la vue latérale du navigateur
Pour une description plus détaillée des avantages de l'utilisation d'un SPA WebRocketX, cliquez ici. Avantages de l'utilisation d'un SPA WebRocketX
Pourquoi le X ? WebRocketX est un hybride. C'est une solution à mi-chemin entre l'ancien monde des sites Web de rafraîchissement pleine page et les solutions JSON JSMVC récentes, comme Angular.
- Comme l'architecture pleine page, WebRocketX s'attend à ce que la mise en page provenant du serveur inclue des données. Ceci est différent de l'architecture JSMVC où les données sont fournies séparément de la disposition dans les objets JSON. Cependant, WebRocketX prend en charge JSON lorsque cela est nécessaire, mais il ne s'agit pas d'un paradigme centré sur JSON.
- Comme l'architecture JSMVC, WebRocketX est une application Web à page unique (SPA) et s'appuie sur des appels AJAX pour soumettre des données et apporter de nouvelles vues.
Autres avantages de WebRocketX Écrit
entièrement en javascript , en utilisant Jquery comme API du navigateur, il fonctionnera sur tous les principaux navigateurs et même sur les appareils mobiles.
Permet à un développeur d'applications Web de créer facilement une expérience utilisateur riche en utilisant
HTML standard et javascript, similaire à l'expérience d'utilisation d'un système d'exploitation de bureau majeur tel qu'Apple ou Windows. Pourtant, c'est extrêmement
poids léger exécutant une petite quantité de code et stocke une grande partie de l'état de l'utilisateur sur le navigateur
minimiser le besoin de communiquer avec le serveur.
Fournit au développeur d'applications Web un
plateforme structurée dans lequel fournir et gérer le contenu dans le navigateur. Pourtant, bien qu'il soit structuré, il laisse toujours le développeur totalement libre d'exploiter la puissance et la commodité du HTML standard et des feuilles de style, et d'utiliser des bibliothèques de widgets tierces.
Intrinsèquement sécurisé car le paradigme de rendu HTML côté serveur stocke l'autorisation de l'utilisateur dans une session serveur où il est difficile pour un utilisateur de la falsifier. De plus, étant donné que les vues inutilisées et non autorisées ne sont pas mises en cache côté client, un acteur malveillant ne dispose pas d’une surface d’attaque. Des frameworks tels que Vue, Angular et React offrent par défaut à tous les utilisateurs la surface d'attaque du compte administrateur, sous forme de vues mises en cache, à moins que l'application Web de l'administrateur ne soit téléchargée et gérée en tant qu'application distincte.
Ce que WebRocketX n'est pas Pas une solution côté serveur , car ses composants front-end (navigateur) ne sont pas couplés aux composants de mémoire back-end (serveur). La seule relation entre ce qui est fourni par le serveur et le framework WebRocketX réside dans quelques conventions simples pour la livraison du code HTML au navigateur. Cette architecture découplée laisse le développeur libre d'utiliser n'importe quel framework backend de son choix, tel que Django, Ruby on Rails, Spring MVC, Php, Asp, Struts, etc. Le contenu est fourni depuis le serveur au format HTML et envoyé depuis WebRocketX en tant que paramètres de formulaire. C'est aussi simple que cela.
Pas une solution CSS ou de mise en page . Il s'agit d'une API de mise en cache et de livraison de contenu conçue pour transformer facilement votre application Web dynamique en SPA. Un développeur est libre de concevoir son application Web comme il le souhaite. L'apparence de ce site Web informatif n'est pas indicative de l'apparence de votre site Web lors de l'utilisation de WRX.
Non conforme au référencement pour les sites Web statiques . L'utilisation de WRX pour des sites Web statiques est avant tout une utilisation conceptuelle et malheureusement, les moteurs de recherche ne sont pas prêts pour l'indexation des sites Web SPA. Aucun des frameworks à page unique tels que React, Angular ou Vue n'est conforme au référencement, au-delà de leurs pages de destination. D'un autre côté, WRX convient très bien aux applications Web dynamiques, en particulier aux sites qui nécessitent qu'un utilisateur se connecte pour gérer tout type de compte ou d'entreprise.
Si vous aimez WebRocketX. Donnez-nous une étoile ici sur Github. Merci!
Installation de votre application à page unique
Créez une page de destination/accueil comme indiqué ci-dessous et incluez-y les bibliothèques suivantes. Il est généralement préférable de situer la page de destination derrière la page de connexion de votre formulaire. En d’autres termes, vous y redirigez l’utilisateur après sa connexion. Tout sauf la bibliothèque jquery est disponible dans le dossier de code source racine WebRocketX trouvé ci-dessus.
jquery[latest version].js including the draggable library from jquery UI
domUtil.js
desktopContext.js
webapi.js
webRocketXStyles.css
Exemple HTML simple pour une application Web dynamique à page unique (SPA)
Des exemples de modèles exécutables pour PHP et Django peuvent être trouvés dans le dossier des modèles dans le code source.
Page d'accueil/d'accueil
La page d'accueil est la page de destination de vos applications Web, généralement derrière votre page de connexion. La page d'accueil est l'endroit où commence votre SPA. Les éléments clés sont que la bibliothèque comprend les paramètres des variables de structure, la cible de départ et l'alerte d'erreur de communication.
<!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 > Exemple de page injectée
Cette page remplacera le contenu principal. Nous allons le mettre dans un fichier appelé test1.html. Le contenu est enveloppé dans une capsule (balise div) configurée avec des attributs XML de métadonnées. Les métadonnées sont un type de programmation déclarative utilisé par le framework pour décider quoi faire de votre contenu.
< div id =" test1 " class =" metaCapsule " capsuleType =" inline " targetId =" winMain " windowTitle =" Test 1 " >
Hello World Test 1.
</ div > Exemple de fonction Javascript
Cet appel remplacera le contenu de winMain. Ce qui est vraiment cool, c'est que le bouton de retour du navigateur reviendra parfaitement à la page précédente, mais vous serez toujours sur une page SPA tout le temps. Cela est vrai pour toute navigation dans le framework et vous disposez d'un contrôle complet et simple si vous décidez que vous souhaitez qu'une page soit toujours actualisée à partir du serveur lorsque vous y revenez, au lieu de provenir du cache du navigateur. Marquer la capsule d'une page avec l'attribut reloadPage égal à "true" soumettra à nouveau la page au serveur avec tous les mêmes paramètres avec lesquels elle a été demandée à l'origine et appellera même le même rappel qui lui a été initialement attribué, dans sa portée de fermeture d'origine.
function test1 ( ) {
var successfulCallback = function ( innerHTMLObject ) {
alert ( "this my callback" ) ;
}
var webapi = new Webapi ( ) ;
webapi . setSuccessCallbackReference ( successfulCallback ) ;
webapi . setUrl ( "test1.html" ) ;
webapi . submitAsync ( ) ;
} Est-ce que cela peut être plus simple ?
Liste complète des attributs de capsule disponibles en mode application Web dynamique
L'architecture capsule WebRocketX permet au développeur de contrôler une grande partie du comportement de l'affichage de manière déclarative.
Vous trouverez ci-dessous tous les attributs possibles de la capsule. Cela vous donnera une idée d'une grande partie des fonctionnalités du framework et de la manière dont il couvre la majorité des cas d'utilisation de la navigation utilisateur.
Les attributs non inclus dans la capsule seront définis sur leurs valeurs par défaut. Les attributs obligatoires sont marqués d'un astérisque*.
- id* - Utilisé pour garder une trace de la page dans le framework WebRocketX. Relayé via le paramètre capsuleId dans l'exemple de modèle. L'utilisation de modèles n'est pas obligatoire.
- class* - Doit être défini sur la valeur "metaCapsule". Utilisé par le framework pour localiser la capsule div.
- capsuleType* - Peut être défini sur les quatre valeurs suivantes, qui déterminent comment et si la capsule sera injectée.
- inline - Le contenu sera injecté dans le div spécifié par l'attribut targetId.
- modal - Le contenu sera injecté dans une couche modale flottante.
- data - Le contenu ne sera pas suivi pour la navigation par le framework. Le développeur peut décider de spécifier un targetId ou de placer le contenu lui-même, ou même d'utiliser le contenu sans le placer dans la page. Le contenu sera renvoyé au développeur dans le callback, en premier paramètre, sous la forme d'un objet DOM de la capsule et de son contenu inclus. Il s’agit du type de capsule idéal à utiliser pour les petites parties actualisables de la page qui ne sont pas parcourues comme des pages entières. Par exemple, les résultats de recherche, les tickers, etc.
- json - Restituez simplement le texte json côté serveur de capsule et il sera livré dans le rappel côté navigateur déjà transformé en objet json. L'envoi de paramètres json au serveur peut être effectué en définissant la valeur d'un paramètre sur une chaîne json à l'aide de l'objet AsyncParametersList.
- targetId (*obligatoire si capsuleType est en ligne) - Spécifie l'emplacement où le HTML entrant sera injecté, lorsque le type de capsule est "en ligne".
- jsOnload - Spécifie une méthode javascript qui sera appelée une fois l'injection terminée. Très utile pour enregistrer les compléteurs automatiques, les composants jquery ui et tout autre type d'opérations de type chargement de page. Un handle vers la capsule dans laquelle la fonction jsOnload a été déclarée est toujours envoyé en tant que paramètre unique à votre fonction js.
- jsReturn - Spécifie une méthode javascript qui sera appelée lorsque cette page sera renvoyée mais pas rechargée. Le retour à une page peut être déclenché en utilisant le bouton Précédent ou en appelant dtSetCapsuleById. Ce mécanisme est utile lorsque le développeur souhaite qu'une partie de la vue soit actualisée, ou que tout autre code soit exécuté, lors de l'affichage, de manière conditionnelle ou inconditionnelle. Étant donné que l'application s'exécute sur une seule page, les conditions peuvent être relayées entre les pages sous forme de variables globales. Un handle vers la capsule dans laquelle la fonction jsReturn a été déclarée est toujours envoyé en tant que paramètre unique à votre fonction js.
- reloadPage (par défaut : false) - Lorsque cela est vrai, la navigation vers cette page dans la pile du navigateur entraînera la récupération d'une nouvelle version de ce contenu à partir du serveur. La requête d'origine sera renvoyée, avec tous ses paramètres d'origine, et la méthode de rappel d'origine sera appelée.
- skipReloadPageOnPrevious (par défaut : false) - Lorsque cela est vrai, une navigation de cette page vers une page de la pile du navigateur marquée d'un rechargement bloquera le rechargement de cette page de destination. Ceci est particulièrement utile pour permettre au développeur de contrôler si différents flux de retour vers une page de rechargement entraîneront son rechargement ou non. Par exemple, il n'est souvent pas souhaitable, lors du retour à une page d'arrière-plan à partir d'un modal, de recharger cette page d'arrière-plan. Cependant, il peut toujours être souhaitable que cette même page d'arrière-plan se recharge lorsqu'on y revient à partir d'une page qui l'a remplacée.
- saveOriginalRequest (par défaut : false) - Lorsqu'elle est définie sur true, la demande d'origine sera enregistrée même s'il ne s'agit pas d'un rechargement.
- saveResponse (par défaut : false) - Lorsqu'il est défini sur true, l'objet de réponse est stocké dans le div de capsule injecté. Cela peut être utilisé ultérieurement pour restaurer le contenu injecté à son état d'origine après les modifications effectuées par l'utilisateur, en appelant recoveryAsyncResponse(id). Le cas le plus courant où cette capacité est souhaitée est lorsque la page dispose d’un bouton d’annulation.
- trackPage (par défaut : true) - La valeur par défaut est true, spécifiant que cette page est placée dans la pile arrière pour référence ultérieure. Ce paramètre n'est pas pertinent pour les types de capsules de données et json car ces types ne sont pas navigables au départ. Le développeur peut spécifier que cette page ne doit pas être placée dans la pile arrière en définissant cet attribut sur false. Définir trackPage sur false est une solution idéale pour les pages sur lesquelles vous ne souhaitez pas que l'utilisateur revienne puis les soumette à nouveau, comme une page de « création ». Lorsque l'utilisateur revient à une page non suivie, il la saute et atterrit sur la page suivie qui la précède.
- windowTitle - Spécifie le titre à définir en haut du navigateur. Nécessaire car nous ne changeons jamais de page et donc ne mettons jamais à jour la balise title dans l’entête html.
- errorPage - Marque cette page comme une exception typée qui entraînera l'omission du rappel réussi défini par le développeur et l'appel du rappel d'échec défini par le développeur.
Avantages de créer une application Django Single Page (SPA)
Bien que les SPA soient généralement assimilés à un framework javascript côté client lourd combiné à des services json, il est toujours très possible de bénéficier des avantages d'un SPA tout en continuant à restituer côté serveur HTML, avec notre framework SPA javascript léger.
- Avantages des micro-requêtes dans la maintenance de l'état de l'interface utilisateur - L'actualisation d'une partie seulement de la page signifie qu'une page entière n'a pas besoin d'être extraite à chaque fois. Seul un extrait de code HTML ou un objet JSON doit être récupéré du serveur. Cela rend le travail du développeur d'interface utilisateur beaucoup plus facile, car il n'a pas à faire des choses comme modèler l'en-tête, le menu et le pied de page dans chaque page ou à se soucier de l'état des autres données sur les parties de la page en dehors de la zone d'actualisation. Même les entrées utilisateur qui n'ont pas été validées sur le serveur sont sécurisées tant qu'elles se trouvent en dehors de la zone actualisée. Une grande partie des difficultés liées au développement de l’interface utilisateur disparaît avec les micro-requêtes.
- Avantages des micro-requêtes dans les services - Étant donné que seules les parties ciblées d'une page sont récupérées, les données nécessaires à ces endroits deviennent plus spécifiques. Cela réduit la logique métier nécessaire dans les services, ce qui simplifie également la récupération à partir d'applications externes telles que les bases de données et les services cloud.
- Stockage de plus d'état dans le navigateur - La combinaison de la mise en cache des vues et de l'actualisation de certaines parties de la page entraîne la persistance de beaucoup plus d'état dans le navigateur. Par conséquent, le développeur n’aura pas besoin de faire autant de déplacements vers le serveur pour obtenir cet état déjà présent. C'est un grand avantage, même pour des choses aussi simples que la soumission d'un formulaire, car lorsque le serveur rejette les entrées utilisateur soumises, la page contenant le formulaire persiste simplement côté client avec toutes ses entrées utilisateur toujours présentes. Nous n'avons jamais perdu la page. D'un autre côté, un formulaire rejeté lors d'une actualisation complète de la page perdra toutes les entrées de l'utilisateur, puisque le navigateur est en train d'afficher la page suivante et que la page du formulaire a disparu. Ainsi, lors d'une actualisation d'une page complète d'une soumission de formulaire rejetée, l'entrée devrait être envoyée au serveur et réaffichée, ce qui restituerait l'intégralité du formulaire et restaurerait l'entrée utilisateur non persistante. Les paramètres du formulaire seraient restaurés à partir de la demande mais pas à partir de la base de données car la soumission n'était pas valide et les données ne sont jamais allées aussi loin. Si vous ne vous souciez pas de vos utilisateurs, vous pouvez leur montrer un message d'erreur et leur faire tout retaper, ce qui est parfois très peu convivial. Dans le cas d'une application Django monopage, utilisant des micro-requêtes, la page n'a jamais été quittée au départ, et nous sommes libres de renvoyer un message d'erreur sous forme de boîte de dialogue modale flottante.
- Navigation dans les vues structurées : il est possible d'accéder aux vues précédemment rendues à l'aide de leurs identifiants de vue. À l'aide des attributs de capsule, les vues peuvent être spécifiées comme pouvant être mises en cache ou forcées à être rechargées (afin qu'elles ne deviennent pas obsolètes).
- Contrôle de l'interaction utilisateur - Avez-vous déjà eu des problèmes avec un utilisateur appuyant deux fois sur un bouton ? Ce genre de problèmes ne se produira plus car WebRocketX place une couche transparente sur l'interface utilisateur lors des allers-retours vers le serveur, ce qui empêche l'interaction de l'utilisateur. Le framework affiche également un joli curseur en sablier pour informer l'utilisateur que quelque chose se passe.
- Gestion structurée des erreurs : les erreurs côté serveur et les délais d'expiration de session peuvent être un véritable problème lorsqu'un développeur s'attend à ce que la mise en page ou les données proviennent d'un rappel asynchrone. WebRocketX standardise la gestion des erreurs et le comportement d'expiration de session afin que rien d'imprévisible ne puisse se produire. Toutes les réponses sont présélectionnées avant que le rappel ne soit envoyé au rappel du développeur pour gérer tout problème. Des hooks sont également fournis pour permettre au développeur de définir un comportement personnalisé en cas d'échec de rappel.
Venez visiter notre site Web pour plus de détails et de documentation
Visitez WebRocketX
