Єдиний маніфест інтерфейс сторінку

Походження веб-технології

Коли Tim Berners Lee ^[1]
винайшов веб шукав систему для публікації наукових документів віддаленого доступу, візуально привабливий, легкий код і простий у використанні для нетехнічних обличчя.

В науковий документ, зовнішній цитує інші документи необхідні для того, щоб читач може додатково розвивати темі.

З цих причин World Wide Web був задуманий як сторінка (документ) на основі системи з гіперпосиланнями.

Спочатку веб-був мир статичних сторінок і заслання, але незабаром генерацію динамічних сторінок і в цілому використання Інтернету в якості підтримки для розробки веб-додатків все складніше.

Поява веб-додатків

Протягом багатьох років спостерігається зусилля, щоб адаптувати веб-парадигми сторінок та посилання на розробку додатків. У веб-додатку думку Бернерса "статичних документів і простий посилання не існує.

Різні підходи розробки додатків були відбувається:

• Модель 1 : прямий переклад оригінальної моделі сторінки та посилання, де сторінки генеруються динамічно.
• Модель 2 про MVC : тепер посилання прямо не вказує на конкретну цільову сторінку, в даному випадку контролер вирішити, що наступна сторінка в залежності від операції відбулися в сторінку переходу.
• MVC заснована на компонентах (модель 3?) : це складна версія Model 2 моделювання як настільної роботи додатків. Вона заснована на компонентах і подій, так що будь-які дії користувача увазі повне відновлення і перезавантаження сторінки частково змінити деякі частини відповідно до дією виконані. Сторінка і сторінка переходу в даний час керує компоненти, які в даний час, які зміни відбуваються в залежності від події, імітуючи, як компоненти працюють на робочий стіл Програмування GUI.

В останні роки метод AJAX був введений цей метод за допомогою JavaScript дозволяє часткових змін на сторінках отримання нових даних від сервера без перезавантаження. Незважаючи на часткову зміну техніки сторінка задовго до введення XMLHttpRequest в Internet Explorer (база AJAX програмування), було підвищення її масове використання.

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

Незважаючи на масове використання AJAX, ми можемо сказати, що Web слід моделі розвитку, ми могли б назвати як "модель 2 (MVC) збагачений AJAX". При використанні AJAX, "Модель 3" не має сенсу, тому що AJAX в значній мірі знижує необхідність сторінці управління на основі компонентів. Бо AJAX зазвичай використовується разом з компонентами (не обов'язково присутній в моделі 2), ми можемо класифікувати сучасний стан мистецтва веб-розробки, як модель 3,5 , де навігація по сторінках частково уникнути в разі незначних переходів стану виконується AJAX і JavaScript.

Які недоліки сторінки навігації та розвитку?

Кожен веб-розробник знає, наскільки проблематична навігації по сторінках у веб-додатку, крім того, щоб витрачати трафік і час процесу відновлення цілих сторінок більше проблем, зробити веб-розробки болючим, як небажаного кешування, назад / вперед кнопками, десинхронізації форми викликано "форми автозаповнення" Особливістю деяких браузерах і так далі. Це не рідкість побачити веб-додатків, які приховують меню і кнопки браузера або з використанням фреймів або фреймів (наприклад, банки), щоб уникнути проблеми кнопок Назад / Вперед.

Сторінка на основі розвитку змушує стиль кодування дивно, що повторюються (включає в себе багато) і неефективною (як пропускної здатності та обчислювальної потужності) не перебуває в робочому столі розвитку.

Що є що перешкоджає інтенсивному використанню AJAX?

В області веб-розробки ми звикли розрізняти два види веб-рішень: веб-додатків і веб-сайтів.

У першому випадку AJAX стає все більше і більше використовується, тому що такого додатка не поділяють деякі реквізити, введені для веб-сайтів. У веб-сайтів інтенсивному використанні AJAX є проблемою.

У публічних веб-сайтах користувачі звикли до сторінки концепції, прив'язані до сторінок деяких реквізитів і послуг, необхідних у будь-який веб-сайт, як:

1. Закладки : кожен веб-сторінка має свій URL, цей URL може бути збережено як закладки. Бо AJAX може частково змінити сторінку URL те ж саме, кінцевий користувач не зможе зберегти як закладки конкретного виду (держави) частині сторінки.
2. Search Engine Optimization (SEO) : Будь веб-сайт хоче бути повністю індексуються пошуковими системами, як Google Search Appliance. Поточний сканери см. на веб-як Web 1.0, тобто, JavaScript код повністю ігноруються, таким чином, будь часткову зміну здійснюється за допомогою AJAX завантажуються з сервера не виконується, то не індексуються сканери обхід веб-сайті.
3. Послуги на основі відвідувань сторінок : Наприклад, рекламні послуги, як Google AdSense і відвідуванні сторінки моніторингу, таких як Google Analytics, в обох випадках кількість завантаження сторінки дуже важливо. Тому будь часткову зміну зроблено AJAX не вважається новим візитом.
4. Іноді необхідно поп-вікна цуценя

Оскільки ці реквізити інтенсивної AJAX не рекомендується на веб-сайтах.

Однак різниця між "сайт" і "веб-додаток" стає все менше, тому що практично будь-який веб-сайт є свого роду "веб-додаток" ...

Чи повинні ми відмовитися від AJAX-додатків?

НІ .

Є технічні рішення для всіх вище перерахованих реквізитів.

Розробка інтернет-сайтів на основі однієї веб-сторінці (SPI), чи можливо це?

ТАК!

Це час, щоб почати цей перехід, розробників і кінцевих користувачів всіх нас отримають. У нас є технології і сучасні браузери мають необхідну кваліфікацію для досягнення цієї мети.

Щоб домогтися успіху в цій "новій" шлях веб-розробки ми повинні виконати всі попередні реквізити будь-якого веб-сайту.

Прощай сторінок, ласкаво просимо держав

У веб-додатків без JavaScript, стан послідовність еквівалентна сторінок в додатку SPI будь часткову зміну передбачає нове "держава" "сторінці". Серед держав, можна виділити дві категорії держав:

• Основні держави
• Вторинний держав

Різницеві між двома типами стан дуже важливо, тому що фундаментальні держави стане веб-сторінки у разі потреби. Фундаментальні та вторинної диференціації залежить сайту.

Щоб краще зрозуміти, як типи держав можна вивчати реальний приклад: Вхід перевірки.

У класичному сторінку додатків типовий логін побудована з використанням двох сторінок, одна для користувача і пароль і один показ користувачеві варіанти, якщо логін перевірки було правильно, сторінка входу буде перезавантажена показані деякі повідомлення про помилки, поряд з формою входу при вході встановлена ​​неправильно .

В SPI Інтернет, початковий логін і сторінки параметрів користувача може бути основним держави, і повідомлення про помилки поряд логін може бути вторинним держав.

Інший приклад, веб-сайт на основі сторінок повинні бути перетворені в SPI, в цьому випадку фундаментальна держави буде сторінок і вторинні держави будуть сторінка держав з незначними змінами, не досить важливим для закладки або бути пройдений роботів.

Єдиний інтерфейс сторінки і закладки

Різні сторінки мають різні URL-адреси, за маршрутом SPI як ми можемо змінити стан і в той же час URL без перезавантаження, щоб це новий стан може бути закладка кінцевих користувачів?.

Існує трюк, за допомогою "посилання" частина URL ("хеш-фрагмент", притон або hashbang), це остання частина, якщо вона присутня, після символу #. Це посилання використовується для прокрутки сторінки до конкретного адресою, вказаною деякі <a name="ref"> </ A> марки. Це посилання, якщо частина змінилася не перезавантажує сторінку, отже, якщо URL посилання змінено за допомогою window.location поряд стану сторінки (в даному випадку це новий стан "фундаментальні") з JavaScript і AJAX, то ніякої перезавантаження не проводиться. Оскільки URL-адресу і основний стан змінилося, кінцеві користувачі можуть зберегти URL, в деякому роді, що містить нову інформацію держави, як закладки.

Коли користувач хоче повернутися знову до закладками сторінок, цільове стан зазначено в довідковій частині URL-адресу, сервер буде запропоновано, на жаль, посилання частина не відправляється на сервер, тому що частина посилань не робить нічого спільного з віддалено з використанням HTTP, тому нам потрібно буде після процесу завантаження.

Сервер видасть початкова сторінка, в якій мета держави не зазначені, однак window.location об'єкт містить оригінальний URL, включаючи посилання частину. При завантаженні на цільову сторінку можна виявити за допомогою JavaScript Чи window.location містить посилання частини і чи є це посилання має необхідну інформацію державних цільових, якщо це правда, ми можемо переписати URL додаванням якийсь нормальний параметр, щоб вказати цільове стан для завантаження. Оскільки URL фактично змінилася новий запит серверу виконується, на цей раз держава, щоб завантажити в параметри і сервер повертає нову сторінку в потрібний стан.

Інший варіант, краще, ніж hashbangs, виникає з появою HTML 5, HTML 5 Історія API ^[2] .

Єдиний інтерфейс сторінки і Search Engine Optimization (SEO)

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

Наступний приклад показує зв'язок з цією ідеєю:

<a href="URL page" onclick="return false"> ... </ a>

Це посилання буде нічого не робити в браузері з JavaScript включена, оскільки навігація відключена " повернення помилкових "в OnClick атрибут, але коли бот індекси посилання ігнорує OnClick атрибут, тому що JavaScript код не буде виконаний і буде обробляти вказаний URL в якості наступного Сторінка для обробки.

В області додатків SPI, URL-адреси використовуються для сторінки / штат навігація повинна містити мета держави, і той же тип адрес, використовуваних в SPI закладок, який використовує частину посилання, щоб вказати мету держави, або ціль безпосередньо вигляді нормальний параметр, пізніше переважно, оскільки дозволяє уникнути запиту до сервера, звичайно, "красиві посилання" також може бути використаний.

Теперішній час Google вже повзає "AJAX URL", тобто, URL, що містять цільовий стан в довідковій частині після #! , як зазначено в
Створення додатків AJAX сканувати ^[3] , в цьому випадку веб-сайт / додаток повинен повернути очікуваний сторінка запитується з _escaped_fragment_ параметрів.

У той же час в рамках веб-SPI можете додати певний код в обробник OnClick до повернення помилковими або можуть зв'язуватися слухач події за посиланням використовується для навігації стан / сторінок, зареєстрованих addEventListener або attachEvent
в залежності від браузера. Ця подія слухач буде виконувати деякі дії, щоб командувати сервер, як правило, з використанням AJAX, для зміни стану сторінки. При натисканні посилання це зміна стану не є новою сторінкою, оскільки атрибут OnClick = "... повернутися помилковим"
уникає поведінка за умовчанням.

Методикою, описаною раніше це самий простий і безпосередній, використовуючи видимі посилання сумісні з ботами і SPI. Ви можете або розділити дві функції, наприклад, за допомогою прихованих зв'язків для кінцевих користувачів, але не для роботів поряд з іншими інтерактивними елементами змінити SPI держави за допомогою JavaScript невидимими для роботів.

Найбільш важливою особливістю SPI здатні рамки генерації сторінки як HTML із необхідним держави на час завантаження і в той же час ті ж зміни стану повинні бути виконані з JavaScript і часткового оновлення сторінки. Ці передумови є основою для SPI і забезпечити сторінка моделювання.

SPI і кнопок Назад / Вперед

Кнопок Назад / Вперед є джерелом проблем на звичайні сторінки на основі веб-сайти і їх слід уникати як можна швидше. Незважаючи на користувачів використовується, щоб уникнути кнопки Назад і Вперед при відправленні форми з одними даними (бо вона несе в собі ризик придбання двічі в одній площині галочкою або книги), використання кнопок Назад / Вперед дуже широке поширення.

Мабуть, парадигма SPI порушує традиційний уклад навігації веб-сайту, так як в теорії кнопок Назад / Вперед не має сенсу в SPI (без сторінок) і веб-браузери не забезпечують хороший контроль над цими кнопками.

Це не зовсім вірно, Назад / Вперед поведінки можуть бути змодельовані, а навігація по сторінках назад / вперед (і історію навігації в цілому) може бути використана для зміни поточного стану до попереднього / вперед держави. В цьому випадку код JavaScript може виявити, коли посилання частина URL змін і вимагає застосування для зміни стану відповідно. Оскільки браузер не змінити сторінку програми тепер повністю відповідальним Назад / Вперед поведінка уникнути типових проблем несподіваних Назад / Вперед використання кінцевими користувачами при відправленні форми, в даний час SPI немає такій формі і не неконтрольованих сторінки навігації на веб-додатків / веб-сайту.

SPI і послуг на основі відвідувань сторінок

Оголошення послуги і лічильників відвідування сторінок на основі того, скільки сторінок було додано. В обох випадках ви можете використовувати приховані елементи <iframe> містить порожній веб-сторінки з необхідними скриптами для виконання даного виду послуг.

У разі реклами послуг, таких як Google AdSense, динамічні вставки <iframe> увазі завантаження нових оголошеннях тому кожна зміна стану може означати новий перезавантаження <iframe> з оголошеннями. Google AdSense, здається, визначити, коли сценарій AdSense виконується в <iframe> і враховує вміст контейнера сторінок. Це може бути бажано, щоб додати якийсь параметр, який визначає основні стани, завантаження <iframe>.

У випадку відвідування лічильника, ми можемо використовувати їх для контролю користувачів відвідування основних станів нашому веб-сайті SPI. В цьому випадку ми повинні прихований <iframe> містить порожній веб-сторінки з контролем сценаріїв. За допомогою простого параметра можна вказати основний стан відвідують. Наші <iframe> повинна бути глобальною (завжди ж на сторінці). При першому завантаженні сторінки, основний державний завантажується (вказане в URL) повинні бути зазначені в <iframe> з параметром. Після завантаження сторінки, кожне фундаментальна зміна стану може бути доведено до <iframe> зміни URL за допомогою JavaScript відповідно до нового основний стан, цей URL зміна призведе до перезавантаження <iframe> (із зазначенням нового відвідування).

SPI і спливаючі вікна

При новому вікні Сторінка створена модель SPI не працює. Фундаменталізм погано, немає ніяких проблем, якщо стан цього нового вікна не має нічого спільного зі станом батьківського вікна, в даному випадку спливаючих вікон в порядку.

Проблема виникає, коли будь-яка дія, що виконується на спливаючі вікна (модального або не модальний) має певний вплив на батьківське вікно, координація між сторінками складно. Наприклад, немає веб-стандарт для створення модальних вікон, так як сторінка поняття традиційно завжди була самостійним елементом, і тому його життєвого циклу важко координувати з іншої сторінки.

На щастя, ця проблема має рішення протягом деякого часу в SPI, можна імітувати модальний або не модальних вікон усередині одного веб-сторінки, ніяких нових реальних вікно створюється сторінка. У разі не-модальних вікон, будь HTML-елемент з абсолютним позиціонуванням може бути "не-модального вікна", і ви можете створити модальних вікон за допомогою абсолютного позиціонування, управління Z-індексу та прозорість елементів "зверху" на сторінці ("модальні шари"). Ці рішення дійсні в контексті SPI.

Приклавши трохи зусиль, навіть держава, яка показує модальне вікно може бути основний стан і, отже, судноплавний пошукових роботів.

Культурний зсув, для веб-розробників

Більшість веб-розробників (і веб-платформами) вважають, що Інтернет як на основі сторінки, сторінки скорочення на одну сторінку передбачає радикальну зміну свідомості і як ми робимо веб-сайти і додатки. Ця зміна не настільки радикальні, завдяки AJAX, AJAX є сьогодні основним і скоротила кількість сторінок типових веб-сайтів, а в результаті це призвело нас біля цієї "нової" моделі SPI розвитку.

У новому SPI веб-тега <form> зникає, і в цілому необхідність сесій використовуються в якості системи управління базами даних після послідовності сторінок. Тепер герой сторінці клієнт з деякою симетрії в сервер (сторінка на сервері). Насправді, тому що ми позбавилися від сторінки координації з сесіями ми звільняємося від джерела проблем, як погана практика, деякі користувачі, відкривати кілька вікон з тієї ж самої сторінці, ця практика зазвичай порушує сесії та програми в цілому.

SPI програмування на основі подій так само, як в настільному, так як в настільних більшість додатків працює в тому ж віконну раму, а коли дитина вікна існують вони повністю управляються в головному вікні і по-справжньому модальним.

Після парадигма еволюції веб-розробки, цей "новий" підхід можна назвати модель 4 .

Культурний зсув для кінцевих користувачів?

Не дуже багато, з можливість установки закладок і Назад / Вперед користувачів моделювання кінця не буде відрізнятися сайт веб-SPI і тій же сторінці, на основі, крім того, сайт SPI буде більш гнучкою та типові блимати і прокрутка сторінки навігації буде видалено.

Технічні життєздатність сьогодні

Цей маніфест є не заява про наміри, а вираз бажання просувати "новий" спосіб створення веб-сайтів, які вже реально. Наведені вище технічні дослідження завжди мала Java веб-фреймворк ItsNat ^[4]
якості технологічної бази SPI розвиток веб-сайту. Незважаючи на ItsNat було задумано з самого першого дня до такого роду програм / сайтів, попередні методи можуть бути застосовані інші структури мережі або ці структури могли б розвиватися, щоб забезпечити умови для такого роду SPI веб-сайтів з вимогами сторінки моделювання.

Деякі вимоги з цих сайтів SPI мережі, щоб мати можливість заміни традиційних сторінок на основі веб-сайти, такі як сторінки моделювання фундаментальних станів на час завантаження, просто можна з сервера веб-орієнтованих структур, бо HTML рендеринга повинно бути зроблено в сервері на час завантаження. HTML-рендеринг на час завантаження і те ж динамічно завантажуваних і вставляється з JavaScript є ключовими характеристиками веб-фреймворк готові будувати сайти SPI Інтернеті. Рамках клієнт орієнтованих може відігравати важливу роль для реалізації так званих вторинних станів.

Реальний приклад

Веб- Innowhere.com ^[5]
проводиться з ItsNat в сервер і є хорошим прикладом веб-сайті SPI, оскільки він підсумовує всі вимоги веб-сайті SPI, описаних в даному документі, щоб бути задовільною заміною традиційної сайту. Справді, нова версія SPI замінює, не значущий естетичний функціональних змін, попередня версія заснована на сторінках.

Характеристика

• Єдиний інтерфейс сторінку: кнопки Назад і Вперед моделюється зміна до попереднього або вперед відвідав держави.
• Основні стани можуть бути збережені у вигляді закладок.
• SEO сумісний: фундаментальні держав досяжні з JavaScript відключені включаючи модальне вікно ^[6] .
• Google SEO сумісний "AJAX URL-адреси", використовуючи #! формат, сторінка також пропонується наступне угоду Google в _escaped_fragment_ параметрів. Наприклад,
  цей стан буде скануватися Google запитуючої цьому URL ^[7] .
• Роботи з JavaScript відключений.
• Показує банери ^[8] на основі Google AdSense
• Незважаючи на те, SPI, переглядаючи основних станів контролюється Google Analytics, за допомогою якої прихований <iframe> URL змінюється, коли фундаментальні зміни стану.
• Моделювання модальне вікно дозволяє уникнути створення нової сторінки вікно, це вікно моделювання також досяжні з прямою URL ^[9]
  з текстом уже в розмітці на час завантаження, отже, SEO сумісні.

Маніфест на інших мовах

Іспанська ^[10]

Російська ^[11] спасибі Андрію Geonya, вона може трохи застаріла, оскільки цей маніфест є "живим"

Посилання, які вказують на маніфест

Обговорення ^[12] на DZone

Обговорення ^[13] на TheServerSide.com

Обговорення ^[14] на YCombinator.com

Обговорення ^[15] на JavaHispano.org (на іспанській)

Автор маніфесту: Хосе Марія Арранс Сантамарія