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

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

Рассмотрим классическую схему HTTP. Делается GET запрос , посылается страница, в ней разные поля, делается submit, и эти поля посылаются на сервер, где их принимает в свои ласковые объятия CGI. Вот для чего изначально и был разработан HTTP. И пока все ограничивалось именно таким сценарием — он вполне разумен.

Можно ведь и для десктопного приложения аналогичную модель предложить. Создается форма (диалог), посылается на экран, пользователь заполняет поля и по кнопке OK делается "POST" — эти поля передаются собственно приложению, которое с ними что-то делает (например, в клиентскую БД записывает). Пока десктопное приложение такими формами и ограничивается, само приложение (т.е код помимо кода форм) почти и не нужно, разве что определять, в какой последовательности формы выводить и откуда их брать, остальное формы и сами сделают.

Но десктопное приложение — это не набор форм, в общем случае. И нажатие кнопки OK (Apply, Execute, пункт меню, кнопка тулбара) вовсе не обязательно приводит к снятию полей из формы и их пересылке куда-то. А приводят, вообще говоря, к самым разнообразным действиям, реализуемым невидимой частью десктопного приложения.

А теперь представьте себе, что у десктопного приложения эту невидимую часть (программную логику) похитили и оставили одни формы. Формы эти почувствуют себя крайне неуютно. До этого им друг до друга, быть может, и дела никакого не было, а теперь они начнут лихорадочно искать способ передавать друг другу информацию — жить-то надо. А они сами (диалоговые окна) вовсе для этого и не предназначены, и не умеют это толком делать.

Именно это и произошло с web-формами. Пока форма сама по себе и ее единственное назначение — отослать введенные пользователем данные на сервер — все работает безупречно. Как только пытаемся сделать что-то более сложное — возникают проблемы. Не потому проблемы, что что-то не так реализовано, а потому, что делается попытка употребить не тот инструмент.

Вот представьте себе — выведено некое броузерное окно, пользователь что-то там делает/набирает, нажимает Submit. Форма посылает эти данные серверу. А зачем, собственно говоря, и почему именно POST ? По логике вещей форма должна бы во-первых, определить, нужно ли тут тревожить сервкер, и если да — послать ему некий запрос общего вида (например, в виде XML), в котором, может быть, значения введенных пользователем полей и не упоминались бы, получить от него ответ и в соответствии с ним модифицировать состояние клиентского приложения — от установки галочки в check до полного обновления содержимого.

Да беда-то в том, что нет никакого клиентского приложения. Есть только форма. И общаться формы напрямую не могут, потому как они заменяют друг друга в окне броузера. Вот и приходится этим формам при отсутствии клиентского приложения начинать общаться через сервер. Со всеми вытекающими последствиями в виде серверных событий по изменению состояния select и т.п. А состояния клиентской части и серверной части, вообще говоря, не синхронизированы, так как хозяин этих клиентских форм — не клиентское приложение, а броузер, и как таковой, он может делать все, что пользователь захочет, в том числе и не имеющее никакого отношения к этому web-приложению. Уходить из него и возвращаться, и при этом не ставля его (серверную часть) даже в известность. Отсюда и все проблемы вроде пресловутой кнопки Back.

А вот если бы нормальное клиентское приложенияе было бы, оно бы и взяло на себя управление этими формами, их "листание", передачу информации от одной формы другой и т.д. И, разумееется, клиентское приложение реализовало бы всю "тяжелую" часть программы, вроде обработки изображений, расчет 3D графики, форматировния текста и т.д. В общем, было бы приложением в обычном смысле этого слова, с любыми возможностями. А сервер делал бы то, что ему положено делать — например, записывал бы посланные клиентским приложением данные в БД или посылал бы клиентскому приложению заготовку очередной формы. И т.д.

Ближе всего к этой идее java-апплеты подошли. Но — не пошли они. Почему — трудно сказать. ИМХО просто из-за неудачной реализации. Вспомните, что представлял собой запуск java-машины в Netscape 4.0, к примеру. Если уж появилось об этом сообщение — ждите секунд 20-30. Да и сейчас java реализована не то, чтобы уж очень эффективно. Получить java heap error при размере хипа 256 Мб при обработке одного слайда ppt-файла — это, вообще говоря, суметь надо.

Нынешний AJAX — это отчаянная попытка вернуться к здравому смыслу, к клиентскому приложению то есть. В принципе AJAX мог бы быть полноценным клиентским приложением, если предположить, что страница (в смысле URL) всегда одна, и она изменяет себя вплоть до полной неузнаваемости, запрашивая данные с сервера. Это многое решает, но не все. Броузер все же остается, с его свободой выполнять действия, к клиентскому приложению не имеющие отношения.

Увы, я не вижу иного варианта, кроме как исполнения web-приложения в своем собственном окне. Будет это окно процесса броузер или же отдельного процесса — не так уж важно. Важно лишь одно — оно должно быть логически отделено от броузера. Внутри себя оно должно быть приложением как приложением, с возможностью передавать ему данные (Copy/Paste, из файла и т.д.), а сообщаться с броузером должно только по своей инициативе. Броузер, в свою очередь, должен иметь возможность сообщаться с этим окном, но не распоряжаться в нем как ему вздумается. Например, он может переслать ему команду "перейди в точку с координатами широта= долгота =" (это в применении к EARTH). Но, вполне возможно, приложение ему ответит — не могу выполнить команду, так как нахожусь в состоянии, не допускающем выполнении такой команды. Как и положено любому приложению — например, VS не позволит вам открыть новый проект, если вы в состоянии отладки текущего проекта.

В целом ситуация мне напоминает историю с Windows 9x. Windows 9x — это очень сильно модифицированная MS-DOS 1.0 . Понемногу, без заранее продуманного плана действий, в эту MS-DOS вводили каталоги на диске, графические средства, защищенный режим (DPMI), вытесняющий, а потом истинный параллелизм и т.д. В итоге монстровидность этой системы все росла и росла, внутренняя логичность и стройность падала, система становилась все более и более ненадежной. К счастью, Микрософт это довольно рано поняла и начала линию NT. Первые версии NT (3.1, 3.5) ничего, кроме критики не вызвали, и явно проигрывали Windows 95 и по удобству юзеровского интерфейса, и по простоте работы, и по требованиям к ресурсам . И даже Windows 4.0 во многом проигрывала Windows 98. Но вреям шло, о линии 9x можно уже, пожалуй, и позабыть, а имеем мы XP-Vista, которые можно критиковать, конечно, но нельзя не признать, что это достаточно логичные и осмысленные по своим концепциям операционные системы.

Так что раньше или позже, я надеюсь, здравый смысл и здесь возобладает