Что значит веб морда

Содержание

Что такое веб-интерфейс: примеры
Что такое web-интерфейс
Web-интерфейс почты
Веб-интерфейс модема
Веб-интерфейс роутера
Все вебморды в одной. virtualhost и proxy_pass в nginx для дома.
Веб-интерфейсы: развитие или наоборот?
Текстовый режим
Оконные интерфейсы
Веб-приложения
Тенденции развития веб-интерфейсов
Рассмотрим подробнее визуальные контролы и решения
Заключение

Что такое веб-интерфейс: примеры

Большинство пользователей привыкли работать с компьютером путем запуска программы и выполнения в ней всех требуемых задач. В наше время программы обладают графическим интерфейсом, что, конечно же, облегчает работу с ним. Но и этот подход уже устаревает. Сейчас все больше появляется веб-интерфейсов. Именно этой теме посвящена данная статья.

Что такое web-интерфейс

Web-интерфейсом можно считать любой сайт, запускаемый через браузер. Например, заходя на свою почту в Интернете, а не используя почтовый клиент, пользователь сталкивается непосредственно с веб-интерфейсом. Он позволяет взаимодействовать со всеми функциями почты и не требует установки дополнительного программного обеспечения. Соответственно, для работы в web-интерфейсе необходимо стабильное подключение к сети, иначе веб-сайты не будут открываться.

Чтобы запустить условную программу через веб-интерфейс, необходимо выполнить простые действия:

Запустить браузер.
Открыть в нем нужный сайт.
Ввести регистрационные данные.

Последний пункт нужен для того, чтобы получить доступ ко всем услугам, предоставляющимся сайтом.

Web-интерфейс почты

Чтобы все более подробней разобрать, необходимо привести примеры использования такого интерфейса на практике. Сейчас рассмотрим интерфейс на примере Yandex.Почты.

Можно осуществить вход в почтовый ящик несколькими методами: через почтового клиента (программу, установленную на компьютере) или через веб-интерфейс (браузер). Рассмотрим второй метод.

В браузере введите сайт почты, в данном случае yandex.ru.
В верхней правой части нажмите кнопку «Войти».
В появившейся форме введите регистрационные данные.
Нажмите кнопку «Войти».

Читайте также: Кдо что это значит

После этого вы попадаете на новую страницу — web-интерфейс почты от Яндекс. В нем вы можете выполнять основные действия, переходя по соответствующим ссылкам. Например, для просмотра входящих писем, необходимо нажать по ссылке «Входящие».

Веб-интерфейс модема

Если с интерфейсом почты все пользователи более или менее знакомы, то меньше они знают интерфейс модема. В статье будет рассмотрен модем фирмы Yota, но способ запуска общий и для «Мегафона», «Билайна», «МТС» и пр.

Итак, чтобы попасть в веб-интерфейс модема, необходимо:

Открыть браузер.
Перейти на сайт модема.
Перейти по ссылке, ведущей в личный кабинет пользователя.
Войти в профиль.
Ввести регистрационные данные.

После этого вы попадаете в меню, откуда можно управлять функциями модема. К слову, чтобы получить регистрационные данные, вам необходимо их ввести при первом входе на сайт. Тогда автоматически откроется окно, где необходимо указать основные данные, которые в будущем будут использоваться для входа.

Веб-интерфейс роутера

Web-интерфейс также используется для управления роутером. Даже более того, с его помощью только и можно настраивать это сетевое устройство. Принцип запуска во многом отличается от тех, что были представлены ранее. Вот, что должен сделать пользователя для его открытия:

Открыть браузер.
Ввести в адресную строку домен роутера. Он может выражаться как в числовом значении, например, 192.168.1.1, так и в буквенном.
После этого появится окно, в котором необходимо ввести данные для входа. Часто они указаны на обратной стороне роутера.

После этого откроется довольно сложный интерфейс, через который можно выполнять настройку устройства.

Теперь вы знаете не только, что такое web-интерфейс, но и как его открыть.

Источник

Все вебморды в одной. virtualhost и proxy_pass в nginx для дома.

В этой статье я хотел бы поделиться опытом, как организовать доступ к Web-интерфейсам различных домашних качалок через один единственный проброшеный наружу порт. Делать будем под винду (на Win32 порту nginx), но точно также можно сделать под unix.

Где это может понадобиться? Очень простой пример, состоящий из двух условий:
— У меня дома стоит СТРИМ, который блокирует входящий 80 порт
— У меня на работе открыты наружу только порты 443, 80, 5190.
— Как итог: я могу достучаться домой только к 2 сервисам, один из которых у меня SSH, и один остается свободным. Задача сводится к тому, чтобы завернуть все WEB-морды в один сайт, ибо замучался я с SSH-туннелингом. Универсального интерфейса, конечно же, не получится, так что их надо логически разделить.

Ничего революционного я не скажу, лишь подскажу, как это сделать. Весь рассказ основывается на следующих вещах, но при желании вы с легкостью подключите любой другой веб-интерфейс:
— У вас есть динамический реальный IP
— DynDNS
— nginx для Win32
— µTorrent
— µTorrent WebUI
— eMule

DynDNS — принцип, регистрация и настройка

Принцип работы DynDNS очень прост: программа на компьютере, маршрутизаторе или модеме периодически обращается к сервису DynDNS. Сервис смотрит IP, с которого произошло обращение, и привязывает зарегистрированную вами бесплатную DNS-запись к IP, с которого произошло обращение. Таким образом, адрес вида myname.dyndns.org всегда указывает именно на ваш внешний IP-адрес, даже если у вас он динамический.

Вам нужно зарегистрировать аккаунт на сайте DynDNS, затем создать одну бесплатную DNS-запись в том домене второго уровня, который вам больше понравится. Мне, например, .homedns.org нравится. В настройках вам следует выставить галочку «Create wildcard alias». Тип записи должен быть «Host with IP address». Пример можете посмотреть на картинке:

Теперь нам нужно настроить программу-клиент. Сразу оговорюсь, что во многих роутерах Asus WL* уже встроен DynDNS-клиент, его настройки находятся в мень IP Config -> Miscellaneous. Так же во многих других домашних роутерах и модемах присутствует DynDNS-клиент. Если же его нет, то его нужно будет поставить на наш сервер. Скачать можно на самом сайте DynDNS в соответствующем разделе.

Включаем, вводим свой логин, пароль, и уже зарегистрированное на сайте DynDNS.org DNS-имя, которое мы хотим задействовать, и вуаля, теперь вы можете обращаться к своему домашнему роутеру по DNS-имени, например, vpedalkin.dyndns.org.

uTorrent, eMule, .

Настроить WEB-интерфейсы всех программ, которые вам нужны, предлагаю самостоятельно, благо, инструкций по этой теме очень много.

WebUI uTorrent нам следует настраивать на альтернативном порту и настраивать фильтрацию по IP. Так как сервер nginx мы будем ставить на той же машине, на которой стоит uTorrent, то делаем фильтрацию по 127.0.0.1 (т.е. только с этой машины). Альтернативный порт мы используем для того, чтобы у нас Web-морда не торчала наружу в двух экземплярах — через nginx и через проброшенный до uTorrent порт.
Подсказка для тех, кто не настраивал uTorrent WebUI никогда: Нужно положить скачанный с сайта uTorrent файл webui.zip, не распаковывая, в папку профиля. Чтобы ее открыть, нажмите Win + R и введите %USERPROFILE% (с процентиками) и нажмите ОК.

Вебморду eMule настраивать легче легкого: прописываем порт, пароль и все.

Я использовал порт 8081 для uTorrent и 8082 для eMule.

Переходим к настройке nginx

К моему большому сожалению, nginx под Win32 официально нет, но есть его сторонняя сборка на cygwin. Из основных недостатков можно отметить то, что nginx win32 ставится только в C:\nginx и никуда его оттуда не денешь.

Итак, устанавливаем nginx, открываем C:\nginx\conf\nginx.conf. Я Предпочитаю использовать редактор AkelPad — он очень похож на блокнот, но хорошо дружит с кодировками и мелкими рюшечками.

В моем случае HTTP-сервер у меня висит на порту 5190, ибо 443 занимать было жалко, да и неудобно это было мне — настраивать секурный сервер, так как uRemote, которой я пользуюсь, не поддерживает HTTPS-соединений.
Полный пример моего конфига здесь.
В общем случае мы добавляем директивы Server, например так:
server <
listen 5190;
server_name emule.vpedalkin.xxxxdns.org;
access_log logs/emule.log main;
location / <
#Аккуратно тут поправьте URL при копировании
proxy_pass h ttp://127.0.0.1:8082/;
proxy_buffer_size 8k;
proxy_buffering off;
proxy_connect_timeout 3;
proxy_ignore_client_abort off;
>
>

Обращаю ваше мнимание: для разделения мы используем Virtual Hosts. Таким образом сервер, в зависимости от того, как к нему обращаются (как к utorrent.vpedalkin.dyndns.org или emule.vpedalkin.dyndns.org), выполняет транспорт к определенному серверу (до uTorrent или eMule соответственно).
Не забываем поправить в конфиге все listen на тот порт, который вы собираетесь открыть наружу для веб-сервера. Также замените все vpedalkin.xxxdns.org на свои собственные реквизиты, зарегистрированные в DynDNS. Обращаю внимание что emule.vpedslkin.dyndns.org не надо регистрировать дополнительно — благодаря той галочке, которую мы поставили в свойствах записи на сайте DynDNS.org в самом начале, все это само будет перебрасываться туда же, куда и сам vpedalkin.dyndns.org

Проброс

Результат

Как результат, я получил Web-интерфейс к eMule по адресу , У меня спокойно настроен и работает uRemote по адерсу , а также веб-морда uTorrent по адресу . Можно было бы убрать эту приставку , но во многих программах типа uRemote эта строка зашита, и избавившись от нее мы не сможем подружить программу и вебморду.
Дополнительно у нас есть сайт , на котором у меня располагаетсяя набор ссылок на все мои веб-морды (у меня их чуточку больше чем описано). Файлы этого сайта лежат в папке c:\nginx\html.

Был рад, если кому-то эта информация покажется интересной.

Источник

Веб-интерфейсы: развитие или наоборот?

Текстовый режим

На недостатках текстовых интерфейсов мы не будем останавливаться, они очевидны. Но в текстовом режиме была и неоспоримые преимущества:

Полный контроль над экраном. Весь экран без остатка был покрыт прикладным интерфейсом программы, не оставляя места для плюшек и излишеств, не было десятков запущенных программ, выскакивающих окошек коммуникаторов, браузера с открытыми соцсетями.

Высокое использование клавиатуры. Все знают, что в специализированных пакетах всегда нельзя было обойтись без знания комбинаций клавиш. Но с появлением мыши пользователи отучились от горячих клавиш и даже курсоров, а многие программисты, вслед за ними, отучились от реализации полноценного управления приложением с помощью клавиатуры.

Однозначность действий. Типично, что в каждый момент для текстового режима имеется очень ограниченное количество действий, что облегчает работу с программами, их разработку и тестирование. Различный функционал практически не пересекается и гораздо меньше проблем с тем, что что-то ломается при доработках.

Оконные интерфейсы

Графический пользовательский интерфейс, применение ООП и оконных систем, основаны на передаче сообщений между визуальными контролами, использование мыши и тачскрина, дали нам много, но забрали еще больше.
Положительных моменты в оконных приложениях:

Контекст интерфейса в пользовательском приложении существуют достаточно долго, чтобы развернуть объектную модель, машину состояний, служебные структуры данных для ускорения процессов (кеш, индексы или ассоциативные массивы, деревья и т.д.). Это же справедливо и на счет сервера, если приложение клиент-серверное.
Есть возможность выводить богатую графику с аппаратной акселерацией и управлять графическими объектами непосредственно передвигая их по экрану мышью. Это незаменимо для программ работающих с графикой и игр, но для прикладных приложений баз данных — это излишество.
На экране можно поместить гораздо больше информации, сгруппировать и подсвечивать ее визуальными элементами (с помощью цвета, шрифта, пиктограмм и т.д.). Доступны различные динамические эффекты, как то: всплывающие подсказки, контекстные меню, графические маркеры для полей при валидации.
Таблицы стали гораздо удобнее: изменение ширины колонок, множественное выделение, контролы в ячейках, прокрутка, сортировка кликом по заголовку и даже возможность вывести дерево в таблице. Кое что из этого было доступно и в текстовом режиме, но в GUI есть для всего готовые решения, реализованные на уровне ОС или инструмента разработки.

Теперь критика:

Правая рука на мышке (а ввод как, левой рукой что-ли?). Поэтому правая рука постоянно двигается между мышью и клавиатурой. Например: вместо нажатия на F4 или комбинации клавиш мы берем мышь, двигаем ее через весь экран к тулбару и там наживает экранную кнопку небольшого размера.
Разработка и тестирование усложнилось, появилось много асинхронных событий, таймерных, серверных, сигналов от других окон и приложений. Среда (окружение) информационной системы стало менее стабильным и предсказуемым.
Программный код стал часто «завязан» на интерфейсах, в ООП произошло смешение в системной функциональности с логикой предметной области и с логикой визуализации, т.к. возможности увеличились, свободы в средствах реализации стало гораздо больше, а формирование подходов и архитектур запоздало.

Конечно же, опытные разработчики начали делать гораздо лучшие интерфейсы, но большая часть как разработчиков, так и пользователей — расслабились и погрязла в ереси.
Вывод: Чрезмерная свобода губительна для масс.

Веб-приложения

И наступило всем счастье, больше не нужно инсталлировать клиенты на компьютеры к пользователям, не нужно париться по поводу версий DLL, версий .NET и множества настроек на их машинах и заботиться о конфликтах ПО на пользовательских компьютерах. Все происходит в браузере и даже стандарты уже к текущему моменту вполне сносно поддерживаются всеми браузерами. Обновлять софт не нужно. Аспект безопасности данных: все хранится на сервере и централизовано бекапится и защищается. По поводу протоколов не паримся имеем HTTPS и JSON, все и удобно и защищено. Нелегальный версий прикладного ПО скоро вообще не будет, т.к. оно не ставится на компьютеры, а используется в модели SaaS по сети.

Но все ли так хорошо?
При отсутствии сети не можем работать, ну это еще как-то терпимо, сеть должна быть всегда, иначе нет групповой работы и коммуникации. Если что-то зависло во время ввода или сеть пропала — теряются введенные данные, отправить по сети нельзя, а локально сохранить негде (локальный сторидж и Web SQL пока не везде доступны). На всем печать идеологии REST, полное отсутствие состояния. Отсутствие средств Разные браузеры, а них особенности, требуется дополнительное тестирование и отладка. Верстку иногда делаем отдельно для IE (реже возникают версии для других браузеров), но это при очень хитрой разметке.

Что унаследовано от оконных интерфейсов?

Засилье мыши усугубилось.
Отвлекающие факторы добавились в большом количестве.
Принципы ООП унаследованы, но их же нужно переосмыслить для веба.

Переосмыслили ООП и паттерны лишь единицы, другие взяли бездумно. А специфика веба в том, что серверные приложения живут доли секунды, при этом они стейтлесс и пользовательский интерфейс при рефреше страниц не сохраняет ни свое состояние (значения в формах, переменные, объекты). В общем, REST — это не наш путь, для пользовательских интерфейсов и приложений баз данных состояние нужно как воздух, и решение многими уже найдено, это механизм сессий и куки, «всеми так любимый» viewstate и устаревший способ передачи состояния в урлах, грядущие стандарты Local Storage и Web SQL от HTML5, key-value СУБД на стороне сервера.

Тенденции развития веб-интерфейсов

С учетом всех проблем и новых возможностей, сформировался мейнстрим, активно поддерживаемой всей передовой частью сети, а именно:

Минимализм и простота — и сайты и приложения становятся сложнее внутри и проще снаружи, этому нас учит все передовые игроки и больше всего — Гугл, мы стараемся. Пользователь должен произвести минимум действий и выбора для получения желаемого результата.
Интерактивность и асинхронность — интерфейсы становятся динамическими, пропадает перезагрузка страниц и смена экранов, подгрузка происходит постепенно, фрагментами. Приложение постепенно модифицирует экран, откликаясь на действия пользователя.
Контекстность — вывод информации и контролы для вызова операций появляются там, где это логически ожидается и показываются только пока это необходимо. Мы экономим экран и внимание пользователя.
Синхронизация и комет — все чаще появляются приложения, в которых сервер генерирует события по своей инициативе, это позволяет синхронизировать экран пользователя с текущим состоянием данных в БД или в памяти сервера.
Полноэкранный лэйаут — не во всем вебе, а именно в веб-приложениях, есть тенденция к максимальному заполнению экрана с перераспределением размеров и границ между элементами интерфейса в зависимости от разрешения.
Упрощенный мобильны интерфейс — с распространением мобильных устройств, снабженных нормальными браузерами, появилась необходимость отдельно разрабатывать интерфейсы для малых разрешений и с поддержкой тачскрина.
Поддержка стандартов — входит в моду решать задачи с применением новых возможностей и спецификаций но с фэлбэком к старым технологиям, например звук и видео уже хочется проигрывать через html5, но флэш нас страхует, или при отсутствии Local Storage мы храним состояние на сервере, просто будет больше запросов, визуализация так же упрощается при показе в старом браузере, но приложение продолжает работать, а выглядит проще.

Рассмотрим подробнее визуальные контролы и решения

Зона прокрутки — для сайтов типична прокрутка полноэкранная, когда весь контент с элементами управления прокручивается разом одним трекбаром справа (или слева для right-to-left). Однако, для веб-приложений это не удобно и гораздо более адекватным решением будет принцип «прикрепления панелей» (как это принято в оконных приложениях), например, инструменты находятся на панели, которая прикреплена к верхней границе окна браузера и растянута на всю ширину, а слева может размещаться панель с динамически подгружаемым деревом, приклеенная к левому краю окна, снизу — строка состояния, справа — панель с контекстными задачами, всю же центральную часть экрана занимает объект работы: документ, карта, таблица, изображение и т.д. Каждая зона имеет свою прокрутку. Конечно идеально, чтобы прокрутку имела только зона в центральной части, а все остальные панели были без прокрутки или прокрутка бы осуществлялась не в трекбаром и только по одной оси.

Сплитер. Для оконных приложений пользуется популярностью динамический разделитель между панелями, который можно перетягивать мышью. Для веб-интерфейсов его тоже реализовали, но пользуются им не часто, а уже в мобильных приложениях сплитер не применим вовсе. Есть несколько решений: «дискретный сплитер», имеющий несколько состояний и переключающийся между ними при нажатии на управляющий элемент. «Умный сплитер» — подстраивает размеры панели под разрешение и конетнт, а перетягивать мышью его нужно крайне редко. «Уплывающий сплитер» — при долгой неактивности скрывает панель, а при подведении мыши — возвращает, но с этим есть проблемы на тачскинах, курсора то мыши там нет.

Гриды — таблицы и более сложные композитные гриды. С ними есть ряд проблем:

Очень плохо смотрится, если таблица имеет отдельный от всей страницы скроллинг, то есть, получается, что у нас скролинг в скролинге. Это актуально и для textarea.
Дублирование кнопок действия для каждой строки грида — это общая проблема всех веб-интерфейсов старого поколения — в глазах рябит.
Уезжают кнопки с действиями: поясню как — как в GMail, то есть, страница имеет общую прокрутку, которая прокручивает и грид и все разом с тулбаром вместе. Получается, что мы прокрутили грид на середину и хотим что-то сделать со строками в середине, а для доступа к тулбару нужно крутить экран вниз или вверх (как это и в редакторе статей Хабра).
И пейджинг (пусть меня осудят, но я скажу все, что об этом думаю) — далее третьей страницы мало кто заходит; длинные списки пользователи не браузят — это бессмысленно, если где-то они организовались, то только для того, чтобы отфильтровать их более подробно, а листать — лишнее; особо весело, когда вся страница перегружается при перелистывнии пейджинга; с сортировкой не всегда удобно; не все СУБД оптимизированы для отбора данных для пейджинга, при больших наборах данных это в любом случае повышает нагрузку на сервер. Что же вместо? Виртуальные гриды — см. ниже.

Что же хочется иметь в гридах:

Виртуализация грида — скролинг сразу большой (по количеству записей), а подгружаются только видимые, ни или еще небольшой запас (упреждающее чтение). Есть варианты, старые записи можно копить, пока весь набор данных не перекачаем в клиента или выделяется определенный буфер в 100-200 записей с вытесняющей подгрузкой строк, при прокрутке старые блоки удаляются.
Формирование на стороне сервера или на стороне браузера — решить эту проблему навсегда и кардинально нельзя. Спорить можно долго, кто-то привык пересылать данные JSON через AJAX и выводить в подготовленный грид на клиенте, а кто-то пересылает записи через AJAX сразу в HTML. Есть еще вариант предзаполненных гридов (это оправдано, если записей не много). Как правильно — определяется спецификой задачи и хороший грид должен реализовывать все три варианта.
Работа с клавиатуры — уже много об этом говорили, но уж очень мне не хватает во всех современных веб-приложения полноценной работы с клавиатуры, это альтернативный способ, но он должен быть, и навигация курсорами и горячие комбинации и функциональные клавиши.
Инлайн редактирование — то есть правка значений по месту, без вызова форм с AJAX/JSON отправкой на сервер отредактированного значения или накопления буфера и отправкой при нажатии «сохранить» сразу целой пачки.

Дерево — для полного счастью дерево должно удовлетворять почти тому же перечню, что и грид: подгружаться динамически, управляться мышью и с клавиатуры, редактироваться по месту и т.д.

Главное меню — забыть как страшный сон! Этот атавизм от оконных приложений в вебе не имеет права на жизнь.

Тулбар — вместо свалки кнопочек и комбо-боксов тулбары постепенно становятся адаптивными, контекстными, мы видим только те функции, которые можно применить в текущем состоянии приложения или к элементу, находящемуся в фокусе.

Комбобокс — cтандартный html-ный комбо-бокс ужасен и по дизайну, который нельзя полностью переопределить и по функционалу, который ограничен банаьным выпадающим списком строк. Нам нужен комбо-бокс с многими режимами, с инкрементным поиском, позволяющим выбирать из больших справочников, с возможногстью выбирать несколько значений, с группами, с картинками (и вообще с элементами с богатым html+css оформлением).

Заключение

Всю дорогу наша команда, для себя и не только, формирует набор контролов для веб-приложений, часть пишем, часть берем и причесываем, часть покупаем (это только если нет времени сделать), но постоянно расширяем набор используемых и проверенных. Эта статья лишь обзорная, если кому-то интересно, то мы можем в свободное время публиковать кратенько о своих наработках, например, вот недавно взялись за доработку jQuery UI нескольких кривых контролов и недостающих. Так же, будем благодарны за Ваше мнение по поводу изложенного подхода, ссылки на хорошие контролы, дэмки, скриншоты и приложения, которые, по Вашему мнению заслуживают внимания.

Добавлено: картинку для медитаций убрал, она Вам не нравится, я чувствую.
А иллюстрации попробую все же собрать в ближайшие дни.

Рис 1: Как некрасиво делать уезжающие тулбары на примере GMail