Дискуссия, которая развернулась на эту тему, несколько не в том направлении пошла. В значительной мере началось обсуждение пустяков, вроде того, один или два линка нужно и нужно ли выделять мышкой и сохранять. Подумал я и решил начать второй тур, отбросив все пустяки и сосредоточив внимание на сущности.
Основная проблема, связанная с 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, которые можно критиковать, конечно, но нельзя не признать, что это достаточно логичные и осмысленные по своим концепциям операционные системы.
Так что раньше или позже, я надеюсь, здравый смысл и здесь возобладает
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нынешний AJAX — это отчаянная попытка вернуться к здравому смыслу, к клиентскому приложению то есть. В принципе AJAX мог бы быть полноценным клиентским приложением, если предположить, что страница (в смысле URL) всегда одна, и она изменяет себя вплоть до полной неузнаваемости, запрашивая данные с сервера. Это многое решает, но не все. Броузер все же остается, с его свободой выполнять действия, к клиентскому приложению не имеющие отношения.
PD>Увы, я не вижу иного варианта, кроме как исполнения web-приложения в своем собственном окне. Будет это окно процесса броузер или же отдельного процесса — не так уж важно. Важно лишь одно — оно должно быть логически отделено от броузера.
PD>Так что раньше или позже, я надеюсь, здравый смысл и здесь возобладает
Согласен. Вообщем то всё к этому и идёт, AJAX — первый шаг в этом направлении. По идее нужен стандарт на взаимодействие браузера с исполняемым в нём клиентским приложением, в котором будут чётко определяться возможности браузера в этом приложении (те про которые ты написал). Вырожденный случай — окно браузера без кнопок, кроме кнопки закрытия, должен стать базовым для большей части приложений. Кстати такое окно используют некоторые разработчики, открывая страницу приложения не напрямую в браузере, а в окне с OLE компонентом IE (там нету стандартных кнопок назад вперед и т.д.).
PD>Но десктопное приложение — это не набор форм, в общем случае. И нажатие кнопки OK (Apply, Execute, пункт меню, кнопка тулбара) вовсе не обязательно приводит к снятию полей из формы и их пересылке куда-то. А приводят, вообще говоря, к самым разнообразным действиям, реализуемым невидимой частью десктопного приложения.
Но веб-приложение — это не набор форм, в общем случае. И нажатие кнопки OK (Apply, Execute, пункт меню, кнопка тулбара) вовсе не обязательно приводит к снятию полей из формы и их пересылке куда-то. А приводят, вообще говоря, к самым разнообразным действиям, реализуемым невидимой частью веб-приложения.
Я не понимаю, как никак не связаные друг с другом формы, которые ни о чем не знают, вдруг оппа и превращаются в РСДН, ГМыл и прочая
Здравствуйте, Mamut, Вы писали:
M>Я не понимаю, как никак не связаные друг с другом формы, которые ни о чем не знают, вдруг оппа и превращаются в РСДН, ГМыл и прочая
Через сервер, однако. Вместо того, чтобы на клиенте это делать
PD>>Так что раньше или позже, я надеюсь, здравый смысл и здесь возобладает
F>Согласен. Вообщем то всё к этому и идёт, AJAX — первый шаг в этом направлении. По идее нужен стандарт на взаимодействие браузера с исполняемым в нём клиентским приложением, в котором будут чётко определяться возможности браузера в этом приложении (те про которые ты написал). Вырожденный случай — окно браузера без кнопок, кроме кнопки закрытия, должен стать базовым для большей части приложений. Кстати такое окно используют некоторые разработчики, открывая страницу приложения не напрямую в браузере, а в окне с OLE компонентом IE (там нету стандартных кнопок назад вперед и т.д.).
После того, как отправил свое сообщение, вдруг сообразил — а ведь есть у меня такое приложение. Называется Weather Channel Desktop. Предложил мне его поставить, кажется, Skype, я согласился и не жалею. Внешне — интерфейс в стиле web-приложений, гиперлинки, самодельные меню и т.д. Связь с каким-то сервером осуществляет, иначе где бы он брал данные для прогноза погоды. Рекламу умеренно гонит. Какие-то новости , в основном по США. В общем, вполне web-приложение.
Только броузер ему даром не нужен. Это DesktopWeather.exe, самый обычный процесс Windows. Посмотрел сейчас его импорт — классический, то есть это даже не .Net приложение. Installer, uninstaller — все как положено, unwise.exe. Для работы использует Adobe Flash Player, внутри себя. Контекстное меню, его собственное.
M>>Я не понимаю, как никак не связаные друг с другом формы, которые ни о чем не знают, вдруг оппа и превращаются в РСДН, ГМыл и прочая
PD>Через сервер, однако. Вместо того, чтобы на клиенте это делать
Тогда это будет обычное десктоп-приложение. В любом случае тезис о "ничем не связаных друг с другом формах" неверен
Здравствуйте, Mamut, Вы писали:
M>>>Я не понимаю, как никак не связаные друг с другом формы, которые ни о чем не знают, вдруг оппа и превращаются в РСДН, ГМыл и прочая
PD>>Через сервер, однако. Вместо того, чтобы на клиенте это делать
M>Тогда это будет обычное десктоп-приложение. В любом случае тезис о "ничем не связаных друг с другом формах" неверен
Я тебя что-то никак не пойму. Есть формы в броузере, посылаемые с сервера. есть их ответ, посылаемый на сервер. Между собой формы не взаимодействуют непосредственно, только через сервер. И при этом мы имеем обычное десктопное приложение. Объясни.
И кстати, если уж цитируешь — цитируй точно. Где я сказал о "ничем не связаных друг с другом формах" ? Нет такого. Я вот что сказал
PD>Есть набор форм, почти никак на клиенте не связанных друг с другом.
Выделено мной. Общаться друг с другом на сервере эти формы могут, тут спорить не о чем.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Только броузер ему даром не нужен. Это DesktopWeather.exe, самый обычный процесс Windows. Посмотрел сейчас его импорт — классический, то есть это даже не .Net приложение. Installer, uninstaller — все как положено, unwise.exe. Для работы использует Adobe Flash Player, внутри себя. Контекстное меню, его собственное.
PD>Вот так и надо делать.
Это уже война между различными платформами для отображения клиентской части приложения: браузер с его DOM и AJAX, апплеты обрабатывающие flash, java апплеты. Что станет со временем более востребовано разработчиками и развито в техническом плане, то и станет доминирующей технологией. В данный момент это обсуждаемые здесь web-приложения, ущербные в том или ином плане перед другими. Если в какой-то момент в технологии всё явственнее вылазит её ущербность, то либо происходит массовый отказ от технологии, либо "спрос рождает предложение" и технология развивается в соответствии с потребностями сообщества, что, мне кажется, происходит и будет происходить с браузерными web-приложениями. Сейчас следующий шаг должны сделать разработчики браузеров, предоставив программисту UI контроль над оканами браузера по типу обычного десктоп приложения. Вы скажете, "ведь это уже есть в других технологиях". Возможно, но по тем или иным причинам эти технологии не дотягивают до уровня "браузера с DOM и AJAX" (причем я не имею в виду в первую очередь функциональность технологии).
С чем не согласен, так это с тем, что отличительной чертой приложения обязательно должен быть Installer, Uninstaller. Я вообще не согласен что к понятию "приложение" привязывается такие вещи как установка, деинсталляция, версия и т.д. Приложение — средство предоставления пользователю информации по запросу и не более того. Совершенно необязательно (хотя и возможно при желании) загонять приложение в общем случае в рамки десктопного приложения.
M>>>>Я не понимаю, как никак не связаные друг с другом формы, которые ни о чем не знают, вдруг оппа и превращаются в РСДН, ГМыл и прочая
PD>>>Через сервер, однако. Вместо того, чтобы на клиенте это делать
M>>Тогда это будет обычное десктоп-приложение. В любом случае тезис о "ничем не связаных друг с другом формах" неверен
PD>Я тебя что-то никак не пойму. Есть формы в броузере, посылаемые с сервера. есть их ответ, посылаемый на сервер. Между собой формы не взаимодействуют непосредственно, только через сервер. И при этом мы имеем обычное десктопное приложение. Объясни.
Если формы будут общаться друг с другом только на клиенте, то чем тогда веб-приложение будет отличаться от десктоп-приложения?
PD>И кстати, если уж цитируешь — цитируй точно. Где я сказал о "ничем не связаных друг с другом формах" ? Нет такого. Я вот что сказал
PD>>Есть набор форм, почти никак на клиенте не связанных друг с другом.
PD>Выделено мной. Общаться друг с другом на сервере эти формы могут, тут спорить не о чем.
Здравствуйте, Mamut, Вы писали:
M>Если формы будут общаться друг с другом только на клиенте, то чем тогда веб-приложение будет отличаться от десктоп-приложения?
Опять неточно цитируешь. Почему это только на клиенте ? Вполне возможно, что и через сервер тоже будут. Но не в нынешнем стиле. Не через HTTP POST. См. мой исходный постинг в этом треде.
Но, в общем, я тебя понял. Цитирую себя
PD>Не должно быть никаких специальных web-приложений. Должны быть просто приложения
Другое дело, что организованы они могут быть внутри по-разному. Одни абсолютно десктопные, другим нужен локальный сервер, третьим — сервер в Интернете, а четвертым, может быть, и несколько таких серверов одновременно. Скрестить, к примеру. Google Earth с Desktop Weather
M>Тогда в чем проблема?
Не знаю. Я изложил свое видение ситуации, ты возразил, так что в чем проблема — тебе и решать.
F>С чем не согласен, так это с тем, что отличительной чертой приложения обязательно должен быть Installer, Uninstaller. Я вообще не согласен что к понятию "приложение" привязывается такие вещи как установка, деинсталляция, версия и т.д. Приложение — средство предоставления пользователю информации по запросу и не более того. Совершенно необязательно (хотя и возможно при желании) загонять приложение в общем случае в рамки десктопного приложения.
Нет, это я вовсе не утверждаю, я просто пример Desktop Weather привел, что у него они есть. Вообще говоря, они скорее всего не нужны, достаточно просто щелкнуть по линку из броузера, в результате чего запустится это самое приложение. Тем более что инсталлер для Windows — это одно, для Linux — другое.
А вот насчет версии — не согласен. Версия должна быть. Я уже об этом писал. Более того, должны быть доступны предыдущие версии. Мне совсем не улыбается мысль, что авторы программы могут что-то в ней в любой момент поменять, после чего она станет работать несколько не так, как прежняя версия, и кому жаловаться ? Они-то хотели как лучше, я понимаю, а если их "лучше" мне поперек горла ? А если у них расчетный сервис, и из-за небольшого улучшения алгоритма процесс теперь сходится к несколько иным значениям ? Мне что, потом в отчете писать — расчет произведен с помощью такого-то сервиса, который до мая месяца выдавал такие-то результаты, а с мая иные ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Не должно быть никаких специальных web-приложений. Должны быть просто приложения
PD>Другое дело, что организованы они могут быть внутри по-разному. Одни абсолютно десктопные, другим нужен локальный сервер, третьим — сервер в Интернете, а четвертым, может быть, и несколько таких серверов одновременно. Скрестить, к примеру. Google Earth с Desktop Weather
Так оно так и есть. Просто приложения организованы по разному — одним для исполнения нужен Windows, другим JVM, третьим .NET, четвертым браузер.
И еще, все никак не пойму, чем Вам так HTTP не нравится? Вполне нормальный протокол, который, кстати не ограничивается GET/POST (а POST, в свою очередь, подходит далеко не только для передачи содержимого формы).
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
PD>Другое дело, что организованы они могут быть внутри по-разному. Одни абсолютно десктопные, другим нужен локальный сервер, третьим — сервер в Интернете, а четвертым, может быть, и несколько таких серверов одновременно. Скрестить, к примеру. Google Earth с Desktop Weather
+100
Просто в сообщениях, как кажется, сквозит этакая нелюбовь к веб-приложениям
Кстати, формы вполне могут друг с другом общаться, а не запрашивать сервер на каждый чих. Это все зависит от от программиста
PD>А вот насчет версии — не согласен. Версия должна быть. Я уже об этом писал. Более того, должны быть доступны предыдущие версии. Мне совсем не улыбается мысль, что авторы программы могут что-то в ней в любой момент поменять, после чего она станет работать несколько не так, как прежняя версия, и кому жаловаться ? Они-то хотели как лучше, я понимаю, а если их "лучше" мне поперек горла ? А если у них расчетный сервис, и из-за небольшого улучшения алгоритма процесс теперь сходится к несколько иным значениям ? Мне что, потом в отчете писать — расчет произведен с помощью такого-то сервиса, который до мая месяца выдавал такие-то результаты, а с мая иные ?
Версия может быть, но она совсем необязательна. Если приложение настолько специфично, что имеет значение её конкретная реализация (как в случае который ты описал), значит поддержка различных её версий ложится уже на плечи компании приложение выпускающей. Например, захочет наша доблестная налоговая инспекция переделать десктопное приложение "Справка по форме 3НДФЛ" на веб приложение. Формат результирующего файла в каждой версии программы разный и может не прочитаться в другой версии. Значит, чтобы обеспечить версионность, нужно делать что-то наподобие такого:
Это по типу того как авторы программ хранят на официальном сайте архив старых версий для тех пользователей, которые предпочитают "ретро".
Ну или просто добавлять новые функции приложения не трогая старые (зависит от того, что конкретно делает приложение).
То есть в конечном счёте отношение к версиям зависит от самого разработчика приложения. Хорошие разработчики будут по необходимости сохранять версионность.
Различие с десктопными приложениями — невозможность контроля этого дела конечным пользователем. Впрочем на то она и клиент — серверная технология чтобы возникала такая проблема.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Основная проблема, связанная с web-приложениями, ИМХО заключается в том, что их как таковых нет . На клиенте. Нет приложения, имеющего свой жизненный цикл, однажды стартующего и когда-то заканчивающегося. Есть набор форм, почти никак на клиенте не связанных друг с другом.
букв много, а смысл ускользает.
если эта цитата — смысл всего текста, то это глупость напоминает анекдот: "жопа есть, а слова "жопа" — нету".
я лично писал веб-приложения с довольно таки "толстым" клиентом в виде эксплорера и нервущимися соединениями ещё пять лет назад.
gmail работает совершенно как веб-приложение.
по-моему, всё высосано из пальца.
тут люди этим профессионально занимаются и пишут эти самые веб-приложения
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так что раньше или позже, я надеюсь, здравый смысл и здесь возобладает
Вносить какие-то радикальные изменения в браузер ни одна из команд не будет, т.к. этими фичами никто пользоваться не будет из соображений совместимости с другими браузерами. Так что особого прогресса в данной области ожидать не стоит.
M>Вносить какие-то радикальные изменения в браузер ни одна из команд не будет, т.к. этими фичами никто пользоваться не будет из соображений совместимости с другими браузерами. Так что особого прогресса в данной области ожидать не стоит.
Разработчики браузеров должны быть поддержаны институтами по стандартизации как это было в случае HTML, XML, CSS.
Сейчас эти изменения делаются на основе решения "браузер в браузере" по типу Adobe Flash, Silverlight и т.п., то есть по сути дела на браузер ставится плагин, расширяющий его функциональность. В идеале надо чтобы эти возможности попали прямо в DOM браузера. Для этого нужно принятие открытого стандарта, поддержанного производителями браузеров и разработчиками.
Здравствуйте, Mamut, Вы писали:
M>+100
M>Просто в сообщениях, как кажется, сквозит этакая нелюбовь к веб-приложениям
Ни в коем разе. К самой идее приложения, которое во время своей работы обращается к каким-то серверам в Интернете — только за. Да иначе и невозможно в нынешнем мире. В конце концов многие чисто десктопные приложения имеют web-компоненту — линк в окне About на сайт компаниии . Это, конечно, только шутка, не надо на эту тему флейм разводить. Но если серьезнее, то некоторое приложение, бывшее до этого классически десктопным, вполне может стать web-приложением. Понадобились ему некие данные, своих нет, а есть некий web-сервис, что их дает. Приконнектились к нему и стали web-приложением. Без всякого броузера.
M>Кстати, формы вполне могут друг с другом общаться, а не запрашивать сервер на каждый чих. Это все зависит от от программиста
Я не специались в web-программировании. Готов тебе поверить, хотя и не пойму , как они это делают, по крайней мере при одном окне броузера. Но сути дела это не изменит.
