Добро пожаловать в WebRocketX©. Разрабатывайте одностраничные веб-приложения (SPA) в 10 раз эффективнее с помощью этой сверхлегкой и сверхбыстрой системы доставки контента. WebRocketX настолько интуитивно понятен и эффективен, что любой, кто его использует, сразу же задается вопросом, где все эти годы скрывалась HTML-инъекция.
Что такое WebRocketX?
WebRocketX — это API JavaScript на стороне браузера, через который выполняются все асинхронные вызовы к серверу. Основной механизм обновления страницы заключается в вставке фрагментов HTML в DOM с использованием свойства InnerHTML. Имея единую точку взаимодействия с сервером, разработчик получает следующие функциональные возможности, предоставляемые API.
- Предоставляет интерфейс одностраничного приложения (SPA) для любой технологии, которая доставляет HTML из серверной части, например Springboot, PHP, Laravel, Django, Rails и т. д.
- Контроль взаимодействия пользователя со стороны браузера во время асинхронного вызова
- Обработка ошибок на стороне браузера для исключений на стороне сервера
- Кэширование вида сбоку браузера ~ Легко заставить кнопку «Назад» работать идеально.
- Навигация в режиме просмотра сбоку браузера
Для более подробного описания преимуществ использования WebRocketX SPA перейдите сюда. Преимущества использования WebRocketX SPA.
Почему Х? WebRocketX — это гибрид. Это решение находится на полпути между старым миром веб-сайтов с полным обновлением страниц и последними решениями JSON JSMVC, такими как Angular.
- Как и полностраничная архитектура, WebRocketX ожидает, что макет, поступающий с сервера, будет включать данные. Это отличается от архитектуры JSMVC, где данные доставляются отдельно от макета в объектах JSON. Однако WebRocketX поддерживает JSON, когда это необходимо, но не является парадигмой, ориентированной на JSON.
- Как и архитектура JSMVC, WebRocketX представляет собой одностраничное веб-приложение (SPA), которое использует вызовы AJAX для отправки данных и создания новых представлений.
Другие замечательные особенности WebRocketX Написано
полностью на JavaScript , используя Jquery в качестве API для браузера, он будет работать во всех основных браузерах и даже на мобильных устройствах.
Позволяет разработчику веб-приложений легко создавать богатый пользовательский интерфейс, используя
стандартный HTML и javascript, аналогично опыту использования основных настольных операционных систем, таких как Apple или Windows. Тем не менее, это чрезвычайно
легкий вес выполняет небольшой объем кода и сохраняет большую часть состояния пользователя в браузере
минимизация потребности в общении с сервером.
Предоставляет разработчику веб-приложений
структурированная платформа для доставки контента и управления им в браузере. Тем не менее, несмотря на то, что он структурирован, он по-прежнему дает разработчику полную свободу использовать мощь и удобство стандартных HTML и таблиц стилей, а также использовать сторонние библиотеки виджетов.
Абсолютно безопасный потому что парадигма рендеринга html на стороне сервера хранит авторизацию пользователя в сеансе сервера, где пользователю трудно подделать. Более того, поскольку неиспользуемые и неавторизованные представления не кэшируются на стороне клиента, злоумышленник не имеет возможности для атаки. Такие платформы, как Vue, Angular и React, по умолчанию предоставляют всем пользователям поверхность атаки учетной записи администратора в виде кэшированных представлений, если только веб-приложение администратора не загружается и не управляется как отдельное приложение.
Чем WebRocketX не является Не серверное решение , поскольку его внешние компоненты (браузер) не связаны с внутренними (серверными) компонентами памяти. Единственная связь между тем, что доставляется с сервера, и платформой WebRocketX — это несколько простых соглашений о доставке HTML в браузер. Эта разделенная архитектура дает разработчику право использовать любую внутреннюю структуру, которую он пожелает, например Django, Ruby on Rails, Spring MVC, Php, Asp, Struts и т. д. Контент доставляется с сервера в виде HTML и отправляется из WebRocketX в качестве параметров формы. Это так просто.
Не CSS или решение для макета . Это API-интерфейс кэширования и доставки контента, предназначенный для легкого превращения вашего динамического веб-приложения в SPA. Разработчик может размещать свое веб-приложение так, как пожелает. Внешний вид этого информационного веб-сайта не указывает на то, как будет выглядеть ваш веб-сайт при использовании WRX.
Не совместим с SEO для статических веб-сайтов. . Использование WRX для статических веб-сайтов — это, прежде всего, только концепция, и, к сожалению, поисковые системы не готовы к индексации веб-сайтов SPA. Ни одна из одностраничных фреймворков, таких как React, Angular или Vue, не является SEO-совместимой, за исключением их целевых страниц. С другой стороны, WRX очень хорошо подходит для динамических веб-приложений, особенно сайтов, которые требуют от пользователя входа в систему для управления любой учетной записью или бизнесом.
Если вам нравится WebRocketX. Дайте нам звезду здесь, в Github. Спасибо!
Установка вашего одностраничного приложения
Создайте целевую/приветственную страницу, как показано ниже, и включите в нее следующие библиотеки. Целевую страницу обычно лучше всего располагать за страницей входа в форму. Другими словами, вы пересылаете пользователя к нему после того, как он войдет в систему. Все, кроме библиотеки jquery, доступно в корневой папке исходного кода WebRocketX, указанной выше.
jquery[latest version].js including the draggable library from jquery UI
domUtil.js
desktopContext.js
webapi.js
webRocketXStyles.css
Простой пример HTML для динамического одностраничного веб-приложения (SPA)
Рабочие примеры шаблонов для PHP и Django можно найти в папке шаблонов исходного кода.
Целевая/приветственная страница
Страница приветствия — это целевая страница вашего веб-приложения, обычно расположенная за страницей входа в систему. Страница приветствия — это то, с чего начинается ваше SPA. Ключевыми частями являются библиотека, включающая настройки переменных платформы, начальную цель и предупреждение об ошибках связи.
<!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 > Пример внедренной страницы
Эта страница заменит основной контент. Мы поместим его в файл test1.html. Содержимое заключено в капсулу (тег div), настроенную с использованием XML-атрибутов метаданных. Метаданные — это тип декларативного программирования, используемый платформой для решения, что делать с вашим контентом.
< div id =" test1 " class =" metaCapsule " capsuleType =" inline " targetId =" winMain " windowTitle =" Test 1 " >
Hello World Test 1.
</ div > Пример функции Javascript
Этот вызов заменит содержимое в winMain. Самое замечательное то, что кнопка «Назад» в браузере позволяет идеально вернуться на предыдущую страницу, но вы все равно будете все время находиться на одной странице SPA. Это справедливо для любой навигации в платформе, и вы получаете полный и простой контроль, если решите, что страница всегда обновляется с сервера при обратном переходе на нее, а не из кеша браузера. Если пометить капсулу страницы атрибутом reloadPage, равным «true», страница будет повторно отправлена на сервер со всеми теми же параметрами, с которыми она изначально была запрошена, и даже вызовет тот же обратный вызов, который был первоначально назначен ей, в исходной области закрытия.
function test1 ( ) {
var successfulCallback = function ( innerHTMLObject ) {
alert ( "this my callback" ) ;
}
var webapi = new Webapi ( ) ;
webapi . setSuccessCallbackReference ( successfulCallback ) ;
webapi . setUrl ( "test1.html" ) ;
webapi . submitAsync ( ) ;
} Может ли все быть проще?
Полный список атрибутов капсулы, доступных в режиме динамического веб-приложения
Капсульная архитектура WebRocketX позволяет разработчику декларативно контролировать большую часть поведения представления.
Ниже показаны все возможные атрибуты капсулы. Это даст вам представление о большей части функциональных возможностей фреймворка и о том, как он охватывает большинство случаев использования пользовательской навигации.
Атрибутам, не включенным в капсулу, будут присвоены значения по умолчанию. Обязательные атрибуты отмечены звездочкой*.
- id* — используется для отслеживания страницы в среде WebRocketX. Передается через параметр CapsuleId в примере шаблона. Использование шаблонов не требуется.
- class* — должно быть установлено значение «metaCapsule». Используется платформой для поиска капсулы div.
- CapsuleType* — можно установить следующие четыре значения, которые определяют, как и будет ли вводиться капсула.
- inline — контент будет вставлен в div, указанный атрибутом targetId.
- модальный — контент будет добавлен в плавающий модальный слой.
- данные — контент не будет отслеживаться для навигации по платформе. Разработчик может решить, указывать ли targetId или размещать контент самостоятельно, или даже использовать контент, не размещая его на странице. Содержимое будет возвращено разработчику в обратном вызове в качестве первого параметра в виде объекта DOM капсулы и включенного в нее содержимого. Это идеальный тип капсулы, который можно использовать для обновляемых небольших частей страницы, по которым не осуществляется навигация по целым страницам. Например, результаты поиска, тикеры и т. д.
- json — просто визуализируйте текст json на стороне сервера капсулы, и он будет доставлен в обратном вызове на стороне браузера, уже преобразованном в объект json. Отправку параметров json на сервер можно выполнить, установив значение параметра в строку json с помощью объекта AsyncParametersList.
- targetId (*обязательный, если тип капсулы является встроенным) — указывает место, куда будет вставлен входящий HTML-код, если тип капсулы является «встроенным».
- jsOnload — указывает метод JavaScript, который будет вызываться после завершения внедрения. Очень полезно для регистрации автозаполнителей, компонентов пользовательского интерфейса jquery и любых других операций типа загрузки страницы. Дескриптор капсулы, в которой была объявлена функция jsOnload, всегда отправляется в качестве одного параметра в вашу функцию js.
- jsReturn — указывает метод JavaScript, который будет вызываться, когда эта страница возвращается, но не перезагружается. Возврат на страницу можно запустить с помощью кнопки «Назад» или вызова dtSetCapsuleById. Этот механизм полезен, когда разработчик желает обновить часть представления или запустить любой другой код при отображении условно или безоговорочно. Поскольку приложение выполняется на одной странице, условия могут передаваться между страницами как глобальные переменные. Дескриптор капсулы, в которой была объявлена функция jsReturn, всегда отправляется в качестве одного параметра в вашу функцию js.
- reloadPage (по умолчанию: false) — если это правда, переход к этой странице в стеке браузера приведет к получению с сервера свежей версии этого контента. Исходный запрос будет отправлен повторно со всеми исходными параметрами и будет вызван исходный метод обратного вызова.
- SkipReloadPageOnPrevious (по умолчанию: false) — если это правда, переход с этой страницы на страницу в стеке браузера, отмеченную перезагрузкой, заблокирует перезагрузку целевой страницы. Это особенно полезно, поскольку позволяет разработчику контролировать, будут ли различные обратные потоки на страницу перезагрузки вызывать ее перезагрузку или нет. Например, часто нежелательно при переходе обратно на фоновую страницу из модального окна перезагружать эту фоновую страницу. Тем не менее, по-прежнему может быть желательно, чтобы та же самая фоновая страница перезагружалась при переходе обратно со страницы, которая ее заменила.
- saveOriginalRequest (по умолчанию: false) — если установлено значение true, исходный запрос будет сохранен, даже если это не перезагрузка.
- saveResponse (по умолчанию: false) — если установлено значение true, объект ответа сохраняется во внедренном капсульном div. Позже это можно использовать для восстановления внедренного содержимого в исходное состояние после изменений пользователем, вызвав restAsyncResponse(id). Наиболее распространенный случай, когда эта возможность желательна, — это когда на странице есть кнопка отмены.
- trackPage (по умолчанию: true) — по умолчанию установлено значение true, указывающее, что эта страница помещается в задний стек для дальнейшего использования. Этот параметр не актуален для капсульных типов данных и json, поскольку по этим типам изначально невозможно перемещаться. Разработчик может указать, что эта страница не должна помещаться в задний стек, установив для этого атрибута значение false. Установка для trackPage значения false — идеальное решение для страниц, на которые вы не хотите, чтобы пользователь возвращался и затем повторно отправлял их, например, страницу «создать». Когда пользователь возвращается на неотслеживаемую страницу, он пропускает ее и переходит на предшествующую ему отслеживаемую страницу.
- windowTitle — указывает заголовок, который будет установлен в верхней части браузера. Необходимо, потому что мы никогда не изменяем страницы и, следовательно, никогда не обновляем тег заголовка в заголовке html.
- errorPage — помечает эту страницу как типизированное исключение, что приведет к тому, что определенный разработчиком успешный обратный вызов будет пропущен и будет вызван определенный разработчиком обратный вызов при сбое.
Преимущества создания одностраничного приложения Django (SPA)
Хотя SPA обычно приравнивают к тяжелой платформе Javascript на стороне клиента в сочетании со службами JSON, все же вполне возможно получить преимущества SPA, продолжая рендерить серверную часть HTML, с помощью нашей легкой инфраструктуры Javascript SPA.
- Преимущества микрозапросов при обслуживании состояния пользовательского интерфейса . Обновление только части страницы означает, что не нужно каждый раз извлекать всю страницу. С сервера необходимо получить только фрагмент HTML или объект JSON. Это значительно упрощает работу разработчика пользовательского интерфейса, поскольку ему не нужно создавать шаблоны заголовка, меню и нижнего колонтитула на каждой странице или беспокоиться о состоянии других данных в частях страницы за пределами области обновления. Даже пользовательский ввод, который не был передан на сервер, безопасен, пока он находится за пределами обновляемой области. Большая часть проблем разработки пользовательского интерфейса исчезает с помощью микрозапросов.
- Преимущества микрозапросов в сервисах . Поскольку извлекаются только целевые части страницы, данные, необходимые в этих местах, становятся более конкретными. Это сокращает объем бизнес-логики, необходимой для служб, а также упрощает извлечение данных из внешних приложений, таких как базы данных и облачные службы.
- Сохранение большего состояния в браузере . Сочетание кэширования представлений и обновления только частей страницы приводит к тому, что в браузере сохраняется гораздо больше состояния. Следовательно, разработчику не нужно будет совершать столько обращений к серверу, чтобы получить это уже существующее состояние. Это большое преимущество даже в таких простых вещах, как отправка формы, потому что, когда сервер отклоняет отправленный пользовательский ввод, страница с формой просто сохраняется на клиентской стороне со всем ее пользовательским вводом. Мы никогда не теряли страницу. С другой стороны, отклоненная форма при полном обновлении страницы потеряет весь пользовательский ввод, поскольку браузер находится в процессе отображения следующей страницы, а страница формы исчезла. Таким образом, при полном обновлении страницы отклонение отправки формы входные данные придется отправить на сервер и отобразить повторно, повторно визуализируя всю форму и восстанавливая несохраняемый пользовательский ввод. Параметры формы будут восстановлены из запроса, но не из базы данных, поскольку отправка была недействительной, поэтому данные никогда не доходили до этого момента. Если вы не заботитесь о своих пользователях, вы можете показать им сообщение об ошибке и заставить их вводить все заново, что иногда происходит и очень недружелюбно. В случае одностраничного приложения Django, использующего микрозапросы, страница никогда не покидалась с самого начала, и мы можем отправить обратно сообщение об ошибке в виде плавающего модального диалога.
- Навигация по структурированному представлению . К ранее визуализированным представлениям можно перейти, используя их идентификаторы. Используя атрибуты капсулы, представления можно указать как кэшируемые или принудительно перезагружаемые (чтобы они не устаревали).
- Контроль взаимодействия с пользователем . Были ли у вас когда-нибудь проблемы, когда пользователь дважды нажимал кнопку? Такого рода проблем больше не возникнет, поскольку WebRocketX помещает прозрачный слой поверх пользовательского интерфейса во время обращения к серверу, который предотвращает взаимодействие с пользователем. Фреймворк также показывает красивый курсор в виде песочных часов, чтобы пользователь знал, что что-то происходит.
- Структурированная обработка ошибок . Ошибки на стороне сервера и таймауты сеансов могут стать настоящей проблемой, когда разработчик ожидает, что макет или данные будут получены из асинхронного обратного вызова. WebRocketX стандартизирует обработку ошибок и поведение тайм-аута сеанса, поэтому ничего непредсказуемого не может произойти. Все ответы предварительно проверяются перед отправкой обратного вызова обратному вызову разработчика для устранения любых проблем. Также предусмотрены перехватчики, позволяющие разработчику определять собственное поведение в случае сбоев обратного вызова.
Посетите наш веб-сайт для получения более подробной информации и документации.
Посетите WebRocketX
