Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так, стоп. Про AutoPostBack я не говорил, это уже другие добавили. И не в нем, конечно, дело, а в том, что на сервере имеются объекты, никакого отношения к серверу не имеющие, а возникшие исключительно в силу кривого дизайна.
Вот этого момента я не понял. PD>Серверный комбобокс (как и другие элементы) — это действительно runat=server в ASP.NET. Впрочем, с таким же успехом это Select из Tapestry, идеология та же примерно. Я не специалист в web-программировании, но, думаю, найдутся и другие среды с аналогичной идеологией.
Тут надо рассуждать подробнее. На таком уровне непонятно, что именно критикуется.
Поясняю:
Если мы рассуждаем о модели активных элементов (ASP.NET Server Controls), то тут я обеими руками за усекновение головы автора идеи. Конкретно меня не устраивает попытка описать поведение страницы в терминах обработчиков событий у контролов.
Эта вражеская идеология подходит для RAD в Drag-n-Drop стиле. Для написания нормальных приложений она не подходит.
Если же мы рассуждаем о расширениях маркапа, которые позволяют сгенерировать содержимое тега select на основе некоторого источника данных, то я никаких проблем с этим не вижу.
Совершенно нормальная практика. Или сервер должен быть написан в стиле
PD>А впрочем, бог с ним, с комбобоксом. Поставлю вопрос иначе — должен ли сервер знать вообще что-нибудь на предмет того, как выглядит интерфейс пользователя ? Вообще в серверном коде должно быть хоть какое-нибудь упоминание об элементах пользовательского интерфейса ?
Смотря в какой модели. В модели веб приложений — да. Сервер таки должен знать, как выглядит интерфейс пользователя.
Потому что — а кто еще? Клиентское приложение? Откуда оно возьмется на клиентской машине?
Особенность веб-приложений — именно в том, что
а) приложение "развертывается" прямо в момент доступа, прозрачно для пользователя
б) приложение размазано по нескольким независимым компонентам.
Рассмотрим эти особенности повнимательнее. Вот, к примеру, пользователь набирает в браузере maps.google.com.
Благодаря а) у него на машине волшебным образом образуется замечательный клиент, который умеет обращаться к картографическому сервису гугла. Этот клиент конечно ограничен по своим возможностям, но большинство существующих, к примеру, Delphi приложений не дотягивают до его функционала на века.
Опять же благодаря а) гуглу не нужно заниматься раздачей "автоматических апдейтов". Изменения в сервисе автоматически синхронизуются с изменениями в клиенте.
Благодаря б) у нас есть возможность вносить локальные изменеия. Страница А перестала работать? Ничего, зато страницы Б и В работоспособны. Нет четкой границы между разными приложениями, и отдельное приложение тоже не монолит.
PD>Или все же лучше, если сервер будет работать только как документ, а пользовательским интерфейсом будет заниматься исключительно вид в рамках старой доброй архитектуры "документ-вид" ? ИМХО лучше.
И кто будет этим "видом"?
PD>И вообще, в чем, собственно, специфика web-приложений, если отвлечься от их текущего состояния ? В чем их отличие от десктопных ? PD> Только в том, что между юзером и сервером сотни километров ? Так это не самое главное, сейчас. Почему для десктопного приложения одна архитектура , а здесь иная, причем кривая ?
Всё как раз наоборот. Веб приложения совершенно необязательно расположены за сотни километров от сервера.
Архитектура веб приложений гораздо прямее, чем архитектура т.н. "клиент-серверных". Десктопные приложения (типа calc.exe) я вообще не рассматриваю. Их архитектура меня совершенно не интересует — там, где нет распределенного состояния, ничего интересного не происходит.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
PD>>А впрочем, бог с ним, с комбобоксом. Поставлю вопрос иначе — должен ли сервер знать вообще что-нибудь на предмет того, как выглядит интерфейс пользователя ? Вообще в серверном коде должно быть хоть какое-нибудь упоминание об элементах пользовательского интерфейса ? S>Смотря в какой модели. В модели веб приложений — да. Сервер таки должен знать, как выглядит интерфейс пользователя.
Нет. Задача сервера: принять данные от клиента, проверить и обработать их согласно неким правилам, отдать новые данные клиенту. Задача клиента: запросить данные у сервера, принять и отобразить их, принять данные от пользователя и отправить их серверу. Всё, что они знают друг о друге — это протокол обмена данными, и ещё клиент знает URL точки доступа на сервере. Но тут есть важный момент: клиентское приложение, как целиком, так и по частям, предоставляет пользователю сам сервер, причём не обязательно тот же самый, что и обрабатывает данные.
S>Рассмотрим эти особенности повнимательнее. Вот, к примеру, пользователь набирает в браузере maps.google.com.
Взять тот же Google Maps. Серверу абсолютно всё равно, что происходит на клиенте. Его задача на запрос: "Дайте картинку для координат таких-то," — ответить: "Нате получите" или "Нет такой картинки". А уж что там потом с картинками происходит, это исключительно на совести клиента.
Здравствуйте, anonymous, Вы писали: S>>Смотря в какой модели. В модели веб приложений — да. Сервер таки должен знать, как выглядит интерфейс пользователя. A>Нет. Задача сервера: принять данные от клиента, проверить и обработать их согласно неким правилам, отдать новые данные клиенту. Задача клиента: запросить данные у сервера, принять и отобразить их, принять данные от пользователя и отправить их серверу. Всё, что они знают друг о друге — это протокол обмена данными, и ещё клиент знает URL точки доступа на сервере. Но тут есть важный момент: клиентское приложение, как целиком, так и по частям, предоставляет пользователю сам сервер, причём не обязательно тот же самый, что и обрабатывает данные.
В целом да. Я имел в виду, что очень часто (правда, всё реже), сервер отдает клиенту приложение вместе с данными.
Вот смотри:
<form>
<label for="title">Заголовок:</label></br>
<input type=text name="title" value="Заголовок"></br>
<label for="body">Тело:</label></br>
<textarea name="body">
А тут такое тело данных лежит себе промеж разметки.
</textarea>
<input name=go type=submit value="Поехали!">
</form>
Здесь у нас сервер отдал и данные, и описание микроклиента, который их
а) покажет
б) позволит поредактировать
в) отправит измененные данные на сервер.
A>Взять тот же Google Maps. Серверу абсолютно всё равно, что происходит на клиенте.
Ну как тебе сказать. Давай посмотрим в трафик:
//пошло скачивание клиента:
GET http://maps.google.com/
GET http://maps.google.com/intl/en_ALL/mapfiles/103/maps2.css
GET http://www.google.com/intl/en_ALL/images/maps_results_logo.gif
GET http://maps.google.com/mapfiles/home3.html
GET http://maps.google.com/mapfiles/hpimgs.png
GET http://maps.google.com/intl/en_ALL/mapfiles/103/maps2/main.js
GET http://maps.google.com/maps/vp?spn=51.887315,81.738281&z=4&vp=37.0625,-95.677068
GET http://maps.google.com/intl/en_ALL/mapfiles/103/maps2/mod_addressbook.js
GET http://maps.google.com/intl/en_ALL/mapfiles/103/maps2/mod_traffic_app.js
GET http://maps.google.com/intl/en_ALL/mapfiles/103/maps2/mod_cb.js
// клиент скачался, пошел за данными:
GET http://mt1.google.com/mt?n=404&v=w2.69&hl=en&x=3&y=6&zoom=13&s=Galileo
GET http://mt0.google.com/mt?n=404&v=w2.69&hl=en&x=3&y=5&zoom=13&s=Galile
GET http://mt2.google.com/mt?n=404&v=w2.69&hl=en&x=4&y=6&zoom=13&s=Ga
GET http://mt1.google.com/mt?n=404&v=w2.69&hl=en&x=4&y=5&zoom=13&s=G
GET http://mt0.google.com/mt?n=404&v=w2.69&hl=en&x=2&y=6&zoom=13&s=Gali
GET http://mt2.google.com/mt?n=404&v=w2.69&hl=en&x=3&y=7&zoom=13&s=
GET http://mt3.google.com/mt?n=404&v=w2.69&hl=en&x=2&y=5&zoom=13&s=Gal
GET http://mt3.google.com/mt?n=404&v=w2.69&hl=en&x=4&y=7&zoom=13&s=Gal
GET http://mt3.google.com/mt?n=404&v=w2.69&hl=en&x=3&y=4&zoom=13&s=Galil
GET http://mt3.google.com/mt?n=404&v=w2.69&hl=en&x=5&y=6&zoom=13&s=Galil
GET http://mt1.google.com/mt?n=404&v=w2.69&hl=en&x=2&y=7&zoom=13&s=Galil
GET http://mt0.google.com/mt?n=404&v=w2.69&hl=en&x=4&y=4&zoom=13&s=
GET http://mt2.google.com/mt?n=404&v=w2.69&hl=en&x=5&y=5&zoom=13&s=Gali
GET http://mt2.google.com/mt?n=404&v=w2.69&hl=en&x=2&y=4&zoom=13&s=Ga
GET http://mt0.google.com/mt?n=404&v=w2.69&hl=en&x=5&y=7&zoom=13&s=Galile
GET http://mt3.google.com/mt?n=404&v=w2.69&hl=en&x=1&y=6&zoom=13&s=G
GET http://mt3.google.com/mt?n=404&v=w2.69&hl=en&x=3&y=8&zoom=13&s=G
GET http://mt2.google.com/mt?n=404&v=w2.69&hl=en&x=1&y=5&zoom=13&s=
GET http://mt0.google.com/mt?n=404&v=w2.69&hl=en&x=4&y=8&zoom=13&s=Gali
GET http://mt1.google.com/mt?n=404&v=w2.69&hl=en&x=5&y=4&zoom=13&s=Gal
GET http://mt0.google.com/mt?n=404&v=w2.69&hl=en&x=1&y=7&zoom=13&s=Ga
GET http://mt2.google.com/mt?n=404&v=w2.69&hl=en&x=2&y=8&zoom=13&s=Galile
GET http://mt0.google.com/mt?n=404&v=w2.69&hl=en&x=6&y=6&zoom=13&s=
GET http://mt1.google.com/mt?n=404&v=w2.69&hl=en&x=1&y=4&zoom=13&s=Galileo
GET http://mt3.google.com/mt?n=404&v=w2.69&hl=en&x=6&y=5&zoom=13&s=Galileo
GET http://mt1.google.com/mt?n=404&v=w2.69&hl=en&x=5&y=8&zoom=13&s=Galileo
GET http://mt1.google.com/mt?n=404&v=w2.69&hl=en&x=6&y=7&zoom=13&s=G
GET http://mt1.google.com/mt?n=404&v=w2.69&hl=en&x=1&y=8&zoom=13&s=Gal
GET http://mt2.google.com/mt?n=404&v=w2.69&hl=en&x=6&y=4&zoom=13&s=Galile
GET http://mt2.google.com/mt?n=404&v=w2.69&hl=en&x=6&y=8&zoom=13&s=Ga
// догружаем клиента
GET http://www.google.com/verify/EAAAAP_ZEUzvBuZr4EDfrqHLBTU.gif
GET http://maps.google.com/intl/en_ALL/mapfiles/103/maps2/mod_ms.js
GET http://maps.google.com/intl/en_ALL/mapfiles/103/maps2/mod_kml.js
GET http://maps.google.com/intl/en_ALL/mapfiles/103/maps2/mod_mpl_host.js
GET http://maps.google.com/intl/en_ALL/mapfiles/103/maps2/mod_mymaps.js
A>Его задача на запрос: "Дайте картинку для координат таких-то," — ответить: "Нате получите" или "Нет такой картинки". А уж что там потом с картинками происходит, это исключительно на совести клиента.
Как видим, веб приложение Google Maps не ограничивается "отдачей картинки". То, о чем ты говоришь — это веб сервис.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, anonymous, Вы писали:
A>Нет. Задача сервера: принять данные от клиента, проверить и обработать их согласно неким правилам, отдать новые данные клиенту. Задача клиента: запросить данные у сервера, принять и отобразить их, принять данные от пользователя и отправить их серверу. Всё, что они знают друг о друге — это протокол обмена данными, и ещё клиент знает URL точки доступа на сервере.
Сказки это все красивые. На практике все равно серверный интерфейс будет зависеть от клиентского UI. Если у нас десктопный грид — нужны кейсеты с динамической подкачкой или что то наподобие, если грид вебовский — нужен пейджинг, если есть какой то интеллисенс — для этого нужна отдельная специфичная точка входа, если комбобокс — нужны данные для лукапа, если есть полнотекстовый поиск — нужна соотв. дырка на сервере. Ну и так далее.
Поэтому изоляция клиентозависимого кода конечно должна быть, но она должна быть логической, по слоям, а не физической, по звеньям.
S>>Рассмотрим эти особенности повнимательнее. Вот, к примеру, пользователь набирает в браузере maps.google.com.
A>Взять тот же Google Maps. Серверу абсолютно всё равно, что происходит на клиенте. Его задача на запрос: "Дайте картинку для координат таких-то," — ответить: "Нате получите" или "Нет такой картинки".
Что то мне подказывает, что для Google Earth используется немножко другой сервис
... << RSDN@Home 1 alpha 3 rev. 0 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кстати. Не знаю, что такое TreeTables, но вроде бы в .Net 2.0 впервые появилося treeview в ASP.NET. Родили, наконец. До этого всякие разработки третьих фирм использовали, с теми или иными багами. Между тем в Win32 этот treview существует по крайней мере с 1995 года, а то как бы и не раньше (не помню, был он в NT 3.51 или нет).
TreeTables — таблица (с прокруткой если длинная) где первый столбец — дерево.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Так, стоп. Про AutoPostBack я не говорил, это уже другие добавили. И не в нем, конечно, дело, а в том, что на сервере имеются объекты, никакого отношения к серверу не имеющие, а возникшие исключительно в силу кривого дизайна. S>Вот этого момента я не понял.
Я просто сказал, что про AutoPostBack я не говориЛ. а критиковал подход в целом на примере комбика.
S>Если мы рассуждаем о модели активных элементов (ASP.NET Server Controls), то тут я обеими руками за усекновение головы автора идеи. Конкретно меня не устраивает попытка описать поведение страницы в терминах обработчиков событий у контролов.
А само наличие серверных элементов управления устраивает ? То есть если бы они были, но все обработчики стояли, скажем, на JS — это бы устроило ?
S>Если же мы рассуждаем о расширениях маркапа, которые позволяют сгенерировать содержимое тега select на основе некоторого источника данных, то я никаких проблем с этим не вижу. S>Совершенно нормальная практика. Или сервер должен быть написан в стиле S>
А ты не задумывался, что здесь вообще не нужен никакой Response ?
string[] values = Client.getValuesForCombo(Server); // вот тут запрос к серверу
Client.Form.Combo.Fill(values);
и все. Нет ответа от сервера в обычном понимании слова (Response). Потому что нет и перегрузки страницы. Потому что и страницы нет. Есть состояние клиентской программы, которое этими строчками меняется
Сравни
string[] values = Client.getValuesForCombo(Document); // обращение куда-то к документу на клиентской же машине
Form.Combo.Fill(values);
Никакого отличия по существу. И не должно его быть.
S>Смотря в какой модели. В модели веб приложений — да. Сервер таки должен знать, как выглядит интерфейс пользователя.
Вообще-то общепринято разделение вида и данных. И документ не должен знать, как выглядит вид.
S>Потому что — а кто еще? Клиентское приложение? Откуда оно возьмется на клиентской машине?
А вот это другой вопрос. В рамках нынешней архитектуры web-приложений — верно, неоткуда. А вот если ее полностью отринуть и продумать все с начала как следует — придумаем, откуда ему взяться
Мои исходный пост как раз и был о том, что нынешняя архитектура кривая.
S>Особенность веб-приложений — именно в том, что S>а) приложение "развертывается" прямо в момент доступа, прозрачно для пользователя
И бога ради
S>б) приложение размазано по нескольким независимым компонентам.
Это требует конкретизации. С высоты птичьего полета здесь 2 компоненты — клиент и сервер. И как именно оно размазано между ними — можно и так решить и иначе. Если с нуля решать проблему.
S>Рассмотрим эти особенности повнимательнее. Вот, к примеру, пользователь набирает в браузере maps.google.com.
<skiiped>
Обсуждать не буду, так как я исходно считаю, что для приложений броузеру делать нечего.
PD>>Или все же лучше, если сервер будет работать только как документ, а пользовательским интерфейсом будет заниматься исключительно вид в рамках старой доброй архитектуры "документ-вид" ? ИМХО лучше. S>И кто будет этим "видом"?
Опять таки в рамках нынешней врхитектуры ответа нет. А вообще — просто некий код с UI (Java ?) на клиенте
S>Архитектура веб приложений гораздо прямее, чем архитектура т.н. "клиент-серверных". Десктопные приложения (типа calc.exe) я вообще не рассматриваю. Их архитектура меня совершенно не интересует — там, где нет распределенного состояния, ничего интересного не происходит.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>А само наличие серверных элементов управления устраивает ? То есть если бы они были, но все обработчики стояли, скажем, на JS — это бы устроило ?
Да, устроило бы, я же сказал.
PD>А ты не задумывался, что здесь вообще не нужен никакой Response ?
Я-то обо всём задумывался.
PD>string[] values = Client.getValuesForCombo(Server); // вот тут запрос к серверу PD>Client.Form.Combo.Fill(values);
PD>и все. Нет ответа от сервера в обычном понимании слова (Response).
Вообще-то, Response здесь один хрен присутствует. Потому что какие-то values for combo таки приезжают. PD>Потому что нет и перегрузки страницы. Потому что и страницы нет. Есть состояние клиентской программы, которое этими строчками меняется
Ничему не противоречит. PD>Никакого отличия по существу. И не должно его быть.
И нету его. Рекомендую посмотреть на то, каким образом функционирует google suggest. Ровно комбобокс, и ровно данными с сервера.
S>>Смотря в какой модели. В модели веб приложений — да. Сервер таки должен знать, как выглядит интерфейс пользователя. PD>Вообще-то общепринято разделение вида и данных. И документ не должен знать, как выглядит вид.
Павел, не нужно сводить "приложение" к коду на сишарпе. Посмотри на maps.google.com — они работают именно так, как ты написал. Только лучше.
PD>А вот это другой вопрос. В рамках нынешней архитектуры web-приложений — верно, неоткуда.
Вот как раз в нынешней модели веб-приложений всё уже придумано — приложение приезжает по тому же протоколу. И пользуется всеми преимуществами протокола. PD>А вот если ее полностью отринуть и продумать все с начала как следует — придумаем, откуда ему взяться PD>Мои исходный пост как раз и был о том, что нынешняя архитектура кривая.
Павел, нынешняя архитектура как раз мегаправильная.
Зачем изобретать кривобокий велосипед, искусственно противопоставляя приложение и его данные?
S>>б) приложение размазано по нескольким независимым компонентам. PD>Это требует конкретизации. С высоты птичьего полета здесь 2 компоненты — клиент и сервер. И как именно оно размазано между ними — можно и так решить и иначе. Если с нуля решать проблему.
Павел, проблема решена примерно в 1995 году.
S>>Рассмотрим эти особенности повнимательнее. Вот, к примеру, пользователь набирает в браузере maps.google.com.
PD><skiiped>
PD>Обсуждать не буду, так как я исходно считаю, что для приложений броузеру делать нечего.
А кому есть чего? Надо отдельно покупать диск с приложением? PD>Опять таки в рамках нынешней врхитектуры ответа нет.
Павел, в рамках нынешней архитектуры есть ответы на всё это. Просто нужно немножко поизучать тему, перед тем как пытаться полить ее помоями. PD> А вообще — просто некий код с UI (Java ?) на клиенте
А почему, собственно, Java? Почему не JavaScript? Почему не ActiveScript? Почему не MSIL?
Неужели для того, чтобы архитектура стала "некривой", нужно непременно рисовать контролы при помощи устаревших на 20 лет "виджетов" и "графических примитивов"?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>В целом да. Я имел в виду, что очень часто (правда, всё реже), сервер отдает клиенту приложение вместе с данными. S>Вот смотри: S>[...] S>Здесь у нас сервер отдал и данные, и описание микроклиента, который их S>а) покажет S>б) позволит поредактировать S>в) отправит измененные данные на сервер.
Этот кусок кода — обычная страница веб-сайта. Можно конечно так писать веб-приложения, но зачем? Зачем смешивать в кучу данные и код (в данном случае UI-разметку) приложения? Да, сервер может отдать именно такой кусок приложения, но в этом случае он действительно должен знать как выглядит UI, потому что он же его и заполняет данными — это устаревший подход, атавизм, доставшийся от веб-сайтов. Идеальной (более правильной) мне кажется ситуация, когда клиент сам запрашивает "чистые" данные и сам раскладывает их по UI. Как ты верно заметил ниже, сервер должен выполнять лишь функции веб-сервиса. Ну и клиента он (или кто-то другой) ещё должен полностью или по частям отдавать.
A>>Взять тот же Google Maps. Серверу абсолютно всё равно, что происходит на клиенте. S>Ну как тебе сказать. Давай посмотрим в трафик: S>[...] S>//пошло скачивание клиента: S>// клиент скачался, пошел за данными: S>// догружаем клиента A>>Его задача на запрос: "Дайте картинку для координат таких-то," — ответить: "Нате получите" или "Нет такой картинки". А уж что там потом с картинками происходит, это исключительно на совести клиента. S>Как видим, веб приложение Google Maps не ограничивается "отдачей картинки".
Не понял этого примера, в чём противоречие с моими словами? Сразу предупреждаю, я не изучал работу именно Google Maps, это было моё предположение, основанное на моём видении веб-приложений.
S>То, о чем ты говоришь — это веб сервис.
А это и должен быть веб-сервис, веб-приложение должно состоять из клиента в браузере и веб-сервиса.
Здравствуйте, AndrewVK, Вы писали:
A>>Нет. Задача сервера: принять данные от клиента, проверить и обработать их согласно неким правилам, отдать новые данные клиенту. Задача клиента: запросить данные у сервера, принять и отобразить их, принять данные от пользователя и отправить их серверу. Всё, что они знают друг о друге — это протокол обмена данными, и ещё клиент знает URL точки доступа на сервере. AVK>Сказки это все красивые. На практике все равно серверный интерфейс будет зависеть от клиентского UI. Если у нас десктопный грид — нужны кейсеты с динамической подкачкой или что то наподобие, если грид вебовский — нужен пейджинг, если есть какой то интеллисенс — для этого нужна отдельная специфичная точка входа, если комбобокс — нужны данные для лукапа, если есть полнотекстовый поиск — нужна соотв. дырка на сервере. Ну и так далее. AVK>Поэтому изоляция клиентозависимого кода конечно должна быть, но она должна быть логической, по слоям, а не физической, по звеньям.
"Мы рождены, чтоб сказку сделать былью." (: Вот скажи мне зачем серверу знать, с какой целью клиент запросил записи с 25 по 36? Может он в грид при прокрутке из хочет добавить, а может на основе введённых пользователем данных, он вычислил, что тому нужны именно эти записи, а может?.. Ну и какое дело серверу до этого? У него совершенно другие заботы, клиент сам разберётся, что ему сделать с полученными данными.
А точка входа может быть вообще одна, вон Janus так работает. Это конечно не наш пример, но мой опыт подсказывает мне, что не сложно будет написать приложение, общающееся с сервером по SOAP посредством XmlHttpRequest. Более того, я это делал. (:
A>>Взять тот же Google Maps. Серверу абсолютно всё равно, что происходит на клиенте. Его задача на запрос: "Дайте картинку для координат таких-то," — ответить: "Нате получите" или "Нет такой картинки". AVK>Что то мне подказывает, что для Google Earth используется немножко другой сервис
Здравствуйте, anonymous, Вы писали:
A>Этот кусок кода — обычная страница веб-сайта. Можно конечно так писать веб-приложения, но зачем? Зачем смешивать в кучу данные и код (в данном случае UI-разметку) приложения?
Затем, что это иногда может дать преимущества в производительности. A> Да, сервер может отдать именно такой кусок приложения, но в этом случае он действительно должен знать как выглядит UI, потому что он же его и заполняет данными — это устаревший подход, атавизм, доставшийся от веб-сайтов.
Ну, я бы не спешил записывать это в атавизмы. Есть всё еще масса случаев, когда красивое разделение между данными и UI может быть произведено по ту сторону HTTP, и это даст определенные преимущества.
A>Идеальной (более правильной) мне кажется ситуация, когда клиент сам запрашивает "чистые" данные и сам раскладывает их по UI.
Ключевое слово здесь — "кажется". Такая ситуация может иметь место, и собственно могучесть архитектуры проявляется в том, что никаких проблем с такой реализацией в веб-приложениях нет (чего бы там ни думал Павел). Но идеальность и правильность в вакууме не существуют. Всегда есть некоторая реальность, и только для конкретной задачи можно сказать, что будет идеальной реализацией, а что — неидеальной. A>Как ты верно заметил ниже, сервер должен выполнять лишь функции веб-сервиса. Ну и клиента он (или кто-то другой) ещё должен полностью или по частям отдавать.
Не вижу нужды что-то запрещать серверу. S>>Как видим, веб приложение Google Maps не ограничивается "отдачей картинки".
A>Не понял этого примера, в чём противоречие с моими словами?
В том, что ты почему-то игнорируешь веб-приложение, а рассматриваешь исключительно веб-сервисы.
На всякий случай напомню, что сервисы людьми напрямую не потребляются. Для того, чтобы пользователь мог извлечь радость из сервиса, ему нужно провзаимодействовать с приложением.
Как уже упомянул AndrewVK, наивно полагать, что к любому осмысленному сервису можно написать удобное приложение.
Всё как раз наоборот — UI приложения диктует функциональные требования для сервиса.
A>Сразу предупреждаю, я не изучал работу именно Google Maps, это было моё предположение, основанное на моём видении веб-приложений.
S>>То, о чем ты говоришь — это веб сервис.
A>А это и должен быть веб-сервис, веб-приложение должно состоять из клиента в браузере и веб-сервиса.
Ок, это означает, что как минимум та часть приложения, которая отвечает за клиента в браузере, таки должна знать, как он выглядит.
А веб-сервис при этом должен обеспечивать функции, которые помогают клиенту продемонстрировать нужное поведение.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, anonymous, Вы писали:
A>Вот скажи мне зачем серверу знать, с какой целью клиент запросил записи с 25 по 36?
Затем, например, чтобы правильно выбрать стратегию кеширования.
A>Ну и какое дело серверу до этого?
Простое. Ему наждо обеспечить:
а) Минимально возможный контракт. Т.е. никаких методов "на всякий случай" в контракте быть не должно
б) Минимально возможное время отклика.
A> У него совершенно другие заботы, клиент сам разберётся, что ему сделать с полученными данными.
Прежде чем клиент начнет разбипраться, ему надо получить те, и только те данные, что ему нужны. Вот есть у тебя метод, возвращающий для сущности Person поля A, B и C. Теперь у тебя появилась формочка, где нужны только B и C. Что, все равно будем доставать из БД и гонять по сети C, несмотря на то, что оно не нужно?
Ок, теперь нам понадобилась еще одна формочка, в которой нужно еще и D. Будем добавлять в существующий метод D?
A>А точка входа может быть вообще одна, вон Janus так работает.
Тебе Антон уже сказал — Janus это не веб-приложение. Но и тут его веб-сервис заточен именно под модель януса (да еще и под конкретную версию его архитектуры). А для NNTP уже совсем другой сервис.
AVK>>Что то мне подказывает, что для Google Earth используется немножко другой сервис
A>Google Earth немножко другое приложение.
Наоборот, прекрасный пример. Google Earth и Google Maps работают с примерно одними и теми же данными, отличается только клиентская часть.
... << RSDN@Home 1.2.0 alpha 4 rev. 995 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Sinclair, Вы писали:
A>>Этот кусок кода — обычная страница веб-сайта. Можно конечно так писать веб-приложения, но зачем? Зачем смешивать в кучу данные и код (в данном случае UI-разметку) приложения? S>Затем, что это иногда может дать преимущества в производительности. A>> Да, сервер может отдать именно такой кусок приложения, но в этом случае он действительно должен знать как выглядит UI, потому что он же его и заполняет данными — это устаревший подход, атавизм, доставшийся от веб-сайтов. S>Ну, я бы не спешил записывать это в атавизмы. Есть всё еще масса случаев, когда красивое разделение между данными и UI может быть произведено по ту сторону HTTP, и это даст определенные преимущества.
Да, но только эти "определённые преимущества" мы получим в обмен на вполне конкретное преимущество незнания сервера о клиенте. И вместо того, чтобы знать только об интерфейсе взаимодействия с клиентом, серверу нужно будет знать и его внутренее устройство. Можно сказать, что в данном случае нарушается свойство инкапсуляции клиента. (:
A>>Идеальной (более правильной) мне кажется ситуация, когда клиент сам запрашивает "чистые" данные и сам раскладывает их по UI. S>Ключевое слово здесь — "кажется". Такая ситуация может иметь место, и собственно могучесть архитектуры проявляется в том, что никаких проблем с такой реализацией в веб-приложениях нет (чего бы там ни думал Павел). Но идеальность и правильность в вакууме не существуют. Всегда есть некоторая реальность, и только для конкретной задачи можно сказать, что будет идеальной реализацией, а что — неидеальной.
Да, безусловно, при создании веб-приложения необходимо учитывать в том числе и вопросы производительности, и в случае необходимости отступать от идеала. С производительностью, кстати, вопрос тоже неоднозначный. Если вычисления просты, то лучше переложить их на клиента, разгрузив тем самым сервер, а раскладка данных по контролам — обычно не сильно сложная операция. С точки зрения же разработки, мы можем поручить работу над клиентом и сервером совершенно разным командам, что также есть плюс.
Всё же предлагаю обсуждать именно идеальный случай, иначе мы скатимся на обсуждение огромного количества частностей. Так и нормализацией БД — практика показывает, что нормализованная БД далеко не всегда подходит для использования в реальных проектах, но это не повод говорить, что нормализация и реальность несовместимы.
A>>Как ты верно заметил ниже, сервер должен выполнять лишь функции веб-сервиса. Ну и клиента он (или кто-то другой) ещё должен полностью или по частям отдавать. S>Не вижу нужды что-то запрещать серверу.
Это весьма субъективное замечание. Не могу с ним спорить.
S>>>Как видим, веб приложение Google Maps не ограничивается "отдачей картинки". A>>Не понял этого примера, в чём противоречие с моими словами? S>В том, что ты почему-то игнорируешь веб-приложение, а рассматриваешь исключительно веб-сервисы.
Э нет, для меня веб-приложение есть сервер (может как веб-вервис) и клиент вместе.
S>На всякий случай напомню, что сервисы людьми напрямую не потребляются. Для того, чтобы пользователь мог извлечь радость из сервиса, ему нужно провзаимодействовать с приложением. S>Как уже упомянул AndrewVK, наивно полагать, что к любому осмысленному сервису можно написать удобное приложение.
Рискну заметить, что удобность приложения вообще никак (одно исключение ниже) не зависит от сервиса, а зависит исключительно от умений юзабилиста. Программирование тут не при чём. Разве что оно повлияет на скорость работы, а это критерий юзабилити — единственный, на который тут как-то можно повлиять.
S>Всё как раз наоборот — UI приложения диктует функциональные требования для сервиса.
Нет. См. выше. Если мы конечно не говорим об удобстве разработчика.
A>>А это и должен быть веб-сервис, веб-приложение должно состоять из клиента в браузере и веб-сервиса. S>Ок, это означает, что как минимум та часть приложения, которая отвечает за клиента в браузере, таки должна знать, как он выглядит.
Клиент по определению знает как он сам выглядит изнутри и снаружи. Или ты что-то другое имел ввиду?
S>А веб-сервис при этом должен обеспечивать функции, которые помогают клиенту продемонстрировать нужное поведение.
А это уже вопрос к разработчикам интерфейса взаимодействия клиента и сервиса. Опять же, в общем случае знания о внутреннем устройстве как сервера так и клиента тут не нужны. ООП в аналогию.
A>>Вот скажи мне зачем серверу знать, с какой целью клиент запросил записи с 25 по 36? AVK>Затем, например, чтобы правильно выбрать стратегию кеширования. A>>Ну и какое дело серверу до этого? AVK>Простое. Ему наждо обеспечить: AVK>а) Минимально возможный контракт. Т.е. никаких методов "на всякий случай" в контракте быть не должно AVK>б) Минимально возможное время отклика. A>> У него совершенно другие заботы, клиент сам разберётся, что ему сделать с полученными данными. AVK>Прежде чем клиент начнет разбипраться, ему надо получить те, и только те данные, что ему нужны. Вот есть у тебя метод, возвращающий для сущности Person поля A, B и C. Теперь у тебя появилась формочка, где нужны только B и C. Что, все равно будем доставать из БД и гонять по сети C, несмотря на то, что оно не нужно? AVK>Ок, теперь нам понадобилась еще одна формочка, в которой нужно еще и D. Будем добавлять в существующий метод D?
Вот и скатились на частности. Ну хорошо, придумаю я тебе самый общий метод getObjectFields(objectClass, objectId, [objectFields]) => [objectValues]. Сервер при этом достаёт весь объект и кеширует его, не будем обсуждать как, всё отработано давно до мелочей. А клиент берёт какие хочет поля, для каких угодно своих нужд. Кеширование на клиенте не запрещено. Запрет на избыточность данных искуственен. Ещё пример придумаешь?
A>>А точка входа может быть вообще одна, вон Janus так работает. AVK>Тебе Антон уже сказал — Janus это не веб-приложение. Но и тут его веб-сервис заточен именно под модель януса (да еще и под конкретную версию его архитектуры). А для NNTP уже совсем другой сервис.
Я между прочим то же самое сказал. Я так же упомянул, что писал веб-приложение работающее с сервисом Janus'а. А также я написал, что интерфейс взаимодействия обсуждаем.
AVK>>>Что то мне подказывает, что для Google Earth используется немножко другой сервис A>>Google Earth немножко другое приложение. AVK>Наоборот, прекрасный пример.
Janus значит не прекрасный пример, а это прекрасный?
Здравствуйте, anonymous, Вы писали:
A>Вот и скатились на частности.
А черт, он как раз в деталях.
A> Ну хорошо, придумаю я тебе самый общий метод getObjectFields(objectClass, objectId, [objectFields]) => [objectValues].
Так в том и дело, что не надо такого метода придумывать.
A>Запрет на избыточность данных искуственен.
Нифига себе исскуственен. Увеличение объема считываемых с диска данных и увеличение сетевого трафика -> увеличение времени отклика по твоему исскусственное ограничение? Ну тогда дальше, наверное, разговаривать уже не о чем.
A> Ещё пример придумаешь?
Этого достаточно.
A>Я между прочим то же самое сказал. Я так же упомянул, что писал веб-приложение работающее с сервисом Janus'а.
Ага, но показать его постеснялся Понимаешь, в чудеса человеческой изворотливости я тоже верю. Но оптимальное решение будет другим. Вопрос в выборе баланса между оптимальностью и универсальностью. Так вот — в случае сетевого взаимодействия и БД все еще оптимальность сильно важнее, потому что именно эти моменты скорее всего будут являться бутылочными горлышками.
AVK>>Наоборот, прекрасный пример.
A>Janus значит не прекрасный пример
Janus тоже прекрасный — его веб-сервис заточен исключительно под него самого. Это я тебе как автор говорю.
... << RSDN@Home 1.2.0 alpha 4 rev. 995 on Windows Vista 6.0.6001.65536>>
Здравствуйте, anonymous, Вы писали:
определенные преимущества.
A>Да, но только эти "определённые преимущества" мы получим в обмен на вполне конкретное преимущество незнания сервера о клиенте. И вместо того, чтобы знать только об интерфейсе взаимодействия с клиентом, серверу нужно будет знать и его внутренее устройство. Можно сказать, что в данном случае нарушается свойство инкапсуляции клиента. (:
Ну, в таком случае мы плавно переходим к вопросу о способах проектирования веб сервисов.
Существующая архитектура веб приложений удовлетворяет всем требованиям. Хочешь инкапсулированного клиента — вот тебе инкапсулированный клиент.
Хочешь комбинированный сервер с клиентом — вот тебе комбинированный сервер с клиентом.
Да, современные веб-приложения как правило выигрывают от разделения сервиса и клиентской части.
A>Да, безусловно, при создании веб-приложения необходимо учитывать в том числе и вопросы производительности, и в случае необходимости отступать от идеала. С производительностью, кстати, вопрос тоже неоднозначный. Если вычисления просты, то лучше переложить их на клиента, разгрузив тем самым сервер, а раскладка данных по контролам — обычно не сильно сложная операция. С точки зрения же разработки, мы можем поручить работу над клиентом и сервером совершенно разным командам, что также есть плюс.
Вообще-то разделение работы над клиентом и сервером никак не связано с местом проведения границы между ними. Вполне типичным является случай, когда веб-приложение целиком живет на стороне сервера, но реальные данные поставляет сервис, невидимый снаружи.
В частности, такая архитектура позволяет, к примеру, разделять контексты безопасности. Сервис, к примеру, работает с привилегированным клиентом и полагается на то, что политики доступа для конкретных пользователей определяет именно клиент.
В случае, если сервис торчит "наружу", полагаться на это нельзя — все обращения выполняются от имени конечного пользователя. Это усложняет сервис.
A>Всё же предлагаю обсуждать именно идеальный случай, иначе мы скатимся на обсуждение огромного количества частностей. Так и нормализацией БД — практика показывает, что нормализованная БД далеко не всегда подходит для использования в реальных проектах, но это не повод говорить, что нормализация и реальность несовместимы.
Также это не повод и говорить о том, что идеальная БД должна быть в какой-то из нормальных форм, а всё остальное — досадное отступление от идеала.
S>>>>Как видим, веб приложение Google Maps не ограничивается "отдачей картинки". A>>>Не понял этого примера, в чём противоречие с моими словами? S>>В том, что ты почему-то игнорируешь веб-приложение, а рассматриваешь исключительно веб-сервисы. A>Э нет, для меня веб-приложение есть сервер (может как веб-вервис) и клиент вместе.
Я предпочитаю трактовать термин "сервер" в контексте веб приложений именно как HTTP сервер. Поскольку он занимается также и отдачей клиента, его всё же интересует то, как будет выглядеть приложение для пользователя.
A>Рискну заметить, что удобность приложения вообще никак (одно исключение ниже) не зависит от сервиса, а зависит исключительно от умений юзабилиста. A>Программирование тут не при чём. Разве что оно повлияет на скорость работы, а это критерий юзабилити — единственный, на который тут как-то можно повлиять.
Ну, вот в Google Design Guidelines скорость отклика идет номером 2 из 10.
Я не представляю себе, как проектировать приложение, которое пренебрегает такими вещами. Поскольку мы говорим о распределенных приложениях, формат API сервиса является критически важным для успеха. В частности, поддержку постраничного доступа невозможно эмулировать. S>>Всё как раз наоборот — UI приложения диктует функциональные требования для сервиса. A>Нет. См. выше. Если мы конечно не говорим об удобстве разработчика.
Нет, мы говорим о реальных приложениях. Если нужен комбобокс — значит, должен быть метод, который возвращает для него значения. Если комбобокса нет — то и метод не нужен. Это неочевидно?
A>>>А это и должен быть веб-сервис, веб-приложение должно состоять из клиента в браузере и веб-сервиса. S>>Ок, это означает, что как минимум та часть приложения, которая отвечает за клиента в браузере, таки должна знать, как он выглядит. A>Клиент по определению знает как он сам выглядит изнутри и снаружи. Или ты что-то другое имел ввиду?
В веб приложениях клиент не существует сам по себе. Он возникает как результат работы сервера, в ответ на определенный http запрос.
Возьмем самое простое веб-приложение: http:/google.com.
Клиент — это та страничка, которая приезжает с гугла. В момент отдачи сервер всё-таки знает, что там будет input type=text, а не, скажем, textarea. C точки зрения Павла Дворкина это — ересь. Весь гугл должен был свестись к сервису, который умеет процессить поисковые запросы, и отдавать ответ не в виде HTML страницы со ссылками, а в виде какого-то абстрактного документа. А уже некий клиент (который непонятно откуда берется в существующей кривой архитектуре) будет отвечать за "раскладку данных по контролам". Наверное, в прямой архитектуре у меня должен был стоять Google Search Application, который умеет пользоваться Open Search API.
При этом эти независимые от Google Service разработчики клиента никогда бы не смогли сделать Google Suggest — потому, что поисковый сервис не предусмотрел ничего подобного в своем API. У разработчиков сервиса нет никакой мотивации внедрять такую функциональность — ни один из независимых клиентов не умеет ее использовать.
Только благодаря тому, что Google Search — это веб приложение, у его авторов есть возможность сразу же повлиять на оба компонента. Сервис знает, что в клиенте есть такая функциональность — он сам отдает браузеру код, который умеет пользоваться Google Suggest. Ему не нужно заниматься согласованием версии протокола и прочей ерундой.
A>А это уже вопрос к разработчикам интерфейса взаимодействия клиента и сервиса.
Интерфейс взаимодействия появляется не сам по себе. Я привел пример. A>Опять же, в общем случае знания о внутреннем устройстве как сервера так и клиента тут не нужны. ООП в аналогию.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, anonymous, Вы писали:
A>Вот и скатились на частности. Ну хорошо, придумаю я тебе самый общий метод getObjectFields(objectClass, objectId, [objectFields]) => [objectValues]. Сервер при этом достаёт весь объект и кеширует его, не будем обсуждать как, всё отработано давно до мелочей. А клиент берёт какие хочет поля, для каких угодно своих нужд. Кеширование на клиенте не запрещено. Запрет на избыточность данных искуственен. Ещё пример придумаешь?
Это будет не очень хороший протокол. Он не отвечает потребностям реальных клиентов. В частности, ничего не сказано про то, как получить данные по нескольким объектам. Каким образом выполнять discovery этих объектов, и так далее.
Если мы продолжим эти умственные упражнения, то получим SQL, вид сбоку.
Дальше что? Вон в соседнем форуме меня опытные собаководы в три голоса уверяют, что SQL — плохой язык, и что приличный клиент обязан общаться с сервером исключительно через хранимые процедуры.
AVK>>Тебе Антон уже сказал — Janus это не веб-приложение. Но и тут его веб-сервис заточен именно под модель януса (да еще и под конкретную версию его архитектуры). А для NNTP уже совсем другой сервис.
A>Я между прочим то же самое сказал. Я так же упомянул, что писал веб-приложение работающее с сервисом Janus'а. А также я написал, что интерфейс взаимодействия обсуждаем.
Фишка в том, что если бы янус был веб приложением, то его можно было бы гораздо быстрее развивать. И проблемы типа "у меня F# не раскрашивается" — "поставь себе новый билд" не возникали бы в принципе.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
A>>Вот и скатились на частности. AVK>А черт, он как раз в деталях.
Каждого чёрта в отдельности обсудим?
A>> Ну хорошо, придумаю я тебе самый общий метод getObjectFields(objectClass, objectId, [objectFields]) => [objectValues]. AVK>Так в том и дело, что не надо такого метода придумывать.
Почему? Что запрещает? Что запрещает по заказу разработчиков клиента в дополнение к нему сделать кучу методов типа getABForPerson(personId) => [aValue, bValue]? А на вопрос разработчиков сервера: "Зачем?" — разработчикам клиента ответить: "Не ваше дело." Это примитивная оптимизация. А может быть эти методы введут сами разработчики сервера проанализировав статистику запросов, и попросят разработчиков клиента впредь пользоваться ими. Это обычные соглашения об интерфейсе. Знать о внутреннем устройстве компонент не обязательно и не нужно.
A>>Запрет на избыточность данных искуственен. AVK>Нифига себе исскуственен. Увеличение объема считываемых с диска данных и увеличение сетевого трафика -> увеличение времени отклика по твоему исскусственное ограничение?
Ой, а чего это мы вдруг про кеширование так быстро забыли?
AVK>Ну тогда дальше, наверное, разговаривать уже не о чем.
Да как хочешь, я не навязываюсь.
A>>Я между прочим то же самое сказал. Я так же упомянул, что писал веб-приложение работающее с сервисом Janus'а. AVK>Ага, но показать его постеснялся
Я его не дописал, нашлись дела поважнее. (: Главное, оно работало.
AVK>Понимаешь, в чудеса человеческой изворотливости я тоже верю. Но оптимальное решение будет другим. Вопрос в выборе баланса между оптимальностью и универсальностью. Так вот — в случае сетевого взаимодействия и БД все еще оптимальность сильно важнее, потому что именно эти моменты скорее всего будут являться бутылочными горлышками.
Я ни разу не сказал, что я против оптимизации. Но я всё ещё пытаюсь обсуждать общий случай.
AVK>>>Наоборот, прекрасный пример. A>>Janus значит не прекрасный пример AVK>Janus тоже прекрасный — его веб-сервис заточен исключительно под него самого. Это я тебе как автор говорю.
Я тебе говорю, что независимо от того, как и подо что затачивался этот веб-сервис, его сможет использовать любой другой клиент. И этот веб-сервис ничего знать о нем не будет.
Здравствуйте, anonymous, Вы писали:
AVK>>А черт, он как раз в деталях.
A>Каждого чёрта в отдельности обсудим?
Я, кажется, уже ответил на этот вопрос.
A>>> Ну хорошо, придумаю я тебе самый общий метод getObjectFields(objectClass, objectId, [objectFields]) => [objectValues]. AVK>>Так в том и дело, что не надо такого метода придумывать.
A>Почему? Что запрещает?
Падение эффективности, усложнение контракта сервиса.
A> Что запрещает по заказу разработчиков клиента в дополнение к нему сделать кучу методов типа getABForPerson(personId) => [aValue, bValue]?
Ничто не запрещает. Только в этом случае говорить о том, что сервис не знает про клиента уже не приходится.
A> А на вопрос разработчиков сервера: "Зачем?" — разработчикам клиента ответить: "Не ваше дело."
Дурдом на выезде?
A>Знать о внутреннем устройстве компонент не обязательно и не нужно.
Речь шла не о том, что сервер должен знать внутреннее устройство клиента, или наоборот, а о том, что сервер должен знать про потребности клиента. Нельзя разработать сервис, удовлетворяющий потребности любых клиентов. И дело не только в контракте сервиса. Цепочка тянется глубже — от этого в определенной степени зависит и архитектура самого сервера, и структура БД.
AVK>>Нифига себе исскуственен. Увеличение объема считываемых с диска данных и увеличение сетевого трафика -> увеличение времени отклика по твоему исскусственное ограничение?
A>Ой, а чего это мы вдруг про кеширование так быстро забыли?
Никто не забыл. Но кеширование не панацея, и не бесплатный сыр, за него тоже надо платить.
AVK>>Ага, но показать его постеснялся
A>Я его не дописал
Ну раз не дописал, то и говорить не о чем.
A>Я ни разу не сказал, что я против оптимизации. Но я всё ещё пытаюсь обсуждать общий случай.
Сферического коня в вакууме?
AVK>>Janus тоже прекрасный — его веб-сервис заточен исключительно под него самого. Это я тебе как автор говорю.
A>Я тебе говорю, что независимо от того, как и подо что затачивался этот веб-сервис, его сможет использовать любой другой клиент.
Это пожалуйста. Но ничего хорошего из этого не получится. Либо клиент будет примитивный, либо будет жуткий оверхед по трафику и по работе сервера, либо идеологически клиент (по крайней мере его часть, работающая с сервером) будет максимально близок к янусу.
... << RSDN@Home 1.2.0 alpha 4 rev. 995 on Windows Vista 6.0.6001.65536>>
