Здравствуйте, Sinclair, Вы писали:

A>>А это и должен быть веб-сервис, веб-приложение должно состоять из клиента в браузере и веб-сервиса.

S>Ок, это означает, что как минимум та часть приложения, которая отвечает за клиента в браузере, таки должна знать, как он выглядит.
S>А веб-сервис при этом должен обеспечивать функции, которые помогают клиенту продемонстрировать нужное поведение.

Мне кажется, или вы действительно начали очереодной раунд битвы "толстый против тонкого", причем не отдавая себе в этом отчета?

Здравствуйте, Sinclair, Вы писали:


PD>>string[] values = Client.getValuesForCombo(Server); // вот тут запрос к серверу
PD>>Client.Form.Combo.Fill(values);

PD>>и все. Нет ответа от сервера в обычном понимании слова (Response).
S>Вообще-то, Response здесь один хрен присутствует. Потому что какие-то values for combo таки приезжают.

Нет. Нет кода на сервере. Есть клиент, запрашивающий с него данные. А поэтому нет никакого Response — в смысле HTTP.

PD>>Никакого отличия по существу. И не должно его быть.
S>И нету его. Рекомендую посмотреть на то, каким образом функционирует google suggest. Ровно комбобокс, и ровно данными с сервера.

Ну если так — значит я прав

S>>>Смотря в какой модели. В модели веб приложений — да. Сервер таки должен знать, как выглядит интерфейс пользователя.
PD>>Вообще-то общепринято разделение вида и данных. И документ не должен знать, как выглядит вид.
S>Павел, не нужно сводить "приложение" к коду на сишарпе. Посмотри на maps.google.com — они работают именно так, как ты написал. Только лучше.

Прекрасно. Итак, эта модель, которую я описал, верна, с твоей точки зрения, и maps.google.com — тому подтверждение. Остается дождаться, когда другие подходы (в т.ч. ASP.NET и т.д.) уйдут в историю.

S>Павел, нынешняя архитектура как раз мегаправильная.

Нынешняя — это что ? maps.google.com или ASP.NET ?

S>Зачем изобретать кривобокий велосипед, искусственно противопоставляя приложение и его данные?

А это, знаешь ли, изобретено лет 20, а может и больше назад. И не приложение и данные, а представление и данные. Разницу чувствуешь ?

S>>>б) приложение размазано по нескольким независимым компонентам.
PD>>Это требует конкретизации. С высоты птичьего полета здесь 2 компоненты — клиент и сервер. И как именно оно размазано между ними — можно и так решить и иначе. Если с нуля решать проблему.
S>Павел, проблема решена примерно в 1995 году.

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


PD>>Обсуждать не буду, так как я исходно считаю, что для приложений броузеру делать нечего.
S>А кому есть чего? Надо отдельно покупать диск с приложением?

Нет. Скачать приложение. Установить его. Запустить. Работать.
Для закачки — HTTP/FTP и броузер. Для работы они тут ни к чему.

PD>>Опять таки в рамках нынешней врхитектуры ответа нет.
S>Павел, в рамках нынешней архитектуры есть ответы на всё это. Просто нужно немножко поизучать тему, перед тем как пытаться полить ее помоями.

Оставляю сей пассаж на твоей совести и не комментирую.

PD>> А вообще — просто некий код с UI (Java ?) на клиенте
S>А почему, собственно, Java? Почему не JavaScript? Почему не ActiveScript? Почему не MSIL?

Да бога ради, разве обязательно Java ? Я, кстати, после слова "Java" вопрос поставил, именно чтобы подчеркнуть это. Не в языке дело, а в модели. А суть ее предельно проста

Не должно быть никаких специальных web-приложений. Должны быть просто приложения.

S>Неужели для того, чтобы архитектура стала "некривой", нужно непременно рисовать контролы при помощи устаревших на 20 лет "виджетов" и "графических примитивов"?

Что за чепуха! При чем тут устаревшие виджеты и примитивы (кстати, интересно, устарел ли графический примитив "окружность", и если да — что должно ему на смену придти ? . При чем тут рисование контролов вообще ? Оно может быть любым, в зависимости от ОС, к примеру. Контролы и прочие элементы UI могу меняться со временем. И какое это вообще к архитектуре отношение имеет ? Если поменять листбокс на листвью — что, архитектура изменится ?

Здравствуйте, AndrewVK, Вы писали:

AVK>Нифига себе исскуственен. Увеличение объема считываемых с диска данных и увеличение сетевого трафика -> увеличение времени отклика по твоему исскусственное ограничение? Ну тогда дальше, наверное, разговаривать уже не о чем.

Маленький комментарий по трафику можно ? А пересылка туда-сюда HTML страницы (клиент ее GET, потом ее же по сути POST) — это как насчет трафика ? И хорошо еще, если там нет AutoPostBack, а иначе на каждый чих пользователя такие вот действия. А надо было переслать, быть может, один бит (юзер галочку поставил)

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Маленький комментарий по трафику можно ? А пересылка туда-сюда HTML страницы (клиент ее GET

Нормально. Должен же как то интерфейс на клиента попасть.

PD>, потом ее же по сути POST

Это как? В POST никакие страницы не пересылаются.

PD> И хорошо еще, если там нет AutoPostBack
PD>, а иначе на каждый чих пользователя такие вот действия. А надо было переслать, быть может, один бит (юзер галочку поставил)

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Маленький комментарий по трафику можно ? А пересылка туда-сюда HTML страницы (клиент ее GET, потом ее же по сути POST) — это как насчет трафика ?
Павел, вы проявляете трогательное незнакомство с протоколом HTTP и форматом HTML.

Во-первых, GET формы относительно трафика вполне себе неплох. Читать про статус код 304.
Во-вторых, "ее же" POST не бывает. В эту сторону едет, скажем, text/html, а в ту — application/x-www-form-urlencoded. Или multipart/form-data.
То есть уезжают всё же данные, а не сама форма — в полном соответствии с вашими наивными представлениями о "прямой" архитектуре.

Впрочем, современные веб-приложения на тег form не полагаются (в частности, именно потому, что набор енкодингов крайне ограничен). Вместо этого делается отправка дополнительного "закадрового" запроса, и он вполне может отправлять только необходимые данные.

PD> И хорошо еще, если там нет AutoPostBack, а иначе на каждый чих пользователя такие вот действия.
Павел, я надеюсь вы научитесь отличать неудачные ASP.NET приложения от хороших веб-приложений.
PD>А надо было переслать, быть может, один бит (юзер галочку поставил)

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет. Нет кода на сервере. Есть клиент, запрашивающий с него данные. А поэтому нет никакого Response — в смысле HTTP.
Ничего непонятно. Кода на сервере нет, response нет. А откуда значения-то берутся?


S>>>>Смотря в какой модели. В модели веб приложений — да. Сервер таки должен знать, как выглядит интерфейс пользователя.
PD>>>Вообще-то общепринято разделение вида и данных. И документ не должен знать, как выглядит вид.
S>>Павел, не нужно сводить "приложение" к коду на сишарпе. Посмотри на maps.google.com — они работают именно так, как ты написал. Только лучше.

PD>Прекрасно. Итак, эта модель, которую я описал, верна, с твоей точки зрения, и maps.google.com — тому подтверждение. Остается дождаться, когда другие подходы (в т.ч. ASP.NET и т.д.) уйдут в историю.
Только не ASP.NET, а скорее ASP.NET Web Forms. Потому что сам по себе ASP.NET — очень хорошая штука. Более качественных реализаций HTTP-конвееров для широкого класса применений я не встречал.
S>>Павел, нынешняя архитектура как раз мегаправильная.
PD>Нынешняя — это что ? maps.google.com или ASP.NET ?
То, что лежит в основе и того и другого — HTTP и внутрибраузерные технологии.

PD>Ну-ну. Проблемы я тут не вижу, так что что именно такое случилось примерно в 1995 году, не понял.
Ну это же ты написал "если с нуля решать проблему". Теперь вдруг тыее не видишь. Кто здесь?

В 1995 году вышел HTTP1/1. HTTP 1/2 так и не вышел.

PD>>>Обсуждать не буду, так как я исходно считаю, что для приложений броузеру делать нечего.
S>>А кому есть чего? Надо отдельно покупать диск с приложением?

PD>Нет. Скачать приложение. Установить его. Запустить. Работать.
PD>Для закачки — HTTP/FTP и броузер. Для работы они тут ни к чему.
Ок, продолжаем непримиримую борьбу с невежеством.
Вот смотрите, Павел, предположим, мы хотим объяснить друг другу, где мы живем и как туда пройти. Вот я могу дать вам ссылку в веб приложение. Вот она. И вы одним кликом попадаете в нужное приложение. А вы что мне дадите? Пошаговую инструкию, как "Скачать приложение. Установить его. Запустить. Работать."?

Поздравляю, мы только что столкнулись с очередным преимуществом веб приложений — адресуемостью.
Стоит отметить, что адресуемость не является обязательным атрибутом веб-приложений. Запросто можно написать веб-приложение, которое ее лишено.
Тем не менее, хорошее веб-приложение обязано быть адресуемым.

S>>Павел, в рамках нынешней архитектуры есть ответы на всё это. Просто нужно немножко поизучать тему, перед тем как пытаться полить ее помоями.
PD>Оставляю сей пассаж на твоей совести и не комментирую.
Ну и зря.

PD>Я, кстати, после слова "Java" вопрос поставил, именно чтобы подчеркнуть это. Не в языке дело, а в модели. А суть ее предельно проста
PD>Не должно быть никаких специальных web-приложений. Должны быть просто приложения.
Непонятно, откуда взялась такая ненависть к веб-приложениям. У них есть масса преимуществ относительно "просто приложений". Никаких недостатков в этой теме пока озвучено не было — исключительно дефекты конкретных реализаций.
S>>Неужели для того, чтобы архитектура стала "некривой", нужно непременно рисовать контролы при помощи устаревших на 20 лет "виджетов" и "графических примитивов"?
PD> При чем тут рисование контролов вообще ? Оно может быть любым, в зависимости от ОС, к примеру. Контролы и прочие элементы UI могу меняться со временем. И какое это вообще к архитектуре отношение имеет ? Если поменять листбокс на листвью — что, архитектура изменится ?
Гм. Павел, если мы копнем чуть глубже настольные приложения под Windows, то окажется, что архитектура UI у них построена на Message Queue, GDI и Windowing.
Листбокс и Листвью — всего лишь тонкие надстройки над этими основами. Поэтому от замены одного на другое, естественно, архитектура никак не поменяется.

Чем отличаются от них веб-приложения?
Тем, что веб приложение описывает свой GUI на совершенно другом языке. Все остальные положительные черты "обычных" приложений легко переносятся и на веб приложения.

Здравствуйте, Sinclair, Вы писали:

S>Только не ASP.NET, а скорее ASP.NET Web Forms. Потому что сам по себе ASP.NET — очень хорошая штука. Более качественных реализаций HTTP-конвееров для широкого класса применений я не встречал.
Но на чистых конвейерах делать графику хреноватенько.

S>Поздравляю, мы только что столкнулись с очередным преимуществом веб приложений — адресуемостью.
S>Стоит отметить, что адресуемость не является обязательным атрибутом веб-приложений. Запросто можно написать веб-приложение, которое ее лишено.
S>Тем не менее, хорошее веб-приложение обязано быть адресуемым.
Чудно. Пожалуй единственный плюс (правда иногда действительно необходимый). А дальше начинается борьба. Борьба с как выежиться в рамках эксплореров, которые плохо совместимы друг с другом. Борьба с безопасностью эксплорера. Борьба с Http. Особенно с его текстуальностьюю Открыть файл с длинным русским именем проблема. Даже борьба с твоим любимым кэшем. Ну очень он не нужен в SSL. И на get'ы в url ставить уникальность задалбывает.

S>Непонятно, откуда взялась такая ненависть к веб-приложениям. У них есть масса преимуществ относительно "просто приложений". Никаких недостатков в этой теме пока озвучено не было — исключительно дефекты конкретных реализаций.
Кривизна заложена в самом WWW. Пытаясь предоставить универсальность, там где ее изначально не было решение настолько усложнили.

S>Гм. Павел, если мы копнем чуть глубже настольные приложения под Windows, то окажется, что архитектура UI у них построена на Message Queue, GDI и Windowing.
S>Листбокс и Листвью — всего лишь тонкие надстройки над этими основами. Поэтому от замены одного на другое, естественно, архитектура никак не поменяется.
Трабла в том, что в Виндах у тебя есть возможность практически полной имплементации с нуля. И достаточно простой способ. В случае Browser — такого нет. Если у тебя целевая платформа IE5, то глядя в хелп по IE7 понимаешь, как много сделать трудно или вообще нельзя. Вот трудно сделать удобный множественный выбор файлов не потеряв чудо деплоинг. Ну хоть убейся.

S>Чем отличаются от них веб-приложения?
S>Тем, что веб приложение описывает свой GUI на совершенно другом языке. Все остальные положительные черты "обычных" приложений легко переносятся и на веб приложения.
Нет. Хранение состояние транзакции (уже это обсуждалось). Доступ к ресурсам компьютера. Ну тяжко делать обсчеты графа в IE ограниченный JavaScript и его глюкавой многопоточностью(если его вообще можно назвать многопоточной). В результате, из обычного приложения мы имеем только некоторый сложнопрограммируемый UI, и практически все. Остальные проблемы кладем на сервак. Ну про недоверие эксплорера и виндов к коду — выполняющемся на нем, я не говорю.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Маленький комментарий по трафику можно ? А пересылка туда-сюда HTML страницы (клиент ее GET, потом ее же по сути POST) — это как насчет трафика ?
S>Павел, вы проявляете трогательное незнакомство с протоколом HTTP и форматом HTML.

Не думаю. Скорее просто неточно выразился.

S>Во-первых, GET формы относительно трафика вполне себе неплох. Читать про статус код 304.
S>Во-вторых, "ее же" POST не бывает. В эту сторону едет, скажем, text/html, а в ту — application/x-www-form-urlencoded. Или multipart/form-data.

Меня не интересуют детали. Вот представь себе , что вся работа идет по одному урлу. Вначале запрашиваем эту страницу (GET). Потом посылаем обратно данные (POST). Потом эта страница опять приезжает сюда в несколько ином виде , так ? Потом POST опять. И т.д. Зачем все эти пересылки ?
Только не надо мне про кеширование на стороне клиента говорить.

S>Павел, я надеюсь вы научитесь отличать неудачные ASP.NET приложения от хороших веб-приложений.

Не-а. Не сумею, так как при "броузерной" архитектуре последних просто быть не может

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Нет. Нет кода на сервере. Есть клиент, запрашивающий с него данные. А поэтому нет никакого Response — в смысле HTTP.
S>Ничего непонятно. Кода на сервере нет, response нет. А откуда значения-то берутся?

Не передергивай. Я же ясно сказал — нет Response в смысле HTTP. А есть просто сокет, который открывает клиент и по которому он делает запрос с сервера данных и получает их.


PD>>Прекрасно. Итак, эта модель, которую я описал, верна, с твоей точки зрения, и maps.google.com — тому подтверждение. Остается дождаться, когда другие подходы (в т.ч. ASP.NET и т.д.) уйдут в историю.
S>Только не ASP.NET, а скорее ASP.NET Web Forms. Потому что сам по себе ASP.NET — очень хорошая штука. Более качественных реализаций HTTP-конвееров для широкого класса применений я не встречал.

С этим вполне могу согласиться.

S>>>Павел, нынешняя архитектура как раз мегаправильная.
PD>>Нынешняя — это что ? maps.google.com или ASP.NET ?
S>То, что лежит в основе и того и другого — HTTP и внутрибраузерные технологии.

HTTP сам по себе ни хорош ни плох, хотя его вообще-то ИМХО проектировали немного не для того, для чего используют . Насчет браузеров — не согласен.


S>В 1995 году вышел HTTP1/1. HTTP 1/2 так и не вышел.

Ах, вот ты о чем...

PD>>Нет. Скачать приложение. Установить его. Запустить. Работать.
PD>>Для закачки — HTTP/FTP и броузер. Для работы они тут ни к чему.
S>Ок, продолжаем непримиримую борьбу с невежеством.

Этот пассаже тоже на твоей совести оставляю.

S>Вот смотрите, Павел, предположим, мы хотим объяснить друг другу, где мы живем и как туда пройти. Вот я могу дать вам ссылку в веб приложение. Вот она. И вы одним кликом попадаете в нужное приложение. А вы что мне дадите? Пошаговую инструкию, как "Скачать приложение. Установить его. Запустить. Работать."?

Ну и ну! Боюсь, что теперь мне надо вести борьбу с элементарным нежеланием понять

Вот я вам даю тоже ссылку

http://down6.flashget.com/flashget196en.exe

По этой ссылке с помощью броузера (или аналогичных средств) вам удастся скачать себе некий EXE. После этого запустите этот EXE (инструкцию дать ? , и у вас будет FlashGet, с помощью которого вам в дальнейшем будет легче и удобнее скачивать другие EXE и не только EXE.

Вот и вся инструкция ? Очень сложно ?

А теперь представь себе, что есть Earth.EXE, который ... в общем то же, что и wikimapia.

А теперь давай забудем про EXE. Может, это EXE, может, jar, может еще что-то. Есть линк, по нему заходим, оно скачивается (броузером!) и запускается (но уже без всякого броузера!) И ведет себя как приложение. Собственно говоря, я, юзер, вообще не знаю, web оно или не web. Куда и как и по какому протоколу оно обращается — меня, юзера, не очень интересует.

Кстати, твоя ссылка с wikimapia очень даже показательна. Все там прекрасно, одно непонятно — броузер-то зачем ? Если бы это просто в окне было — чем хуже ?

PD>>Не должно быть никаких специальных web-приложений. Должны быть просто приложения.
S>Непонятно, откуда взялась такая ненависть к веб-приложениям. У них есть масса преимуществ относительно "просто приложений". Никаких недостатков в этой теме пока озвучено не было — исключительно дефекты конкретных реализаций.

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

S>Гм. Павел, если мы копнем чуть глубже настольные приложения под Windows, то окажется, что архитектура UI у них построена на Message Queue, GDI и Windowing.

Ты давно это узнал ? Если недавно — поздравляю !

S>Листбокс и Листвью — всего лишь тонкие надстройки над этими основами. Поэтому от замены одного на другое, естественно, архитектура никак не поменяется.

Ну слава богу

S>Чем отличаются от них веб-приложения?
S>Тем, что веб приложение описывает свой GUI на совершенно другом языке.

Именно. На языке, который изначально не был приспособлен для описания приличного GUI и неспособен к этому до сих пор.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Именно. На языке, который изначально не был приспособлен для описания приличного GUI и неспособен к этому до сих пор.

А как же GWT? Java как Java

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да и прочего идиотизма хватает. Одни только "серверные элементы управления" чего стоят! Серверный комбобокс — это как ? Я что-то вообще его с большим трудом себе представляю . И за каким чертом серверу знать, что где-то на клиенте за 1000 км от него есть комбобокс

Напрягает, что общение между клиентом и сервером осуществляется в терминах событий представления. Типа: нажали такую-то кнопку, выбрали в комбобоксе другой пункт и т.п. Причем каждый раз с клиента отправляется все состояние представления — viewstate, значения во всех контролах (должен же сервер знать все что содержиться в представлении!.. ). Вся эта страничка воссоздается на сервере, вызывается наконец-то обрабочик этого события, формируется новая страница и отправляется клиенту... Не могу понять, почему это кем-то считаеться правильным?!

PD>ИМХО действительно идея Java-апплетов является наилучшей. Подчеркиваю, идея, а не текущая реализация. Есть приложение (на Java), исполняемое на клиенте. Приложение обращается к серверу, сервер выполняет действия, клиент получает ответ. Фактически та же модель, что и в настольных приложениях типа multi-tier. Все.
+1

Здравствуйте, Sinclair, Вы писали:

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

S>Рассмотрим эти особенности повнимательнее. Вот, к примеру, пользователь набирает в браузере maps.google.com.
S>Благодаря а) у него на машине волшебным образом образуется замечательный клиент, который умеет обращаться к картографическому сервису гугла. Этот клиент конечно ограничен по своим возможностям, но большинство существующих, к примеру, Delphi приложений не дотягивают до его функционала на века.

Ладно, Delphi оставим в покое, все же, похоже, уходящая технология.

Заходим вот сюда, как ты и рекомендовал

http://www.wikimapia.org/#lat=54.769231&lon=83.101251&z=18&l=1&m=a&v=2

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

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

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

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

Теперь о UI.

Органы управления (ползунок с зумом и стрелки) находятся не на своем месте. Они расположены в клиентской области и заслоняют часть изображения. Им место не здесь, а на тулбаре.

Ну вот, слово и сказано.

Тут неделю назад получил я частное письмо от одного RSDN-овца с просьбой помочь. Ему нужен тулбар, который встраивался бы в IE, Mozilla, Opera... Он нашел на RSDN мой постинг 3-летней давности и попросил совета.

Что я мог ему ответить ? Если бы тулбар для десктопных приложений — да бога ради, хоть на Win32, хоть на MFC, хоть на Delphi, да даже на .Net. Но ему нужно тулбар, встраиваемый в броузеры.

Про разработку тулбаров для IE я краем уха слышал. Если покопаюсь — может, разберусь за некоторое время. Не уверен, правда, что тулбар для IE7 будет работать для IE6. Но вот в чем совершенно уверен — это в том, что для Mozilla придется начинать все сначала, а про ее тулбары я слышал краем от края уха. Опера — вообще не знаю. Сафари ? Вы что, издеваетесь ?

И при этом речь идет все же о исполняемом (x86) коде, неком плагине, который встраивается в броузер и не зависит от страницы. А как насчет модификации тулбара IE из HTML страницы ?

Пойдем дальше. Меню.

Открыть новое окно броузера без верхнего меню — раз плюнуть, а вот можно ли его убрать в текущем окне броузера — не знаю, не видел такого. А хотелось бы вместо этого меню, которое вообще ни к чему на www.wikimapia.org, иметь то меню, которое для этой страницы наиболее подходит. Как насчет модификации меню любого броузера из страницы, а ?

В результате имеем, что имеем. Когда на странице нужно меню, его начинают из подручных средств изготавливать. Из гиперлинков, проще говоря, с JavaScript, чтобы эффект выпадения подменю сделать. Каждый на свой лад делает. ДОСовские времена напоминает, когда каждый свое меню изобретал (помнишь меню Лексикона, ранних версий Нортон Утилит, Supercalc ?). Причем ранние ДОСовские времена — в поздние времена были уже Turbo Professional, Turbo Vision...

Дальше пойдем. Правая кнопка, контекстное меню.

В обычном окне броузера там — сам знаешь что. Причем, конечно, в разных броузерах по-разному. И даже в одном броузере зависит от того, где щелкнешь. И большая часть пунктов никакого отношения к текущей странице не имеет. Вот, например, есть там у меня Download All with Flashget. Это мне туда Flashget вставил. Хорошее дело, если речь идет просто о странице со ссылками, а вот на www.wikimapia.org оно нужно ? Земной шар себе перекачать ? Не нужно. Поэтому на www.wikimapia.org это контекстное меню отключили вообще. Правильно, конечно, сделали, но почему бы вместо него свое не установить ? Пустяковая, прямо вам скажу, работа для десктопных приложений. А для броузера как ? Чтобы в любом броузере работало! Ась ?

Дальше пойдем. Вот нашел я свой дом и захотел этот кусочек себе на память вытащить. Попробовал мышкой выделить регион для последующего Ctrl-Ins — не выделяется. Вместо этого карта сдвигаться начинает. Ладно, допустим, это так задумано — не давать мне возможности грабить куски (хотя и непонятно, зачем). Пойду-ка я на другую страницу (http://www.google.ru/). Лого там у них сверху красивое. Хочу кусочек из него вырезать и сохранить. Нет, тоже не получается. Придется мне эту картинку целиком сохранить, а потом (ай-яй-яй) запустить некий десктопный графический редактор, чтобы вырезать нужный кусок.

Дальше пойдем. Вот зашел я на www.wikimapia.org , посмотрел и решил другое окно броузера открыть. Собрался было там www.rsdn.ru набрать, да призадумался. Кто их там , на этом RSDN знает, а вдруг трояна какого-то подсунут или еще что-то сделают нехорошее ? Ребята там ушлые, все могут сделать. Нет уж, приму-ка я меры. Зачем, спрашиватся, мне Internet Options дано ? Вот и зайду туда, поставлю High Level, поупражняюсь насчет trusted и не очень trusted сайтов, поставлю вместо Enabled Prompt, а то и Disabled. В общем, приму меры против этих деятелей с RSDN, чтобы они мне никакого вреда принести не смогли. Обложусь защитой со всех сторон. Да и картинки там на RSDN большие, отключу-ка я их показ.

Обложился. Все прекрасно, все угрозы с RSDN блокированы. Да вот беда — что-то www.wikimapia.org тоже работать перестала. Не показывается карта, хоть тресни. Вместо картинок одни placeholders. И показать отдельный кусок нельзя — контекстное меню-то заблокировано. М-да... Это что же за web-приложение такое, которое можно элементарно заставить не работать, поменяв ему настройки без его ведома ?

Ну что, продолжать ? Продолжим. Подумал я и решил, что зря я так плохо о RSDN подумал. Никаких там вредителей нет, доверять им можно , да и картинки там небольшие, пусть качаются. Верну все обратно (если смогу вспомнить, что я там изменил). И www.wikimapia.org опять заработала, даже странно Подкачала свои куски изображений и все показала.

Только вот мусору у меня много в Temporary Internet Files что-то скопилось. Пожалуй, сотру я его. И стер (правда, стер).

А тут как на грех Интернет обрушился (это уже фантазия). Печально. Ладно, пока он не работает, на карту из www.wikimapia.org посмотрю. Хм, а куда она делась ? Нет ее почему-то... Броузер пытается заново все квадраты подкачать. Это кто же у моего web-приложения текущие данные удалил и его даже в известность не поставил ?

Ладно, хватит, хотя можно бы еще столько же накатать...

И при этом речь идет о хорошем web-приложении. Что уж тогда о плохих говорить ?

И как же быть с Delphi приложениями, которые не дотягивают до этого функционала на века ? Неужели только через 100 лет мы сумеем картинки в настольных приложениях показывать ? Ты часом не из 19 века это письмо писал ?

Попытка с негодными средствами — вот самое точное определение т.н. web-приложений.

PD>Органы управления (ползунок с зумом и стрелки) находятся не на своем месте. Они расположены в клиентской области и заслоняют часть изображения. Им место не здесь, а на тулбаре.

Google Earth


PD>Дальше пойдем. Вот нашел я свой дом и захотел этот кусочек себе на память вытащить. Попробовал мышкой выделить регион для последующего Ctrl-Ins — не выделяется.

А в каких десктоп приложениях есть подобная функциональность???


PD> Это что же за web-приложение такое, которое можно элементарно заставить не работать, поменяв ему настройки без его ведома ?

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


PD>Это кто же у моего web-приложения текущие данные удалил и его даже в известность не поставил ?

del c:\Windows /s/q

Да и вообще на любой папке, хранящей данные любого приложения.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Меня не интересуют детали. Вот представь себе , что вся работа идет по одному урлу. Вначале запрашиваем эту страницу (GET). Потом посылаем обратно данные (POST). Потом эта страница опять приезжает сюда в несколько ином виде , так ?
Нет. Зачем мне представлять, что "вся работа идет по одному урлу"? Это противоречит базовой концепции веб-приложений — "адресуемости".
PD>Потом POST опять. И т.д. Зачем все эти пересылки ?
PD>Только не надо мне про кеширование на стороне клиента говорить.

S>>Павел, я надеюсь вы научитесь отличать неудачные ASP.NET приложения от хороших веб-приложений.
PD>Не-а. Не сумею, так как при "броузерной" архитектуре последних просто быть не может
Павел, я по прежнему продолжаю не понимать, почему ты выбираешь какие-то плохие примеры, и заявляешь, что хороших приложений не бывает.

Здравствуйте, GlebZ, Вы писали:

S>>Только не ASP.NET, а скорее ASP.NET Web Forms. Потому что сам по себе ASP.NET — очень хорошая штука. Более качественных реализаций HTTP-конвееров для широкого класса применений я не встречал.
GZ>Но на чистых конвейерах делать графику хреноватенько.
Ну да, просто обработка графики пока что в вебе встречается редко; поэтому надстройки над конвеером, ориентированной на графику я пока не видел. Самоделки, выводящие каптчу, не в счёт.
GZ>Чудно. Пожалуй единственный плюс (правда иногда действительно необходимый). А дальше начинается борьба. Борьба с как выежиться в рамках эксплореров, которые плохо совместимы друг с другом.
Это есть. Согласен. Но это не проблема архитектуры, а проблема реализации. Выберешь другую архитектуру — будешь бороться с чем-нибудь другим. Что, не сталкивался с глюками ListView? А я сталкивался. Любая более-менее сложная платформа содержит малоприятные "особенности".

GZ>Борьба с безопасностью эксплорера. Борьба с Http. Особенно с его текстуальностьюю Открыть файл с длинным русским именем проблема.
Никакой текстуальности в HTTP нет. Что такое "файл с длинным русским именем"? Может быть, кто-то не читал RFC 2046?
GZ>Даже борьба с твоим любимым кэшем.
Это не борьба "с кэшем", а борьба со своим невежеством. На браузерной стороне багов в реализации кэша я не встречал. На серверной — бывали.
GZ>Ну очень он не нужен в SSL.
Это неправда. В SSL кэш по умолчанию отключен. Кроме того, хидеры HTTP по-прежнему рулят.
GZ>И на get'ы в url ставить уникальность задалбывает.
Ну так надо учиться! Разбираться, что такое Cache-Control и что такое Expires. И никакого "ставить уникальность" не понадобится.

GZ>Кривизна заложена в самом WWW. Пытаясь предоставить универсальность, там где ее изначально не было решение настолько усложнили.
Ну и где кривизна?

GZ>Трабла в том, что в Виндах у тебя есть возможность практически полной имплементации с нуля. И достаточно простой способ. В случае Browser — такого нет. Если у тебя целевая платформа IE5, то глядя в хелп по IE7 понимаешь, как много сделать трудно или вообще нельзя. Вот трудно сделать удобный множественный выбор файлов не потеряв чудо деплоинг. Ну хоть убейся.
Один из недостатков HTML. Но, как я уже неоднократно намекал, HTML не единственный язык разметки для веб-приложений.
К примеру, хорошие аплоадилки народ пишет на Flash. А он сейчас имеет 97% покрытие целевой аудитории.

S>>Чем отличаются от них веб-приложения?
S>>Тем, что веб приложение описывает свой GUI на совершенно другом языке. Все остальные положительные черты "обычных" приложений легко переносятся и на веб приложения.
GZ>Нет. Хранение состояние транзакции (уже это обсуждалось). Доступ к ресурсам компьютера. Ну тяжко делать обсчеты графа в IE ограниченный JavaScript и его глюкавой многопоточностью(если его вообще можно назвать многопоточной).
GZ>В результате, из обычного приложения мы имеем только некоторый сложнопрограммируемый UI, и практически все. Остальные проблемы кладем на сервак.
Совершенно верно! Павел вот только что наоборот ругался, что веб приложения сильно много отдают клиенту. Он против даже комбобоксов, а ты хочешь обсчет графа делать в IE. Нахрена? Вон посмотри как гугл мэпс обсчитывает граф при поиске пути из НьюЙорка в Сиэтл — причем размер графа такой, что никакой доступ к ресурсам твоего компьютера тебя бы не спас.
GZ>Ну про недоверие эксплорера и виндов к коду — выполняющемся на нем, я не говорю.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не передергивай. Я же ясно сказал — нет Response в смысле HTTP. А есть просто сокет, который открывает клиент и по которому он делает запрос с сервера данных и получает их.
Ну ответ-то от сервера есть.


PD>Ах, вот ты о чем...

S>>Ок, продолжаем непримиримую борьбу с невежеством.
PD>Этот пассаже тоже на твоей совести оставляю.
Лучше на своей. Это ж не я не понимаю элементарных вещей.

PD>Ну и ну! Боюсь, что теперь мне надо вести борьбу с элементарным нежеланием понять
PD>Вот я вам даю тоже ссылку
PD>http://down6.flashget.com/flashget196en.exe
PD>По этой ссылке с помощью броузера (или аналогичных средств) вам удастся скачать себе некий EXE. После этого запустите этот EXE (инструкцию дать ? , и у вас будет FlashGet, с помощью которого вам в дальнейшем будет легче и удобнее скачивать другие EXE и не только EXE.
FlashGet — неудачный пример. Это приложение в принципе не может быть веб-приложением, потому что у него нет отделяемого состояния. Всё его состояние сводится к списку файлов, недокачанных на локальный компьютер.
PD>Вот и вся инструкция ? Очень сложно ?
Ну, для calc.exe тоже инструкция была бы не очень сложная.
PD>А теперь представь себе, что есть Earth.EXE, который ... в общем то же, что и wikimapia.
Ок, отлично. Жду ссылку на твой адрес в earth.exe.

PD>А теперь давай забудем про EXE. Может, это EXE, может, jar, может еще что-то. Есть линк, по нему заходим, оно скачивается (броузером!) и запускается (но уже без всякого броузера!) И ведет себя как приложение. Собственно говоря, я, юзер, вообще не знаю, web оно или не web. Куда и как и по какому протоколу оно обращается — меня, юзера, не очень интересует.
И как ты дашь ссылку "внутрь" такого приложения? Оно не будет адресуемым. Для вырожденных случаев я ничего не имею против — не нужно делать онлайновый калькулятор; достаточно ссылки на calc.jar.

PD>Кстати, твоя ссылка с wikimapia очень даже показательна. Все там прекрасно, одно непонятно — броузер-то зачем ? Если бы это просто в окне было — чем хуже ?
Тем, что "в окне" ссылка бы не открылась. Может быть, ты не понял? Я дал ссылку не на викимапию. Я дал ссылку на свой дом.


PD>Ненависть — не мой стиль, ненависти я не испытываю. Насчет дефектов конкретных реализаций — не стоит на это списывать. Пока используется броузерная технология — эти самые дефекты конкретных реализаций будут постоянно той отдушиной, на которые ты будешь все списывть.
Да при чем тут браузер! Постбэк и вьюстейт никакого отношения к браузеру не имеют.


S>>Гм. Павел, если мы копнем чуть глубже настольные приложения под Windows, то окажется, что архитектура UI у них построена на Message Queue, GDI и Windowing.
PD>Ты давно это узнал ? Если недавно — поздравляю !
Да, примерно году в 1997.
S>>Листбокс и Листвью — всего лишь тонкие надстройки над этими основами. Поэтому от замены одного на другое, естественно, архитектура никак не поменяется.
PD>Ну слава богу
Ну почему слава-то? Плакать надо! Это же ужасно — мучиться со всеми вот этими корявыми контролами прошлого века.

S>>Чем отличаются от них веб-приложения?
S>>Тем, что веб приложение описывает свой GUI на совершенно другом языке.

PD>Именно. На языке, который изначально не был приспособлен для описания приличного GUI и неспособен к этому до сих пор.
Это я оставляю на твоей совести. Тебя не смущает, что самые передовые технологии описания GUI почему-то переходят к модели, очень похожей на HTML?
Или последнее, что ты освоил на эту тему — это comctl32 версии 4.0?

Здравствуйте, Pavel Dvorkin, Вы писали:

Замечательный пример бреда. Длинный. Попозже подробно откомментирую.

Здравствуйте, artelk, Вы писали:
A>Напрягает, что общение между клиентом и сервером осуществляется в терминах событий представления. Типа: нажали такую-то кнопку, выбрали в комбобоксе другой пункт и т.п. Причем каждый раз с клиента отправляется все состояние представления — viewstate, значения во всех контролах (должен же сервер знать все что содержиться в представлении!.. ). Вся эта страничка воссоздается на сервере, вызывается наконец-то обрабочик этого события, формируется новая страница и отправляется клиенту... Не могу понять, почему это кем-то считаеться правильным?!
Это никем не считается правильным. Учись делать хорошие веб-приложения, а не тяп-ляп-говно.

Здравствуйте, Sinclair, Вы писали:

S>Ну почему слава-то? Плакать надо! Это же ужасно — мучиться со всеми вот этими корявыми контролами прошлого века.

А где примеры прямых и современных контролов?

S>>>Чем отличаются от них веб-приложения?
S>>>Тем, что веб приложение описывает свой GUI на совершенно другом языке.

Эта отличительная черта свойственна не только веб приложениям, но и standalone приложениям. WPF приложения например тоже свой UI описывают на xaml'е. Мы в своих проектах используем самописную библиотеку контролов, которая описывает наш UI в xml файле. Есть еще и HtmlLayout.

Здравствуйте, Mamut, Вы писали:


M>А в каких десктоп приложениях есть подобная функциональность???

Irfan View.


PD>> Это что же за web-приложение такое, которое можно элементарно заставить не работать, поменяв ему настройки без его ведома ?

M>Любое десктоп-приложение будет вести себя похоже, за исключением некоторых примитивных. Предлагаю поупражняться в удалении веток из реестра, например

Нет, не буду. Если его настройки — должно отработать эту ситуацию. Если общесистемные — не его проблема.


M>Да и вообще на любой папке, хранящей данные любого приложения.

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