Здравствуйте, Mamut, Вы писали:
PD>>Ваше решение ?
PD>>Категорическое требование — сервер a.com решительно не хочет ничего знать о почтовых делах и даже о существовании b.com, а b.com — не интересуется продуктами и не знает о наличии a.com.
M>expedia.com
M>Помимо собственной базы, тянет данные также из всяких GPS(global planning system). Поьзователь загел, заказал отель+трансфер+перелет, expedia отослала все данные, кому надо, составила маршрут, отдала пользователю билет+путевку
Нарушает мое требование выше — сервер a.com решительно не хочет ничего знать о почтовых делах.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А ты сумел это решение в рамках AJAX реализовать. Я ведь и писал, что AJAX — это некая попытка вернуться к здравому смыслу. Но усложнить задачу — и тебе понадобятся либо еще d.com, e.com..., либо такой уж C.com, который будет все делать.
Я даже не знаю, что ответить, потому что для меня, как JEE разработчика, это совершенно нормально.
Более того, я с легкостью могу представить вариант, когда a.com и b.com, например, платны для того, кто предоставляет сервис c.com (не для конечного пользователя!). Как вариант, a.com и b.com -- лишь частные реализации сервисов и однажды их надо будет заменить на другие.
И еще тут такое архитектурное соображение. Если клиент, работающий с a.com и с b.com разрабатывается независимо от них (а это, в принципе, следует из условия), то в любом случае нужна какая-то прокладка между ними и клиентским приложением, для обеспечения меньшей связности.
>>Как вариант, вызывать сервисы a.com и b.com будет c.com (например, сервисы a.com и b.com могут не быть доступны публично, а только для "партнеров"), а форма будет делать один-единственный запрос к c.com.
PD>Все принимается. Именно это я и предложил. Замечу, что c.com здесь попросту не нужен, если бы код на клиенте мог сам обратиться к a.com и b.com.
Стоп. А какая, собственно разница?
PD>Я к чему этот пример привел ? Если действовать в рамках классического "при нажатии Submit форма отсылает свои данные на сервер" — то ничего не выйдет, так как тут два сервера. А вот если на клиенте имеется приложение с более или менее изощренной логикой, то задача становится банальной. Хоть к десятку серверов по очереди (а то и параллельно с ожиданием обращайся. Вообще, делай что хочешь, не ограничивая себя ничем. К примеру, обращаешься ты к a.com, а он тебе в ответ — скачай файл с ftp://a.com .Качаем его, анализируем и на основе этого анализа делаем что-то. Письмо можешь отправить прямо с клиента. И т.д. Я это, конечно, не как пример хорошего стиля привел, а просто , чтобы продемонстрировать возможности.
Стоп. Какая разница?
Веб приложение — это не просто морда на HTML. Это морда на ХТМЛ плюс сервер. Сервер также ничем не ограничен. Он также может слать запросы хоть в сотню мест одновременно
PD>А ты сумел это решение в рамках AJAX реализовать. Я ведь и писал, что AJAX — это некая попытка вернуться к здравому смыслу. Но усложнить задачу — и тебе понадобятся либо еще d.com, e.com..., либо такой уж C.com, который будет все делать.
И? Сервер c.com, который будет делать запросы ко всем этим сторонним сервисам куда делся? Никуда.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Ты уж хоть самому себе не противоречь. Только что ты мне про web-сервисы писал, в задаче с a.com и b.com. А для них рекоменлованный протокол — SOAP. Кем рекомендованный? SOAP — чудовищный отстой, придуманный по трагической ошибке. PD> XML то есть. И парсит его web-service просто так. Обучен он этому, понимаешь ли. PD>И с чего это XML файл с двумя координатами будет чудовищным ?
Ну почему же с двумя? Речь шла про "список адресов, которые мне надо посетить".
Вот я тебе отправил ссылку на даже более продвинутую штуку — там есть разноцветные флажки, примечания, предполагаемые фрагменты маршрута. Ну и понятно, что штука интерактивная — т.е. ты к примеру можешь получить инструкции по проезду к любому из мест. PD> Скорее уж командная строка чудовищная, особенно когда там русские буквы в виде %EC%AD... Я такое как-то плохо в ASCII в уме перевожу. А если там не на русском, а на грузинском ?
А зачем тебе русские буквы, на грузинском, и переводить? Для сервиса проблем с переводом нету, а человек и XML читать не будет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Помимо собственной базы, тянет данные также из всяких GPS(global planning system). Поьзователь загел, заказал отель+трансфер+перелет, expedia отослала все данные, кому надо, составила маршрут, отдала пользователю билет+путевку PD>Нарушает мое требование выше — сервер a.com решительно не хочет ничего знать о почтовых делах.
А сервисы, которыми пользуется expedia, ничего о них и не знают.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Нет, пока что еще рано. Сначала свяжись с a.com, чтобы узнать габариты и вес. Без этого b.com с тобой и разговаривать не будет.
А, тебе надо детали реализации сервера? Ок.
PD>Если несложно, объясни, в каком порядке будут 1a и 1b выполняться. В нынешнем — невозможно, см. выше. PD>И еще — куда 1b свой 404 вернет ?
Клиенту.
S>>2. Форма для формирования следующего запроса. В форме два поля: название товара и адрес. В нее подставлены значения, которые указаны в параметрах URL. После нажатия submit форма банально отправляет браузер на URL, сформированный по введенным пользователем данным.
PD>На какой именно URL ?
Я же указал в начале.
PD>Все остальное skipped. Если действительно хочешь ответить — потрать минут 5 и опиши схему в деталях. Например
PD>Форма для формирования следующего запроса. В форме два поля: название товара и адрес. В нее подставлены значения, которые указаны в URL web-сервиса c.com (я правильно понял ? — PD)
Да. PD> . После нажатия submit форма банально отправляет браузер на этот URL, сформированный по введенным пользователем данным.
Да. PD>Получив этот HTTP запрос, сервис c.com выполняет следующие действия ... И по порядку.
1. Сервис на c.com соединяется по протоколу HTTP с сервисом a.com и пытается получить результат.
Предполагаем три возможных ситуации:
1a. Сервис a.com вернул 200 Ok, т.е. товар найден. Мы парсим его response и переходим на шаг 2.
1b. Сервис a.com вернул 404 Not Found, т.е. товар не найден. Мы вернем клиенту 404, сообщение "товар не найден" и покажем стандартную форму из п. 4.
1с. Сервис a.com вернул что-то еще либо нам не удалось с ним связаться. Вернем клиенту 400, сообщение "ничего не работает" и покажем стандартную форму из п. 4.
Пока что мы пренебрегаем обработкой 302, 303, 304, и 307.
2. Отправляем запрос скомбинированный из данных, полученных в 1a от a.com и введенного пользователем адреса, на сервис b.com
Рассматриваем два варианта:
2a. Сервис b.com вернул 200 Ok, т.е. подсчет стоимости удался. Переходим на шаг 3.
2b. Сервис b.com вернул что-то еще либо нам не удалось с ним связаться. Вернем клиенту 400, сообщение "товар найден по адресу XXX, но с оценкой доставки возникли проблемы" и покажем стандартную форму из п. 4.
3. Показываем результат работы: стоимость доставки.
4. Показываем форму с двумя инпутами, в которой подставлены те значения, которые были переданы в URL. Метод у формы — GET, action="".
Всё. Полчаса работы. Никаких упражнений с аяксами в данной задаче выполнять не нужно — это не улучшит поведение системы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
PD>>>Категорическое требование — сервер a.com решительно не хочет ничего знать о почтовых делах и даже о существовании b.com, а b.com — не интересуется продуктами и не знает о наличии a.com.
M>>expedia.com
M>>Помимо собственной базы, тянет данные также из всяких GPS(global planning system). Поьзователь загел, заказал отель+трансфер+перелет, expedia отослала все данные, кому надо, составила маршрут, отдала пользователю билет+путевку
PD>Нарушает мое требование выше — сервер a.com решительно не хочет ничего знать о почтовых делах.
Причем тут сервер а? expedia — это сервер с.
Схема работает так:
— клиент зашел на http://expedia.com/ (сервер с) и сказал:
хочу отель в нью-йорке, 05.05-10.05, прилетаю я из парижа
— expedia ломанулась в свою базу данных отелей (сервер а), и запомнила:
отель есть
— expedia ломанулась в систему типа Amadeus (сервер b) или Galileo (сервер x) или любую GPS (сервера y1, y2...yn) и запомнила:
самолет есть
— expedia вернулась к клиенту (сервер с) и сказала:
нате вам сформированное предложение с отелями с сервера а и самолетами с сервера b
Причем клиенту пофиг, что и с какого сервера пришло
Другой пример. Я заказал на Амазоне товар. Я его выбрал, заплатил, его мне доставили. В момент отправки Amazon мне сказал: мы отправили ваш ттовар с помощью DHL, номер вашего заказа: X, проверить статус товара можно на сайте http://dhl.com/status/X
Все произошло абсолютно без моего участия, на сервере с(Амазон), который сам связал товар (сервер а) с поставщиком (сервер b), при этом сервер b так и не узнал, чем я оплачивал, какие еще товары я заказывал и т.п.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>Ты уж хоть самому себе не противоречь. Только что ты мне про web-сервисы писал, в задаче с a.com и b.com. А для них рекоменлованный протокол — SOAP. S>Кем рекомендованный?
Microsoft.
>SOAP — чудовищный отстой, придуманный по трагической ошибке.
И XML, конечно, тоже. Ясно.
PD>>И с чего это XML файл с двумя координатами будет чудовищным ? S>Ну почему же с двумя? Речь шла про "список адресов, которые мне надо посетить".
Понятно. С двумя не будет, а вот если маршрут содержит 15-20 точек — будет. Все ясно.
S>Вот я тебе отправил ссылку на даже более продвинутую штуку — там есть разноцветные флажки, примечания, предполагаемые фрагменты маршрута. Ну и понятно, что штука интерактивная — т.е. ты к примеру можешь получить инструкции по проезду к любому из мест.
И что ? Хорошая программа, ничего плохого не скажу. Но что тут особенного ? БД у них мощная, карты хорошие, серверов много. Вот и все
PD>> Скорее уж командная строка чудовищная, особенно когда там русские буквы в виде %EC%AD... Я такое как-то плохо в ASCII в уме перевожу. А если там не на русском, а на грузинском ? S>А зачем тебе русские буквы, на грузинском, и переводить? Для сервиса проблем с переводом нету, а человек и XML читать не будет.
А меня как раз заказчик просит сейчас сохранение в XML сделать и добавить возможность там редактировать кое-что. Я ему теперь объясню, что это все отстой, ибо так сказал Sinclair.
Ладно, хватит, не стоит продолжать. Бессмысленно. Твоя зашоренность просто удивляет.
Здравствуйте, Mamut, Вы писали:
PD>>Форма для формирования следующего запроса. В форме два поля: название товара и адрес. В нее подставлены значения, которые указаны в URL web-сервиса c.com (я правильно понял ? — PD) . После нажатия submit форма банально отправляет браузер на этот URL, сформированный по введенным пользователем данным. Получив этот HTTP запрос, сервис c.com выполняет следующие действия ... И по порядку.
M>Сервер (а не клиент) отправляет запрос на a.com, b.com, ...., x.com в порядке, предусморенном логикой приложения
Подробнее, пожалуйста. Сервер — каким именно образом он эти запросы делать будет ? Он умеет сам запросы от броузеров принимать (с помощью web-сервера), а вот web-клиентом он не является. Добавим в него функциональность web-клиента ?
Здравствуйте, Sinclair, Вы писали:
S>1. Сервис на c.com соединяется по протоколу HTTP с сервисом a.com и пытается получить результат.
Так, минуту. Сервис на c.com, что, содержит в себе web-клиента ? Как иначе он запрос-то делать будет ? И где он для этого форму возьмет ? У него она, стало быть, есть.
S>Предполагаем три возможных ситуации:
<детали skiped,согласен>
S>2. Отправляем запрос скомбинированный из данных, полученных в 1a от a.com и введенного пользователем адреса, на сервис b.com
Так, еще один web-клиент на c.com, или же перенастроили предыдущий клиент. Из первого клиента взяли данные , новую форму соорудили , в нее данные занесли и submit ей устроили ?
S>Рассматриваем два варианта:
<детали skiped,согласен>
S>3. Показываем результат работы: стоимость доставки.
То есть теперь c.com вернул ответ клиенту в ответ на его запрос.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Microsoft.
Не надо слушать всё, что говорит Microsoft. Надо думать и своей головой иногда. PD>И XML, конечно, тоже. Ясно.
Нет, в XML ничего особенно плохого нет. Впрочем, я и не ожидал, что ты угадаешь.
S>>Вот я тебе отправил ссылку на даже более продвинутую штуку — там есть разноцветные флажки, примечания, предполагаемые фрагменты маршрута. Ну и понятно, что штука интерактивная — т.е. ты к примеру можешь получить инструкции по проезду к любому из мест.
PD>И что ? Хорошая программа, ничего плохого не скажу. Но что тут особенного ? БД у них мощная, карты хорошие, серверов много. Вот и все
Только она работает без файлов в неизвестном науке формате (на всякий случай напомню, что кроссплатформенного способа определить по XML файлу имя и адрес приложения, которое его должно открывать, не существует), без инсталляции какого-либо софта на клиента и очень-очень эффективно в плане сетевого трафика.
Ее вряд ли можно было бы существенно улучшить путем перехода на инсталлируемого клиента (чего тебе почему-то очень сильно хочется).
Основное отличие Google Earth — поддержка 3d.
Увы, оказывается и это не проблема для современных веб-приложений. Хочешь представить себе окрестности штаб-квартиры микрософт?
На, смотри: http://maps.live.com/#JnE9eXAubWljcm9zb2Z0JTdlc3N0LjAlN2VwZy4xJmJiPTY1LjQwMzQ0NDc4ODMwNzglN2UxMTIuNSU3ZTQxLjExMjQ2ODc4OTE4MDklN2U1My4zNDk2MDkzNzU=
Bird's eye работает без клиента.
PD>>> Скорее уж командная строка чудовищная, особенно когда там русские буквы в виде %EC%AD... Я такое как-то плохо в ASCII в уме перевожу. А если там не на русском, а на грузинском ? S>>А зачем тебе русские буквы, на грузинском, и переводить? Для сервиса проблем с переводом нету, а человек и XML читать не будет.
PD>А меня как раз заказчик просит сейчас сохранение в XML сделать и добавить возможность там редактировать кое-что. Я ему теперь объясню, что это все отстой, ибо так сказал Sinclair.
PD>Ладно, хватит, не стоит продолжать. Бессмысленно. Твоя зашоренность просто удивляет.
Павел, у меня никакой зашоренности нет. У меня хватает опыта работы и с настольными, и с классическими "сетевыми" приложениями, и с веб-приложениями, и с веб-сервисами, и с SOAP будь он неладен. А вот ты практически ничего не знаешь про веб приложения, и продолжаешь из принципа цепляться
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>1. Сервис на c.com соединяется по протоколу HTTP с сервисом a.com и пытается получить результат.
PD>Так, минуту. Сервис на c.com, что, содержит в себе web-клиента ? Как иначе он запрос-то делать будет ? И где он для этого форму возьмет ? У него она, стало быть, есть.
Павел, Вы извините, конечно, но, по-моему, у Вас какое-то странное представление о работе веб-серверов и протоколе HTTP. Средства для отправки HTTP-запросов давным-давно существуют в любой веб-платформе. Никакой "формы" для этого не надо. Никакой особенной "функциональности веб-клиента" тоже.
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!
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Подробнее, пожалуйста. Сервер — каким именно образом он эти запросы делать будет ?
Ты меня удивляешь.
Так и будет делать. Например,
var request = WebRequest.Create("http://a.com/handlerpath");
PD>Он умеет сам запросы от броузеров принимать (с помощью web-сервера), а вот web-клиентом он не является. Добавим в него функциональность web-клиента ?
А почему ты думаешь, что ее там нету? curl есть на любом линуксе, WebСlient есть на любой винде. Про джаву/.net я и не говорю.
Или ты думал, что веб-клиент — это Интернет Эксплорер?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Так, минуту. Сервис на c.com, что, содержит в себе web-клиента ? Как иначе он запрос-то делать будет ? И где он для этого форму возьмет ? У него она, стало быть, есть.
Спрашивали — отвечаем.
Никакой формы в сервисе нет. Есть HttpWebRequest. Мы получаем HttpWebResponse, и делаем второй HttpWebRequest.
Форма — чисто клиентский артефакт; браузер умеет с ее помощью делать некоторое убогое подмножество HTTP-запросов. PD>Так, еще один web-клиент на c.com, или же перенастроили предыдущий клиент. Из первого клиента взяли данные , новую форму соорудили , в нее данные занесли и submit ей устроили ?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
PD>>Все принимается. Именно это я и предложил. Замечу, что c.com здесь попросту не нужен, если бы код на клиенте мог сам обратиться к a.com и b.com.
M>Стоп. А какая, собственно разница?
Ну разница все же есть. Пользователь должен запрос к c.com устраивать, назначения которого он не понимает и догадаться о его существовании, мб, не сможет.
PD>>Я к чему этот пример привел ? Если действовать в рамках классического "при нажатии Submit форма отсылает свои данные на сервер" — то ничего не выйдет, так как тут два сервера. А вот если на клиенте имеется приложение с более или менее изощренной логикой, то задача становится банальной. Хоть к десятку серверов по очереди (а то и параллельно с ожиданием обращайся. Вообще, делай что хочешь, не ограничивая себя ничем. К примеру, обращаешься ты к a.com, а он тебе в ответ — скачай файл с ftp://a.com .Качаем его, анализируем и на основе этого анализа делаем что-то. Письмо можешь отправить прямо с клиента. И т.д. Я это, конечно, не как пример хорошего стиля привел, а просто , чтобы продемонстрировать возможности.
M>Стоп. Какая разница?
Продумай всю эту схему в деталях
M>Веб приложение — это не просто морда на HTML. Это морда на ХТМЛ плюс сервер. Сервер также ничем не ограничен. Он также может слать запросы хоть в сотню мест одновременно
Может. Только вот при этом ему придется отнюдь не серверными делами заниматься, и изображать из себя то web-client, то ftp-client, то еще что-нибудь. Он уже, по сути не сервер, а нечто общее будет.
PD>>А ты сумел это решение в рамках AJAX реализовать. Я ведь и писал, что AJAX — это некая попытка вернуться к здравому смыслу. Но усложнить задачу — и тебе понадобятся либо еще d.com, e.com..., либо такой уж C.com, который будет все делать.
M>И? Сервер c.com, который будет делать запросы ко всем этим сторонним сервисам куда делся? Никуда.
Да, только функционал его резко возрастает и становится не серверным.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
PD>>>Форма для формирования следующего запроса. В форме два поля: название товара и адрес. В нее подставлены значения, которые указаны в URL web-сервиса c.com (я правильно понял ? — PD) . После нажатия submit форма банально отправляет браузер на этот URL, сформированный по введенным пользователем данным. Получив этот HTTP запрос, сервис c.com выполняет следующие действия ... И по порядку.
M>>Сервер (а не клиент) отправляет запрос на a.com, b.com, ...., x.com в порядке, предусморенном логикой приложения
PD>Подробнее, пожалуйста. Сервер — каким именно образом он эти запросы делать будет ? Он умеет сам запросы от броузеров принимать (с помощью web-сервера), а вот web-клиентом он не является. Добавим в него функциональность web-клиента ?
Десктоп приложение как работает? Это [отображение + логика] Так?
Как работает веб-приложение? Это [отображение + логика] Так? Веб-страница — это отображение. Сервер — это логика. Что тут непонятного?
|уровень отображения|уровень логики
веб-страница
----запрос--->
сервер
--- запрос другим серверам --->
<-- ответ с других серверов ---
<---ответ----
Каким образом сервер будет запросы делать? Да каким угодно, в зависимости от того, какой API для взаимодействия ему предоставляют другие сервера. У мня товарищ одно врема тупо парсил HTML одного турецкого банка для того, чтобы получить курс валют, чтобы показать на своем сайте (при этом посетитель сайта ни сном ни духом не знал, что список валют получен с какого-то другого сервера)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Microsoft. S>Не надо слушать всё, что говорит Microsoft. Надо думать и своей головой иногда.
Не надо исходить из того, что принципы, положенные в основу современной модели, являются наилучшими. Надо и своей головой думать иногда.
PD>>И XML, конечно, тоже. Ясно. S>Нет, в XML ничего особенно плохого нет. Впрочем, я и не ожидал, что ты угадаешь.
Я не телепат и не специалист по шарадам.
S>Только она работает без файлов в неизвестном науке формате (на всякий случай напомню, что кроссплатформенного способа определить по XML файлу имя и адрес приложения, которое его должно открывать, не существует), без инсталляции какого-либо софта на клиента и очень-очень эффективно в плане сетевого трафика.
Тебе не надоело аргументы в ее пользу приводить ? Я же уже ответил — хорошее приложение, не спорю. Твои аргументы все в одну фразу укладываются — посмотри, какое оно хорошее, вот что оно еще умеет и вот что, смотри. Какое это отношение к делу имеет ? Что, если бы это было десктопным приложением, он бы трафик больший устраивало ? Трафик определяется тем, что посылают и что принимают, а не тем, является приложение десктопным или нет. Если ICQ сделать web-приложением — что, трафик для передачи SMS изменится ?
PD>>Ладно, хватит, не стоит продолжать. Бессмысленно. Твоя зашоренность просто удивляет. S>Павел, у меня никакой зашоренности нет. У меня хватает опыта работы и с настольными, и с классическими "сетевыми" приложениями, и с веб-приложениями, и с веб-сервисами, и с SOAP будь он неладен. А вот ты практически ничего не знаешь про веб приложения, и продолжаешь из принципа цепляться
Зря тыт так думаешь. Я полтора года ими занимался, мне вполне хватило, чтобы по крайней мере основные идеи понять. А насчет зашоренности — ты ее просто не видишь. Все твои аргументы, в конечном счете, к одному сводятся — посмотрите, какие хорошие возможности есть у тех или иных web-приложений. Но я с этим и не спорю, есть. Я утверждаю совсем другое — эти приложения имеют довольно-таки кривую архитектуру. И на базе кривой архитектуры можно неплохое ПО сделать. А вот для тебя, похоже, нет бога, кроме Аллаха и бог един.
PD>>>Все принимается. Именно это я и предложил. Замечу, что c.com здесь попросту не нужен, если бы код на клиенте мог сам обратиться к a.com и b.com.
M>>Стоп. А какая, собственно разница?
PD>Ну разница все же есть. Пользователь должен запрос к c.com устраивать, назначения которого он не понимает и догадаться о его существовании, мб, не сможет.
define: пользователь?
Я — пользователь. Я зашел на expedia.com. Мне абсолютно фиолетово, к скольки серверам будет устроен запрос, я в итоге получу готовый ответ.
M>>Стоп. Какая разница?
PD>Продумай всю эту схему в деталях
M>>Веб приложение — это не просто морда на HTML. Это морда на ХТМЛ плюс сервер. Сервер также ничем не ограничен. Он также может слать запросы хоть в сотню мест одновременно
PD>Может. Только вот при этом ему придется отнюдь не серверными делами заниматься, и изображать из себя то web-client, то ftp-client, то еще что-нибудь. Он уже, по сути не сервер, а нечто общее будет.
У нас есть отображение (веб-страница)
У нас есть логика (сервер)
Среди прочих сервер может обращаться к другим серверам за информацией по различным протоколам: SOAP, XML-RPC, двоичным протоколам на основе ASN.1, прямым обменом сырыми двоичными данными и проч. Что его менее сервером не делает
Сервер может и не запрашивать такие данные, если он самодостаточен. Но как минимум он будет обращаться к базе данных тоже по какому-то протоколу (здесь он видать становится веб-фтп-клиентом, ага)
В результате сервер получает/генерирует какие-то данные, которые отправляются в уровень отображения — на веб-страницу
PD>>>А ты сумел это решение в рамках AJAX реализовать. Я ведь и писал, что AJAX — это некая попытка вернуться к здравому смыслу. Но усложнить задачу — и тебе понадобятся либо еще d.com, e.com..., либо такой уж C.com, который будет все делать.
M>>И? Сервер c.com, который будет делать запросы ко всем этим сторонним сервисам куда делся? Никуда.
PD>Да, только функционал его резко возрастает и становится не серверным.
??????????????????????????????????????????????
Можно эту фразу перевести на русский? Или определение работы сервера в студию. Мне сложно представить себе некий сферовакуумный сервер, который существует в отрыве от внешнего мира
PD>Нет. Используем его. CHtmlView — это просто view для окна, в котором IWebBrowser2 сидит. В конце концов броузер из двух частей состоит. Одна часть, сильно навороченная — это само броузерное приложение, со всеми опциями и возможностями, SSL и сертификатами и т.д. Другая — просто очень своеобразный контрол, в котором можно картинки показывать, некоторые строчки подсвечивать, курсор над ними форму руки принимает и т.д., а для описания этому контролу, где и как все изобразить, используется некий язык под названием HTML. Вот эту вторую часть и несложно вставить в свое приложение. Впрочем, и от первой части там кое-что будет — отрабатываться линки будут.
Как человек который немного в теме, могу тебя заверить что "вставить вторую часть в своё приложение" — это вовсе не так просто как это кажется на первый взгляд. Куча ньюансов, куча подводных камней. К примеру, пользователь отключил в IE показ картинок — и — опа — а где красивые картинки в моём приложении подевались? Выкрутил настройки безопасности IE на максимум (даже не я выкрутил, а администратор сети, он молодец и паранойик) — и опа, приложению нашему стало плохо. CHtmlView это слишком тонкая прослойка, для реальных приложений которые хостят MS HTML он решает лишь малую часть проблем.
И кстати балланс сложности между MS HTML (как ты его называешь — IWebBrowser2) и собственно IE ты понимаешь неправильно — самое сложное как раз MS HTML, с HTML рендерером, поддержкой Pluggable protocols, секьюрити, интеграцией с Active Scripting и т.п. А собственно IE — это лишь UI для показа менюшек и хостинга MS HTML. Именно поэтому есть с дюжину "альтернативных" IE — всякие там Maxthon и т.п., которые хостят MS HTML самостоятельно.
Здравствуйте, Sinclair, Вы писали:
PD>>Ты уж хоть самому себе не противоречь. Только что ты мне про web-сервисы писал, в задаче с a.com и b.com. А для них рекоменлованный протокол — SOAP. S>Кем рекомендованный? SOAP — чудовищный отстой, придуманный по трагической ошибке.
обращайся. Вообще, делай что хочешь, не ограничивая себя ничем. К примеру, обращаешься ты к a.com, а он тебе в ответ — скачай файл с ftp://a.com .Качаем его, анализируем и на основе этого анализа делаем что-то. Письмо можешь отправить прямо с клиента. И т.д. Я это, конечно, не как пример хорошего стиля привел, а просто , чтобы продемонстрировать возможности.
