Як інтерпретували форми HTML на початку 90-х?


109

У сучасній павутині HTML- <form>елемент подається та інтерпретується сценарієм. Або інтерпретується мовою програмування на стороні сервера (зазвичай PHP), або інтерпретується за допомогою клієнтського сценарію (майже завжди JavaScript).

Форми існували ще на початку 90-х. Як їх тоді тлумачили?

Згідно з цією статтею у Вікіпедії, тоді було надіслано HTML-форму на основі електронної пошти, але це було ненадійно. Це все було? Чому HTML навіть мав форми, якщо вони були настільки марними без написання сценаріїв? Або це була ситуація з куркою і яйцями?


25
Я використав perl з cgi

67
Завжди
існував

22
Щоб доповнити зображення, були використані деякі ранні форми, action="mailto:staff@example.com"які наказали веб-браузеру запустити електронний поштовий клієнт і перенести подані поля у вигляді неочищеного вмісту нової пошти. Нульове програмування, лише деякі співробітники, щоб обробляти електронні листи вручну.
kubanczyk

2
Перед формами навіть існувало <ISINDEX>, яке часто підключалося до сервера WAIS .
zwol

Відповіді:


182

До сценарію на стороні сервера (PHP, Ruby, node.js) існувало програмування на стороні сервера.

Одним із оригінальних інтерфейсів між веб-серверами та зворотними процесами був загальний інтерфейс шлюзу (CGI). Вона була введена на початку 90-х командою бек-енду NCSA, тоді як форми були введені в HTML Тімом Бернерсом-Лі (який також був у NCSA в той час). Таким чином, форми були введені приблизно в той же час, коли була винайдена CGI.

Спочатку багато людей писали програми CGI в C. Я був одним із тих, хто мав це робити як домашнє завдання. Замість гігантської всеохоплюючої рамки ми писали невеликі програми C, які читають зі stdin та друкують до stdout (ми друкували HTTP-відповідь, а не лише HTML згідно зі специфікацією CGI). На веб-сайті було багато цих невеликих програм, кожна з яких робила одну дрібницю та оновлювала деяку базу даних (іноді ця база даних була просто плоским файлом).

Майже як тільки вона була представлена, люди також почали писати сценарії CGI в Perl. Тож насправді не було перехідного періоду між програмами C та мовами скриптів. Люди просто перестали писати сценарії CGI на мові C, оскільки це було швидше зробити це на мовах сценаріїв.


4
Чудова відповідь і від вас, і від @Dekel. Ці відповіді та запропоновані посилання справді заповнюють прогалину. Я не можу не задатися питанням, скільки веб-сайтів насправді турбує реалізувати будь-який із цих матеріалів, перш ніж такі технології, як JS, Perl, PHP, були доступні для веб-сценаріїв. Але це питання для іншого дня.
Джеймс Джонс

15
@JamesJones, багато і багато з нас зробили. Почати не все було так важко, хоча бракувало інструментів для масштабування великих та високоефективних веб-додатків. Я читав програмування CGI у всесвітній мережі в кінці 90-х і в підлітковому віці почав писати всілякі коди CGI.
Дан Ленскі

12
Власне, базову програму CGI написати дуже просто. Просто роздрукуйте статичні заголовки та деякі HTML з перемежуванням даних. Просто технологія (HTML, змішана з заголовками, змішаними з кодом ...) не відповідає масштабам складних програм. Значить, були винайдені рамки ...
sleske

12
Якщо ви все ще хочете побачити CGI в дії, спробуйте розклад руху залізниць Швейцарії: sbb.ch - введіть місце відправлення та призначення - натисніть червону кнопку - потім подивіться на URL-адресу в браузері, особливо частину query.exe: -)
theDmi

8
Насправді "наскільки це було поширено": ну, набагато більше веб-сайтів тоді були повністю статичними. Але два часто зустрічаються біти активного вмісту були "гостьовими книгами" (застарілими блогами / соціальними мережами / спамом) та "лічильниками хітів".
pjc50

70

Сторона сервера насправді завжди була на знімку.

Сервер Apache HTTP був доступний з 1995 року, а в 1996 році він також підтримував Perl (який використовувався як мова програмування на стороні сервера).

JavaScript був створений у 1996 році, і Netscape був першим браузером, що підтримував клієнтську мову (реалізація інших постачальників браузерів базувалася на роботі, що була виконана в Netscape).

У 1993 році виходить браузер Mosaic із підтримкою зображень, вкладених списків та заповнення форм.

В основному - кожен сервер HTTP, який може обробляти запит і передавати його в якусь програму (незалежно від того, якою мовою написано цю програму), є додатком на сервері. Він може бути написаний мовою сценаріїв (Perl / Python / PHP / Ruby), мовою високого рівня (Java / C #), а якщо дуже хочеться - навіть складанням. Все, що вам потрібно зробити, це переконатися, що ви «дотримуєтеся протоколу».


1
Гарна історія. Отримано. Однак форми були впроваджені до 1995 року. Я не можу розробитись лише коли, але в en.wikipedia.org/wiki/HTML є Dave Raggett's competing Internet-Draft, "HTML+ (Hypertext Markup Format)", from late 1993, suggested standardizing already-implemented features like tables and fill-out forms.ваш останній абзац, що описує практику до 1995 року?
Джеймс Джонс

3
@JamesJones: Перевірте вікіпедію на загальному інтерфейсі шлюзу
slebetman

2
@JamesJones, додав інформацію про браузер Mosaic та форми заповнення. Ви також маєте чудову відповідь slebetman щодо CGI.
Dekel

1
@JamesJones Стандарти не є чіткими, і вони повною мірою застосовуються до більшості речей у мережі (хоча не до Інтернету в цілому). Стандарт HTML був (і справді все ще є) жахливим, і кожен створив власні розширення. Мозаїка, Netscape та Internet Explorer були найбільш відомими - більшість їх розширень були додані до пізніших стандартів HTML, причому Netscape та IE дуже співпрацювали з цим. HTML навіть тоді не вбудовував зображення ( img) - автор вважав це непридатним до ідеї гіпертексту; тільки успіх Mosaic / Netscape змусив зміни стандарту.
Луань

3
Ця відповідь не обов'язково є помилковою, але я не зовсім впевнений, як речі, представлені щонайменше через 2-3 роки після того, як форми були доступні у браузері, є свідченням того, що форма завжди підтримувала серверні форми.
8bittree

1

JavaScript не був таким заздалегідь (пекло Ajax ще не вийшов). Так що це було чисто серверно. Переважно CGI (будучи Perl) та PHP.

Був також Coldfusion, але не був популярним фаворитом.

Врешті-решт, наприкінці 1999 та на початку 2000-х вийшли ASP.NET (aspx) та JavaServer Pages (jsp), хоча багато комерційних сайтів використовували aspx та jsp з очевидних причин.

Зауважте, Java-аплети також існували (в основному для візуалізації), але їх потрібно було окремо завантажувати та підтримувати браузером.


3
Насправді я програмував ASP до початку 1998 року. До цього був ще один стандарт MS, який називався htxшаблони.
Маленький Санті

1
^ звучить так, ніби ви були одним із оригіналів! Давно товариш! : D: D
tfont

1

Крім того, я натрапив на цікавий фрагмент історії у Вікіпедії. Форми HTML можна також надсилати електронною поштою, використовуючи mailto:адресу в targetатрибуті. Не здавалося популярним, але все-таки класно!

Цитуючи статтю у Вікіпедії :

Підтримка користувача-агента для надсилання форми HTML на основі електронної пошти з використанням URL-адреси "mailto" як дії форми була запропонована в RFC 1867, розділ 5.6, протягом епохи HTML 3.2. Різні веб-браузери реалізували його, використовуючи окрему електронну програму або використовуючи власні рудиментарні можливості SMTP. Незважаючи на те, що іноді ненадійно, це було коротко популярним, як простий спосіб передачі даних форми без залучення веб-сервера чи скриптів CGI.

І RFC 1867 (листопад 1995 р.):

5.6 Дозволити форму ACTION бути "mailto:"

Незалежно від цієї пропозиції, для
інтерпретації HTML користувачів користувачам було б дуже корисно дозволити АКЦІЮ у формі бути
URL-адресою "mailto:". Це здається гарною ідеєю, з цією
пропозицією чи без неї . Аналогічно, ДІЯ у формі HTML, яка отримується через пошту, ймовірно, повинна бути за замовчуванням повідомленням "відповідь до:".
Ці дві пропозиції дозволять подавати форми HTML через
сервери HTTP, але надсилати їх назад поштою, або, як альтернативу, дозволяти HTML-форми
надсилати поштою, заповнюватись відомими HTML адресатами, а результати надсилати назад.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.