Bienvenido a WebRocketX©. Desarrolle aplicaciones web de una sola página (SPA) 10 veces más eficientemente con este sistema de entrega de contenido súper liviano y súper rápido. WebRocketX es tan intuitivo y eficaz que cualquiera que lo utilice se pregunta inmediatamente dónde se ha estado escondiendo la inyección HTML durante todos estos años.
¿Qué es WebRocketX?
WebRocketX es una API de JavaScript del lado del navegador a través de la cual se realizan todas las llamadas asíncronas al servidor. Su mecanismo principal para actualizar la página es mediante la inserción DOM de fragmentos de HTML utilizando la propiedad internalHTML. Al tener un único punto de interacción con el servidor, el desarrollador tiene la siguiente funcionalidad proporcionada por la API.
- Proporciona una interfaz de aplicación de página única (SPA) para cualquier tecnología que entregue HTML desde el backend, como Springboot, PHP, Laravel, Django, Rails, etc.
- Control del lado del navegador de la interacción del usuario durante la llamada asíncrona
- Manejo de errores del lado del navegador de excepciones del lado del servidor
- Almacenamiento en caché de la vista lateral del navegador ~ Haga que el botón Atrás funcione perfectamente fácilmente.
- Navegación de la vista lateral del navegador
Para obtener una descripción más detallada de los beneficios de utilizar un WebRocketX SPA, vaya aquí Beneficios de utilizar un WebRocketX SPA
¿Por qué la X? WebRocketX es un híbrido. Es una solución a medio camino entre el viejo mundo de los sitios web de actualización de página completa y las soluciones JSON JSMVC recientes, como Angular.
- Al igual que la arquitectura de página completa, WebRocketX espera que el diseño proveniente del servidor incluya datos. Esto es diferente a la arquitectura JSMVC, donde los datos se entregan por separado del diseño en objetos JSON. Sin embargo, WebRocketX admite JSON cuando es necesario, pero no es un paradigma centrado en JSON.
- Al igual que la arquitectura JSMVC, WebRocketX es una aplicación web de página única (SPA) y se basa en llamadas AJAX para enviar datos y generar nuevas vistas.
Otras ventajas interesantes de WebRocketX Escrito
completamente en javascript , al utilizar Jquery como API para el navegador, se ejecutará en todos los navegadores principales e incluso en dispositivos móviles.
Permite a un desarrollador de aplicaciones web crear fácilmente una rica experiencia de usuario utilizando
HTML estándar y javascript, similar a la experiencia de utilizar un importante sistema operativo de escritorio como Apple o Windows. Sin embargo, es extremadamente
peso ligero ejecuta una pequeña cantidad de código y almacena gran parte del estado del usuario en el navegador
minimizando la necesidad de comunicarse con el servidor.
Proporciona al desarrollador de aplicaciones web una
plataforma estructurada en el que entregar y administrar contenido dentro del navegador. Sin embargo, aunque está estructurado, deja al desarrollador completamente libre para aprovechar el poder y la conveniencia del HTML estándar y las hojas de estilo, y para utilizar bibliotecas de widgets de terceros.
Intrínsecamente seguro porque el paradigma de representación HTML del lado del servidor almacena la autorización del usuario en una sesión del servidor donde es difícil para un usuario manipularla. Además, dado que las vistas no utilizadas y no autorizadas no se almacenan en caché del lado del cliente, un mal actor no tiene una superficie de ataque proporcionada. Marcos como Vue, Angular y React brindan a todos los usuarios la superficie de ataque de la cuenta de administrador de forma predeterminada, como vistas en caché, a menos que la aplicación web del administrador se descargue y administre como una aplicación separada.
Lo que WebRocketX no es No es una solución del lado del servidor , porque sus componentes de front-end (navegador) no están acoplados a los componentes de memoria de back-end (servidor). La única relación entre lo que se entrega desde el servidor y el marco WebRocketX son algunas convenciones simples para la entrega del HTML al navegador. Esta arquitectura desacoplada deja al desarrollador libre de utilizar cualquier marco de backend que desee, como Django, Ruby on Rails, Spring MVC, Php, Asp, Struts, etc. El contenido se entrega desde el servidor como HTML y se envía desde WebRocketX como parámetros de formulario. Es tan simple como eso.
No es una solución CSS o de diseño . Es una API de entrega y almacenamiento en caché de contenido diseñada para convertir fácilmente su aplicación web dinámica en un SPA. Un desarrollador es libre de diseñar su aplicación web como desee. La apariencia de este sitio web informativo no es indicativo de cómo se verá su sitio web cuando utilice WRX.
No compatible con SEO para sitios web estáticos . El uso de WRX para sitios web estáticos es principalmente un uso conceptual y desafortunadamente los motores de búsqueda no están preparados para la indexación de sitios web SPA. Ninguno de los marcos de una sola página, como React, Angular o Vue, es compatible con SEO, más allá de sus páginas de destino. Por otro lado, WRX es una muy buena opción para aplicaciones web dinámicas, especialmente sitios que requieren que un usuario inicie sesión para administrar cualquier tipo de cuenta o negocio.
Si te gusta WebRocketX. Danos una estrella aquí en Github. ¡Gracias!
Instalación de su aplicación de una sola página
Cree una página de inicio/bienvenida como se muestra a continuación e incluya las siguientes bibliotecas en ella. Por lo general, es mejor ubicar la página de destino detrás de la página de inicio de sesión del formulario. En otras palabras, reenvía al usuario después de iniciar sesión. Todo, excepto la biblioteca jquery, está disponible en la carpeta del código fuente raíz de WebRocketX que se encuentra arriba.
jquery[latest version].js including the draggable library from jquery UI
domUtil.js
desktopContext.js
webapi.js
webRocketXStyles.css
Ejemplo HTML simple para una aplicación web dinámica de una sola página (SPA)
Las plantillas de ejemplo ejecutables para PHP y Django se pueden encontrar en la carpeta de plantillas del código fuente.
Página de inicio/bienvenida
La página de bienvenida es la página de inicio de su aplicación web, generalmente detrás de su página de inicio de sesión. La página de bienvenida es donde comienza su SPA. Las partes clave son que la biblioteca incluye la configuración de las variables del marco, el objetivo inicial y la alerta de error de comunicaciones.
<!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 > Ejemplo de página inyectada
Esta página reemplazará el contenido principal. Lo pondremos en un archivo llamado test1.html. El contenido está envuelto en una cápsula (etiqueta div) configurada con atributos XML de metadatos. Los metadatos son un tipo de programación declarativa utilizada por el marco para decidir qué hacer con su contenido.
< div id =" test1 " class =" metaCapsule " capsuleType =" inline " targetId =" winMain " windowTitle =" Test 1 " >
Hello World Test 1.
</ div > Ejemplo de función de JavaScript
Esta llamada reemplazará el contenido en winMain. Lo realmente interesante es que el botón Atrás del navegador navegará perfectamente a la página anterior, pero seguirás en una página SPA todo el tiempo. Esto se aplica a cualquier navegación en el marco y usted tiene un control completo y simple si decide que desea que una página siempre se actualice desde el servidor cuando regresa a él, en lugar de provenir de la memoria caché del navegador. Marcar la cápsula de una página con el atributo reloadPage igual a "verdadero" volverá a enviar la página al servidor con los mismos parámetros con los que se solicitó originalmente e incluso llamará a la misma devolución de llamada que se le asignó originalmente, en su alcance de cierre original.
function test1 ( ) {
var successfulCallback = function ( innerHTMLObject ) {
alert ( "this my callback" ) ;
}
var webapi = new Webapi ( ) ;
webapi . setSuccessCallbackReference ( successfulCallback ) ;
webapi . setUrl ( "test1.html" ) ;
webapi . submitAsync ( ) ;
} ¿Puede ser más sencillo?
Lista completa de atributos de cápsula disponibles en el modo de aplicación web dinámica
La arquitectura de cápsula WebRocketX permite al desarrollador controlar gran parte del comportamiento de la vista de forma declarativa.
A continuación se muestran todos los atributos posibles de la cápsula. Esto le dará una idea de gran parte de la funcionalidad de los marcos y de cómo cubre la mayoría de los casos de uso de navegación del usuario.
Los atributos no incluidos en la cápsula se establecerán en sus valores predeterminados. Los atributos obligatorios están marcados con un asterisco*.
- id* : se utiliza para realizar un seguimiento de la página en el marco WebRocketX. Transmitido a través del parámetro CapsuleId en el ejemplo de plantilla. No es necesario utilizar plantillas.
- clase* : debe establecerse en el valor "metaCapsule". Utilizado por el marco para localizar el div cápsula.
- CapsuleType* : se puede configurar en los siguientes cuatro valores, lo que determina cómo y si se inyectará la cápsula.
- inline: el contenido se inyectará en el div especificado por el atributo targetId.
- modal: el contenido se inyectará en una capa modal flotante.
- datos: el marco no rastreará el contenido para la navegación. El desarrollador puede decidir si desea especificar un targetId o colocar el contenido por su cuenta, o incluso utilizar el contenido sin colocarlo en la página. El contenido se devolverá al desarrollador en la devolución de llamada, como primer parámetro, en forma de objeto DOM de la cápsula y su contenido incluido. Este es el tipo de cápsula ideal para usar en partes más pequeñas de la página que se pueden actualizar y por las que no se navega como páginas completas. Por ejemplo, resultados de búsqueda, tickers, etc.
- json: simplemente renderice el texto json en el lado del servidor de la cápsula y se entregará en la devolución de llamada del lado del navegador ya convertido en un objeto json. El envío de parámetros json al servidor se puede realizar estableciendo el valor de un parámetro en una cadena json utilizando el objeto AsyncParametersList.
- targetId (*obligatorio si el tipo de cápsula está en línea) : especifica la ubicación donde se inyectará el html entrante, cuando el tipo de cápsula está "en línea".
- jsOnload : especifica un método javascript que se llamará cuando se complete la inyección. Muy útil para registrar autocompletas, componentes jquery ui y cualquier otro tipo de operaciones de carga de página. Un identificador de la cápsula en la que se declaró la función jsOnload siempre se envía como un parámetro único a su función js.
- jsReturn : especifica un método javascript que se llamará cuando se regrese a esta página pero no se vuelva a cargar. El regreso a una página se puede activar usando el botón Atrás o llamando a dtSetCapsuleById. Este mecanismo es útil cuando el desarrollador desea que se actualice parte de la vista, o que se ejecute cualquier otro código, al mostrarse de forma condicional o incondicional. Dado que la aplicación se ejecuta en una sola página, las condiciones se pueden transmitir entre páginas como variables globales. Un identificador de la cápsula en la que se declaró la función jsReturn siempre se envía como un parámetro único a su función js.
- reloadPage (predeterminado: falso): cuando esto es cierto, al navegar a esta página en la pila del navegador se recuperará una versión nueva de este contenido del servidor. Se reenviará la solicitud original, con todos sus parámetros originales, y se llamará al método de devolución de llamada original.
- skipReloadPageOnPrevious (predeterminado: falso): cuando esto es cierto, una navegación desde esta página a una página en la pila del navegador que está marcada con una recarga bloqueará la recarga de esa página de destino. Esto es particularmente útil para permitir al desarrollador controlar si diferentes flujos de retorno a una página de recarga harán que se recargue o no. Por ejemplo, a menudo no es deseable volver a una página de fondo desde un modal para que esa página de fondo se vuelva a cargar. Sin embargo, aún puede ser deseable que esa misma página de fondo se vuelva a cargar cuando se navega de regreso desde una página que la reemplazó.
- saveOriginalRequest (predeterminado: falso): cuando se establece en verdadero, la solicitud original se guardará incluso si no se trata de una recarga.
- saveResponse (predeterminado: falso): cuando se establece en verdadero, el objeto de respuesta se almacena en el div de la cápsula inyectada. Esto se puede utilizar más adelante para restaurar el contenido inyectado a su estado original después de las modificaciones realizadas por el usuario, llamando a recoveryAsyncResponse(id). El caso más común en el que se desea esta capacidad es cuando la página tiene un botón de cancelar.
- trackPage (predeterminado: verdadero): el valor predeterminado es verdadero, especificando que esta página se coloca en la pila posterior para mayor referencia. Esta configuración no es relevante para los tipos de datos de cápsula y json porque, para empezar, esos tipos no son navegables. El desarrollador puede especificar que esta página no se debe colocar en la pila de actividades estableciendo este atributo en falso. Configurar trackPage en falso es una solución ideal para páginas a las que no desea que el usuario regrese y luego vuelva a enviar, como una página de "creación". Cuando el usuario regresa a una página sin seguimiento, la saltará y llegará a la página con seguimiento que la precede.
- windowTitle : especifica el título que se establecerá en la parte superior del navegador. Necesario porque nunca cambiamos de página y, por lo tanto, nunca actualizamos la etiqueta de título en el encabezado html.
- errorPage : marca esta página como una excepción escrita, lo que provocará que se omita la devolución de llamada exitosa definida por el desarrollador y que se llame a la devolución de llamada fallida definida por el desarrollador.
Beneficios de crear una aplicación de página única (SPA) de Django
Si bien los SPA se equiparan comúnmente con un marco de JavaScript pesado del lado del cliente combinado con servicios JSON, aún es muy posible obtener los beneficios de un SPA mientras se sigue procesando el lado del servidor HTML, con nuestro marco de SPA de JavaScript liviano.
- Ventajas de las microsolicitudes en el mantenimiento del estado de la interfaz de usuario : actualizar solo una parte de la página significa que no es necesario extraer una página completa cada vez. Sólo es necesario recuperar del servidor un fragmento html o un objeto json. Esto hace que el trabajo del desarrollador de UI sea mucho más fácil porque no tiene que hacer cosas como crear plantillas para el encabezado, el menú y el pie de página en cada página o preocuparse por el estado de otros datos en las partes de la página fuera del área de actualización. Incluso la entrada del usuario que no se ha confirmado en el servidor es segura siempre que esté fuera del área actualizada. Gran parte del dolor del desarrollo de la interfaz de usuario desaparece con las microsolicitudes.
- Ventajas de las microsolicitudes en los servicios : dado que solo se recuperan partes específicas de una página, los datos necesarios en estos lugares se vuelven más específicos. Esto reduce la lógica empresarial necesaria en los servicios, lo que también simplifica la recuperación desde aplicaciones externas, como bases de datos y servicios en la nube.
- Almacenamiento de más estado en el navegador : la combinación de almacenar en caché las vistas y actualizar solo partes de la página da como resultado que se conserve mucho más estado en el navegador. Por lo tanto, el desarrollador no necesitará realizar tantos viajes al servidor para obtener este estado ya presente. Este es un gran beneficio incluso en cosas tan simples como el envío de formularios, porque cuando el servidor rechaza la entrada del usuario enviada, la página con el formulario simplemente persiste en el lado del cliente con todas las entradas del usuario aún presentes. Nunca perdimos la página. Por otro lado, un formulario rechazado en una actualización de página completa perderá toda la entrada del usuario, ya que el navegador está en el proceso de mostrar la página siguiente y la página del formulario desapareció. Por lo tanto, en un envío de formulario rechazado de actualización de página completa, la entrada tendría que enviarse al servidor y volver a mostrarse, volviendo a representar el formulario completo y restaurando la entrada del usuario no persistente. Los parámetros del formulario se restaurarían a partir de la solicitud pero no de la base de datos porque el envío no era válido, por lo que los datos nunca llegaron tan lejos. Si no le importan sus usuarios, puede mostrarles un mensaje de error y hacer que escriban todo de nuevo, lo cual se hace a veces y es muy poco amigable. En el caso de una aplicación Django de una sola página, que utiliza microsolicitudes, la página nunca se abandonó para empezar y somos libres de enviar un mensaje de error como un cuadro de diálogo modal flotante.
- Navegación de vista estructurada : se puede navegar a las vistas renderizadas previamente utilizando sus identificadores de vista. Al utilizar los atributos de la cápsula, las vistas se pueden especificar como almacenables en caché o forzar la recarga (para que no queden obsoletas).
- Control de interacción del usuario : ¿Alguna vez ha tenido problemas con un usuario que presiona un botón dos veces? Ese tipo de problemas ya no ocurrirán porque WebRocketX coloca una capa transparente sobre la interfaz de usuario durante los viajes de ida y vuelta al servidor que impide la interacción del usuario. El marco también muestra un bonito cursor de reloj de arena para que el usuario sepa que algo está sucediendo.
- Manejo estructurado de errores : los errores del lado del servidor y los tiempos de espera de sesión pueden ser una verdadera molestia cuando un desarrollador espera que el diseño o los datos provengan de una devolución de llamada asíncrona. WebRocketX estandariza el manejo de errores y el comportamiento del tiempo de espera de la sesión para que no pueda suceder nada impredecible. Todas las respuestas se seleccionan previamente antes de enviar la devolución de llamada al desarrollador para solucionar cualquier problema. También se proporcionan enlaces para permitir al desarrollador definir un comportamiento personalizado en caso de errores de devolución de llamada.
Visite nuestro sitio web para obtener más detalles y documentación.
Visita WebRocketX
