Bem-vindo ao WebRocketX©. Desenvolva aplicativos da web de página única (SPA) 10 vezes mais eficientemente com este sistema de entrega de conteúdo superleve e rápido. WebRocketX é tão intuitivo e eficaz que qualquer pessoa que o utilize imediatamente se pergunta onde a injeção de HTML esteve escondida todos esses anos.
O que é WebRocketX?
WebRocketX é uma API javascript do lado do navegador por meio da qual todas as chamadas assíncronas para o servidor são feitas. Seu principal mecanismo de atualização da página é por meio da inserção DOM de trechos de HTML usando a propriedade innerHTML. Por ter um único ponto de interação com o servidor o desenvolvedor conta com as seguintes funcionalidades fornecidas pela API.
- Fornece um front-end de aplicativo de página única (SPA) para qualquer tecnologia que forneça HTML do back-end, como Springboot, PHP, Laravel, Django, Rails, etc.
- Controle do lado do navegador da interação do usuário durante a chamada assíncrona
- Tratamento de erros do lado do navegador de exceções do lado do servidor
- Cache da visualização lateral do navegador ~ Faça com que o botão Voltar funcione perfeitamente com facilidade.
- Navegação na visualização lateral do navegador
Para uma descrição mais detalhada dos benefícios de usar um SPA WebRocketX, clique aqui Benefícios de usar um SPA WebRocketX
Por que o X? WebRocketX é um híbrido. É uma solução a meio caminho entre o velho mundo dos sites de atualização de página inteira e as soluções JSON JSMVC recentes, como Angular.
- Assim como a arquitetura de página inteira, o WebRocketX espera que o layout vindo do servidor inclua dados. Isso é diferente da arquitetura JSMVC, onde os dados são entregues separadamente do layout em objetos JSON. No entanto, WebRocketX oferece suporte a JSON quando necessário, mas não é um paradigma centrado em JSON.
- Assim como a arquitetura JSMVC, WebRocketX é um aplicativo web de página única (SPA) e depende de chamadas AJAX para enviar dados e trazer novas visualizações.
Outras ótimas coisas sobre WebRocketX Escrito
inteiramente em javascript , usando Jquery como API para o navegador, ele será executado em todos os principais navegadores e até mesmo em dispositivos móveis.
Permite que um desenvolvedor de aplicativos da web crie facilmente uma experiência de usuário rica usando
HTML padrão e javascript, semelhante à experiência de usar um dos principais sistemas operacionais de desktop, como Apple ou Windows. Ainda assim, é extremamente
peso leve executando uma pequena quantidade de código e armazena grande parte do estado do usuário no navegador
minimizando a necessidade de comunicação com o servidor.
Fornece ao desenvolvedor de aplicações web um
plataforma estruturada no qual entregar e gerenciar conteúdo dentro do navegador. No entanto, embora seja estruturado, ainda deixa o desenvolvedor completamente livre para aproveitar o poder e a conveniência do HTML padrão e das folhas de estilo, e para usar bibliotecas de widgets de terceiros.
Inerentemente seguro porque o paradigma de renderização HTML do lado do servidor armazena a autorização do usuário em uma sessão do servidor onde é difícil para o usuário adulterá-la. Além disso, como as visualizações não utilizadas e não autorizadas não são armazenadas em cache no lado do cliente, um malfeitor não tem uma superfície de ataque fornecida a ele. Estruturas como Vue, Angular e React fornecem a todos os usuários a superfície de ataque da conta do administrador por padrão, como visualizações em cache, a menos que o aplicativo Web do administrador seja baixado e gerenciado como um aplicativo separado.
O que WebRocketX não é Não é uma solução do lado do servidor , porque seus componentes front-end (navegador) não estão acoplados aos componentes de memória back-end (servidor). A única relação entre o que é entregue do servidor e a estrutura WebRocketX são algumas convenções simples para entrega do HTML ao navegador. Essa arquitetura desacoplada deixa o desenvolvedor livre para usar qualquer estrutura de back-end que desejar, como Django, Ruby on Rails, Spring MVC, Php, Asp, Struts, etc. O conteúdo é entregue do servidor como HTML e enviado do WebRocketX como parâmetros de formulário. É tão simples assim.
Não é uma solução CSS ou de layout . É uma API de cache e entrega de conteúdo projetada para transformar facilmente seu aplicativo da web dinâmico em um SPA. Um desenvolvedor é livre para fazer o layout de seu aplicativo da web da maneira que desejar. A aparência deste site informativo não indica a aparência do seu site ao usar o WRX.
Não é compatível com SEO para sites estáticos . O uso de WRX para sites estáticos é principalmente um uso apenas conceitual e infelizmente os motores de busca não estão prontos para a indexação de sites SPA. Nenhuma das estruturas de página única, como React, Angular ou Vue, é compatível com SEO, além de suas páginas de destino. Por outro lado, o WRX é uma ótima opção para aplicações web dinâmicas, especialmente sites que exigem login do usuário para gerenciar qualquer tipo de conta ou negócio.
Se você gosta do WebRocketX. Dê-nos uma estrela aqui no Github. Obrigado!
Instalação do seu aplicativo de página única
Crie uma página inicial/de boas-vindas conforme mostrado abaixo e inclua as seguintes bibliotecas nela. A página de destino geralmente é melhor localizada atrás da página de login do formulário. Em outras palavras, você encaminha o usuário para ele após o login. Tudo, exceto a biblioteca jquery, está disponível na pasta de código-fonte raiz WebRocketX encontrada acima.
jquery[latest version].js including the draggable library from jquery UI
domUtil.js
desktopContext.js
webapi.js
webRocketXStyles.css
Exemplo de HTML simples para um aplicativo da Web dinâmico de página única (SPA)
Modelos de exemplo executáveis para PHP e Django podem ser encontrados na pasta de modelos no código-fonte.
Página inicial/de boas-vindas
A página de boas-vindas é a página inicial de seus aplicativos da web, geralmente atrás de sua página de login. A página de boas-vindas é onde começa o seu SPA. As partes principais são que a biblioteca inclui as configurações das variáveis da estrutura, o alvo inicial e o alerta de erro de comunicação.
<!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 > Exemplo de página injetada
Esta página substituirá o conteúdo principal. Colocaremos isso em um arquivo chamado test1.html. O conteúdo é encapsulado em uma cápsula (tag div) configurada com atributos XML de metadados. Os metadados são um tipo de programação declarativa usada pelo framework para decidir o que fazer com seu conteúdo.
< div id =" test1 " class =" metaCapsule " capsuleType =" inline " targetId =" winMain " windowTitle =" Test 1 " >
Hello World Test 1.
</ div > Exemplo de função Javascript
Esta chamada substituirá o conteúdo em winMain. O mais legal é que o botão Voltar do navegador navegará de volta para a página anterior perfeitamente, mas você ainda estará em uma página do SPA o tempo todo. Isso se aplica a qualquer navegação na estrutura e você terá controle completo e simples se decidir que deseja que uma página seja sempre atualizada do servidor quando você navegar de volta para ela, em vez de vir do cache do navegador. Marcar a cápsula de uma página com o atributo reloadPage igual a "true" reenviará a página ao servidor com todos os mesmos parâmetros com os quais foi solicitada originalmente e até mesmo chamará o mesmo retorno de chamada que foi originalmente atribuído a ela, em seu escopo de fechamento original.
function test1 ( ) {
var successfulCallback = function ( innerHTMLObject ) {
alert ( "this my callback" ) ;
}
var webapi = new Webapi ( ) ;
webapi . setSuccessCallbackReference ( successfulCallback ) ;
webapi . setUrl ( "test1.html" ) ;
webapi . submitAsync ( ) ;
} Será que pode ficar mais simples?
Lista completa de atributos de cápsula disponíveis no modo de aplicativo Web dinâmico
A arquitetura cápsula WebRocketX permite ao desenvolvedor controlar grande parte do comportamento da visualização de forma declarativa.
Abaixo são mostrados todos os atributos possíveis da cápsula. Isso lhe dará uma ideia de grande parte da funcionalidade do framework e como ela cobre a maioria dos casos de uso de navegação do usuário.
Os atributos não incluídos na cápsula serão definidos com seus valores padrão. Os atributos obrigatórios estão marcados com um asterisco*.
- id* - Usado para rastrear a página na estrutura WebRocketX. Retransmitido por meio do parâmetro capsuleId no exemplo do modelo. O uso de modelos não é obrigatório.
- class* - Deve ser definido com o valor "metaCapsule". Usado pela estrutura para localizar o div da cápsula.
- capsuleType* - Pode ser definido com os quatro valores a seguir, que determinam como e se a cápsula será injetada.
- inline - O conteúdo será injetado na div especificada pelo atributo targetId.
- modal - O conteúdo será injetado em uma camada modal flutuante.
- data - O conteúdo não será rastreado para navegação pelo framework. O desenvolvedor pode decidir se deseja especificar um targetId ou colocar o conteúdo por conta própria, ou até mesmo usar o conteúdo sem colocá-lo na página. O conteúdo será retornado ao desenvolvedor no callback, como primeiro parâmetro, na forma de um objeto DOM da cápsula e seu conteúdo incluído. Este é o tipo de cápsula ideal para usar em partes menores e atualizáveis da página que não são navegadas como páginas inteiras. Por exemplo, resultados de pesquisa, tickers, etc.
- json - Basta renderizar o texto json no lado do servidor cápsula e ele será entregue no retorno de chamada do lado do navegador já transformado em um objeto json. O envio de parâmetros json para o servidor pode ser feito definindo o valor de um parâmetro para uma string json usando o objeto AsyncParametersList.
- targetId (*obrigatório se capsuleType estiver embutido) - Especifica o local onde o HTML recebido será injetado, quando o tipo de cápsula for "inline".
- jsOnload - Especifica um método javascript que será chamado quando a injeção for concluída. Muito útil para registrar autocompleters, componentes jquery ui e qualquer outro tipo de operação de carregamento de página. Um identificador para a cápsula em que a função jsOnload foi declarada é sempre enviado como um único parâmetro para sua função js.
- jsReturn - Especifica um método javascript que será chamado quando esta página for retornada, mas não recarregada. O retorno a uma página pode ser acionado usando o botão Voltar ou chamando dtSetCapsuleById. Este mecanismo é útil quando o desenvolvedor deseja que parte da visualização seja atualizada, ou qualquer outro código seja executado, após exibição, condicional ou incondicionalmente. Como o aplicativo está sendo executado em uma única página, as condições podem ser retransmitidas entre as páginas como variáveis globais. Um identificador para a cápsula em que a função jsReturn foi declarada é sempre enviado como um único parâmetro para sua função js.
- reloadPage (padrão: false) - Quando isso for verdade, navegar para esta página na pilha do navegador resultará na recuperação de uma nova versão deste conteúdo do servidor. A solicitação original será reenviada, com todos os seus parâmetros originais, e o método de retorno de chamada original será chamado.
- skipReloadPageOnPrevious (padrão: false) - Quando isso for verdade, uma navegação desta página para uma página na pilha do navegador marcada com um recarregamento bloqueará o recarregamento da página de destino. Isso é particularmente útil para permitir que o desenvolvedor controle se diferentes fluxos de retorno para uma página de recarga farão com que ela seja recarregada ou não. Por exemplo, muitas vezes é indesejável ao navegar de volta para uma página de plano de fundo a partir de um modal que essa página de plano de fundo seja recarregada. No entanto, ainda pode ser desejável que a mesma página de plano de fundo seja recarregada quando ela for navegada de volta a partir de uma página que a substituiu.
- saveOriginalRequest (padrão: false) - Quando definido como true, a solicitação original será salva mesmo que não seja uma recarga.
- saveResponse (padrão: false) - Quando definido como true, o objeto de resposta é armazenado na div da cápsula injetada. Isso pode ser usado posteriormente para restaurar o conteúdo injetado ao seu estado original após as edições do usuário, chamando restoreAsyncResponse(id). O caso mais comum em que essa capacidade é desejada é quando a página possui um botão cancelar.
- trackPage (padrão: true) - O padrão é true, especificando que esta página é colocada na pilha de retorno para referência adicional. Essa configuração não é relevante para os tipos de dados de cápsula e json porque esses tipos não são navegáveis para começar. O desenvolvedor pode especificar que esta página não deve ser colocada na pilha de retorno definindo este atributo como falso. Definir trackPage como false é uma solução ideal para páginas que você não deseja que o usuário volte e reenvie, como uma página "criar". Quando o usuário volta para uma página não rastreada, ele a ignora e chega à página rastreada anterior.
- windowTitle - Especifica o título a ser definido na parte superior do navegador. Necessário porque nunca mudamos de página e, portanto, nunca atualizamos a tag de título no cabeçalho HTML.
- errorPage - Marca esta página como uma exceção digitada que resultará no retorno de chamada bem-sucedido definido pelo desenvolvedor sendo ignorado e no retorno de chamada com falha definido pelo desenvolvedor sendo chamado.
Benefícios de fazer um aplicativo Django de página única (SPA)
Embora os SPAs sejam comumente equiparados a uma estrutura javascript pesada do lado do cliente combinada com serviços json, ainda é muito possível obter os benefícios de um SPA e ao mesmo tempo renderizar o lado do servidor HTML, com nossa estrutura SPA javascript leve.
- Vantagens da micro solicitação na manutenção do estado da interface do usuário - Atualizar apenas parte da página significa que uma página inteira não precisa ser puxada todas as vezes. Apenas um snippet html ou objeto json precisa ser recuperado do servidor. Isso torna o trabalho do desenvolvedor de UI muito mais fácil porque ele não precisa fazer coisas como modelar o cabeçalho, o menu e o rodapé em cada página ou se preocupar com o estado de outros dados nas partes da página fora da área de atualização. Mesmo a entrada do usuário que não foi confirmada no servidor é segura, desde que esteja fora da área atualizada. Grande parte da dor do desenvolvimento da UI desaparece com microsolicitações.
- Vantagens da microsolicitação em serviços - Como apenas as partes direcionadas de uma página são recuperadas, os dados necessários nesses locais tornam-se mais específicos. Isso reduz a lógica de negócios necessária nos serviços, o que também simplifica a recuperação de aplicativos externos, como bancos de dados e serviços em nuvem.
- Armazenando mais estado no navegador - A combinação de visualizações de cache e atualização de apenas partes da página resulta na persistência de muito mais estado no navegador. Portanto, o desenvolvedor não precisará fazer tantas viagens ao servidor para obter esse estado já presente. Este é um grande benefício mesmo em coisas tão simples como o envio de formulários, porque quando o servidor rejeita a entrada enviada pelo usuário, a página com o formulário simplesmente persiste no lado do cliente com todas as entradas do usuário ainda presentes. Nunca perdemos a página. Por outro lado, um formulário rejeitado em uma atualização completa da página perderá todas as entradas do usuário, pois o navegador está exibindo a próxima página e a página do formulário desapareceu. Portanto, em um envio de formulário rejeitado com atualização de página inteira, a entrada teria que ser enviada ao servidor e exibida novamente, renderizando novamente o formulário inteiro e restaurando a entrada não persistente do usuário. Os parâmetros do formulário seriam restaurados a partir da solicitação, mas não do banco de dados porque o envio era inválido e os dados nunca chegaram tão longe. Se você não se importa com seus usuários, você pode mostrar a eles uma mensagem de erro e fazê-los digitar tudo novamente, o que às vezes é feito e muito hostil. No caso de uma aplicação Django de página única, usando microsolicitações, a página nunca foi abandonada e estamos livres para enviar de volta uma mensagem de erro como uma caixa de diálogo modal flutuante.
- Navegação de visualização estruturada - visualizações renderizadas anteriormente podem ser navegadas usando seus identificadores de visualização. Usando atributos de cápsula, as visualizações podem ser especificadas como armazenáveis em cache ou forçadas a recarregar (para que não fiquem obsoletas).
- Controle de interação do usuário – Você já teve problemas com um usuário pressionando um botão duas vezes? Esses tipos de problemas não ocorrerão mais porque o WebRocketX coloca uma camada transparente sobre a IU durante viagens de ida e volta ao servidor que impede a interação do usuário. A estrutura também mostra um belo cursor de ampulheta para informar ao usuário que algo está acontecendo.
- Tratamento de erros estruturados - Erros no servidor e tempos limite de sessão podem ser um verdadeiro incômodo quando um desenvolvedor espera que o layout ou os dados venham de um retorno de chamada assíncrono. WebRocketX padroniza o tratamento de erros e o comportamento de tempo limite da sessão para que nada imprevisível possa acontecer. Todas as respostas são pré-selecionadas antes que o retorno de chamada seja enviado ao desenvolvedor para lidar com quaisquer problemas. Ganchos também são fornecidos para permitir que o desenvolvedor defina um comportamento personalizado para falhas de retorno de chamada.
Venha visitar nosso site para mais detalhes e documentação
Visite WebRocketX
