Здравствуйте, Mamut, Вы писали:
M>Наткнулся вот на такое: http://blog.blist.com/index.php/2008/01/30/blist-demo-08-launch-video/ (видеопрезентация)
M>Подумалось... Все же люди начинают делать веб-приложения с упором на слово приложение, несмотря на всю кривизну HTML+CSS+Javascript. Предстоит нам бум таких приложений или все же нет?
На протяжении последних лет имею отношение к созданию уже трех поколений одного и того же приложения.
Нечто типа Office только для сегмента рынка. Т.е. есть "контакты", scheduler/calendar, свой e-mail, word processor, но нет excel потому как не нужно
— есть набор модулей и форм делающих все нужные вычисления. Все это естетсвенно интегрировано друг с другом как нужно.
Итак три поколения или варианта одного и того же:
Первое поколение: было типичное десктоп приложение — VB и много добра на C++. Была group версия — с файл-сервером (дрова страшные) и пр.
Второе поколение: клиент/сервер, MS Java Applet + custom JNI modules(word processor например) и сервер — SOAP/IIS/ASP/VB6/MSSQL.
Третье поколение: HTML/AJAX клиент + ActiveX/NSplug-ins и сервер ASP.NET/MSSQL.
В данный момент могу объективно оценивать все три варианта. На самом деле имеет смысл сравнивать последние два в данном контексте.
Разработка: человеко-часы — для третьего поколения не меньше чем второго. AJAX и scripting своей недетрминирванностью и "в IE работает в FF — нет" добавили
фана и ощущения как-то-это-все-на-соплях-держится. Java и MS VisualJ++ IDE представляется значительно более комфортным и суть надежным способом разработки UI.
Для данной задачи (оффисное (productive) приложение с доступом клиента из оффиса и дома) второе поколение представляется наиболее адекватным поставленой задаче.
Техническое качество UI (response time, weight, features) практически делало систему неотличимую от desktop приложения исполняемого локально.
Трафик с сервером — "летает", ибо пакеты компактны — только данные. Переход на HTML UI (который формируется на сервере и доставляется каждый раз на клиента)
резко поднял нагрузку на server side. Один http сервер стал обслуживать в три раза меньше клиентов.
Между первым и вторым поколением Америка и Канада фактически перешли на broadband inet connection. Но между вторым и третьим "перерывчик небольшой" — эффективно
клиент системы потерял в качестве — UI стал ощутимо медленнее.
Далее, классический HTML/CSS не имеет средств vertical alignment что превратило все экраны/формы в длинные прокручиваемые ленты. Качество UI в этом случае пострадало.
Имхо, значительно.
Это я все к тому что приложение приложению — рознь. Скажем лично я бы не стал делать описываемое приложение как browser based (Третье поколение).
Как Sciter based — да. Но не как browser based.
Здравствуйте, c-smile, Вы писали:
CS>К сожалению для полномасштабных UI существует изначальная проблема browser — проблема наличия "back button". Это суровое ограничение которое ни Java Applet ни Silverlight в приниципе победить не могут.
Который (back button) вообще-то абсолютно ни к чему ни в каких "web приложениях", поскольку ничего, кроме головной боли, не создает. Вот в статических HTML сайтах, да, он имеет смысл. Здесь же логика действий пользователя должна контролироваться приложением, а оно это делать толком не может, так как пользователь с помощью back button может вполне отправиться черт знает куда, а потом вернуться.
Да разве только back button ? А возможность зайти на любую страницу, где уже был через history ? В том числе и на страницу, на которую вообще не положено заходить прямо, а только с некоей иной страницы ? Вот и ведут web-программисты отчаяную борьбу с тем, с чем вообще бороться и не надо бы, потому что этого не должно быть.
Да и прочего идиотизма хватает. Одни только "серверные элементы управления" чего стоят! Серверный комбобокс — это как ? Я что-то вообще его с большим трудом себе представляю . И за каким чертом серверу знать, что где-то на клиенте за 1000 км от него есть комбобокс
ИМХО действительно идея Java-апплетов является наилучшей. Подчеркиваю, идея, а не текущая реализация. Есть приложение (на Java), исполняемое на клиенте. Приложение обращается к серверу, сервер выполняет действия, клиент получает ответ. Фактически та же модель, что и в настольных приложениях типа multi-tier. Все.
Здравствуйте, Kisloid, Вы писали:
K>Ну или если рассматривать все вот с такой точки зрения, что браузер является хостом для твоего веб приложения, а ОС для твоего десктоп приложения. Изменения настроек браузера делаются в Tools -> Internet Options, а настройки ОС в Control Panel. Я почему-то сомневаюсь, что изменения настроек в Control Panel как-то негативно воздействуют на мое десктоп приложение
да, легко, что у нас там Fonts, Windows Firewall, Regional Options, любое десктопное приложение можно озадачить, а уж молчу про такую вещь как установка удаление кодеков. Только все это, так же как и с бразузером так и должно быть — если включается глобальная настройка "Не показывать картинки" то их и не должно быть ни где. То что у IE нет такой настройки отдельно по сайтам — это его личное горе, в FireFox есть.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я вообще-то в такие места не хожу
Твое счастье
PD>, и это не аргумент.
Это железобетонный аргумент. Тебе может и не надо, а мне вот регулярно. И сочетание глобальной доступности и того, что мне лень бекапы архива делать привело к тому, что от настольных мейлеров я отказался.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1054 on Windows Vista 6.0.6001.65536>>
Здравствуйте, c-smile, Вы писали:
CS>Частичным решением могло бы быть client side storage. Но этого нет ни в silverlight ни в Java Applet ни в Flex. CS>Есть попытка решить сие в Google Gears но опять же до стека undo/redo операций не добраться вообще.
Для Silverlight есть Isolated Storage
По умолчанию доступно 100Кб, можно увеличить по согласию пользователя.
Здравствуйте, AndrewVK, Вы писали:
AVK>Silverlight это несколько иное, это скорее закос в сторону Flash/Flex, но круче и изначально с рассчетом на построение UI.
Flash/Flex это тоже в принципе такой applet. applet c точки зрения host page это embeddable конструкция которая "исполняет" "активные" документы — т.е. некий код и имеет свой markup (optional).
К сожалению для полномасштабных UI существует изначальная проблема browser — проблема наличия "back button". Это суровое ограничение которое ни Java Applet ни Silverlight в приниципе победить не могут.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я бы так сказал — это тренд для серьезных компаний — та же Google. Но не для большинства компаний, увы...
Дело не в серьезности компании, а в серьезности человека, принимающего решения. А пока масса народа носится с горящими глазами и криками AJAX, AJAX и с PHP наперевес ...
... << RSDN@Home 1.2.0 alpha 3 rev. 883 on Windows Vista 6.0.6001.65536>>
Здравствуйте, VGn, Вы писали: VGn>Такая страница может быть промежуточной частью некой бизнес-транзакции. И да — у неё не должно быть прямой url, либо, что логичнее, страница по её url должна отслеживать состояние транзакции.
Совершенно верно. И HTTP позволяет нам писать приложения, которые такую реальность отражают. Только отсутствие опыта и систематического образования в данной области приводит к двум самым распространенным ошибкам:
— у ресурсов нет собственных URL (злоупотребление postback, AJAX, Flash, апплетами)
— у внутренних состояний бизнес-транзакций есть свои URL.
Как только допущена такая ошибка, начинается мужественная неравная борьба с браузером. В то время как верный способ — это проектировать приложение с учетом навигационной модели.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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>А надо было переслать, быть может, один бит (юзер галочку поставил)
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, Mamut, Вы писали:
M>>Предлагаю стереть из реестра ветки Adobe, а также папочку с настройками Адоба откуда-нить из Application Data. Оппаньки, а че это оно опять регистрацию запросило и работать перестало?
K>Ты понимаешь разницу между стереть ветки из реестра и легальным измененим настроек через общедоступный интерфейс?
ветки реесра я так же стираю через легальный общедоступный интерфейс
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Sinclair, Вы писали:
A>>>Таблицу с пэйджером ты как будешь делать? Сервисный метод, выдающий данные и запрос из javascript с последующим заполнением таблицы? По моему — самое удачное решение. S>>100%. GZ>Не всегда. Иногда пользователю нужна адресуемость именно второй страницы. Собственно, то о чем ты говорил до этого.
Это ничему не противоречит. Правильный способ — именно подкачка. Я могу сделать решение, которое будет выглядеть и работать как сплошная таблица с прокруткой, безо всякого искусственного пейджинга, и при этом 100% адресуемая. И при этом потребление трафика будет как птичка поклевала.
GZ>Простейший способ реализации — все таки get.
Всякий раз, когда нам нужно выбирать между простотой пользователя и простатой программиста, мы выбираем простоту пользователя. Потому что настоящему программисту простата не нужна
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
GZ>>Чудно. Пожалуй единственный плюс (правда иногда действительно необходимый). А дальше начинается борьба. Борьба с как выежиться в рамках эксплореров, которые плохо совместимы друг с другом. S>Это есть. Согласен. Но это не проблема архитектуры, а проблема реализации. Выберешь другую архитектуру — будешь бороться с чем-нибудь другим. Что, не сталкивался с глюками ListView? А я сталкивался. Любая более-менее сложная платформа содержит малоприятные "особенности".
Особенность та, что ты можешь сделать свое ListView. В достаточно короткие сроки. (вопрос будет ли лучше стандартного — не поднимаю).
GZ>>Борьба с безопасностью эксплорера. Борьба с Http. Особенно с его текстуальностьюю Открыть файл с длинным русским именем проблема. S>Никакой текстуальности в HTTP нет. Что такое "файл с длинным русским именем"? Может быть, кто-то не читал RFC 2046?
Если не читал — то Microsoft. Он спокойно пропускает такие неразбитые файловые имена, но изредка глючит. И благодаря этим изредка, подобную ошибку локализовать сложно.
GZ>>Даже борьба с твоим любимым кэшем. S>Это не борьба "с кэшем", а борьба со своим невежеством. На браузерной стороне багов в реализации кэша я не встречал. На серверной — бывали. GZ>>Ну очень он не нужен в SSL. S>Это неправда. В SSL кэш по умолчанию отключен. Кроме того, хидеры HTTP по-прежнему рулят.
Смотря как. Благодаря такому — один чел много времени потерял. Видишь-ли особенность.
GZ>>И на get'ы в url ставить уникальность задалбывает. S>Ну так надо учиться! Разбираться, что такое Cache-Control и что такое Expires. И никакого "ставить уникальность" не понадобится.
Не всегда подобное возможно. На какой-то версии IE мне так и не удалось побороть таким образом. Токмо через get.
GZ>>Кривизна заложена в самом WWW. Пытаясь предоставить универсальность, там где ее изначально не было решение настолько усложнили. S>Ну и где кривизна?
WWW — предназначено для текстовsх презентаций. Он очень хорошо показывает текст и картинки. В нем плохо проработаны именно не представление информации, а обработка информации перед и после показа. Если говорить о CSS и behavour, то можно сказать что по сложности — оно уже наравне с GUI. При этом возможностей меньше. А уж если говорить о самой возможности отключать JavaScript, то совсем плохо. Для WWW — он особенно и не нужен был. Для бизнес-приложений — обязателен.
S> Один из недостатков HTML. Но, как я уже неоднократно намекал, HTML не единственный язык разметки для веб-приложений. S>К примеру, хорошие аплоадилки народ пишет на Flash. А он сейчас имеет 97% покрытие целевой аудитории.
Для данной целевой аудитории — безусловно. А вот для бизнес — все значительно хуже. Да и время ответа увеличивается из-за лишнего оверхеда перегрузки логики приложения на локал. Иногда это бывает важно.
GZ>>В результате, из обычного приложения мы имеем только некоторый сложнопрограммируемый UI, и практически все. Остальные проблемы кладем на сервак. S>Совершенно верно! Павел вот только что наоборот ругался, что веб приложения сильно много отдают клиенту. Он против даже комбобоксов, а ты хочешь обсчет графа делать в IE. Нахрена? Вон посмотри как гугл мэпс обсчитывает граф при поиске пути из НьюЙорка в Сиэтл — причем размер графа такой, что никакой доступ к ресурсам твоего компьютера тебя бы не спас.
Именно. У google maps — своя специфика. Это очень дорогое решение, с большим количеством серверов, которые в комплексе очень высокопроизводительные и которое не каждый может себе позволить. И при этом я должен терпеть из-за загрузки их картинок по моему медленному и весьма латентному каналу.
Здравствуйте, 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 на совершенно другом языке. Все остальные положительные черты "обычных" приложений легко переносятся и на веб приложения.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>1. Irfan View, о котором я уже писал
Irfan View, кстати, обладает на редкость неудачным UI.
PD>А на wikipedia нет. Но обрати внимание, ты это преподносишь как достижение, в то время как для десктопных приложений это мелочь, так, мимоходом сделать
В обратную сторону это тоже работает. Например, способность Web UI очень хорошо приспосабливаться под разные шрифты и размеры текста — для большинства десктопных приложений до сих пор недоступное достижение. Или например такая тривиальнейшая вещь, как скопировать текст сообщения в буфер. У каждого вида приложений своя специфика ти недостатки, которые зачастую являются продолжением их достоинств. Например, способность веб-приложений работать везде оборачивается недоступностью специфичных локальных ресурсов. Надо просто уметь выбирать ту технологию, которая максимально подходит потребностям заказчика здесь и сейчас, а не вычислять которая из них сакс, а которая рулез.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1052 on Windows Vista 6.0.6001.65536>>
Да, если уж тебе приходится к таким аргументам прибегать — значит других не осталось.
S>Получается, что ты будешь давать 2 (две) ссылки: одну на само приложение, вторую — на файл с данными для приложения.
Это уже некий прогресс. Итак, ты признал, что ссылку внутрь приложения (в твоем понимании) можно и для десктопных дать. Теперь ссылки считать начали.
OK, посчитаем
Мне действительно придется дать одну ссылку на EXE. Это верно. Но вот насчет того, что ссылок будет 2 — не согласен. Больше их будет. И у тебя и у меня
Эта программа, о которой мы говорим — она что, одноразового использования ? Меня вполне устраивает одноразовая посуда, а вот одноразовые программы мне не нужны.
Предположим, что пользователь будет с этой программой работать N раз. Тогда
И несчастный пользователь должен теперь их по одной открывать. Потому что иного способа в броузере не предусмотрено.
И кстати, за каким богом ты мне каждый раз, как попугай, повторяешь http://www.wikimapia.org ? Я это давно уже помню, собственно, мы с тобой о других приложениях и не говорим. Нельзя ли линки впредь без этого слать ?
А если он хочет все эти locations в одном окне открыть ? Типа того, чтобы открылось окно, включающее в себя все эти locations, чтобы можно было сориентироваться. Не выйдет.
А десктопное приложение никакой командной строкой пользоваться бы не стало. Записать все locations в XML, например, файл, и его послать. В нем заодно и сказано, как рекомендуется открывать — в одном окне (табе) или каждое в своем. Приложение его анализирует, и если требуется в одном и это технически исполнимо — делает. И сделает этот XML файл — само же приложение
Итого у тебя N ссылок, да еще нужно каждую вручную открывать а у меня 1 (один) файл.
(В скобках. А презренный десктопный flashget умеет- таки из окна броузера все ссылки вытащить и одним действием пользователя закачку по всем линкам устроить. Да еще дает мне возможность отобрать только нужные из них).
S>Польза второго — крайне ограничена.
Именно. Польза от таких решений крайне ограничена. Примитив. Для того, чтобы Google Earth стало не занятной игрушкой, а чем-то полезным, очень много надо добавить
S>Так это же замечательно! С каких пор "малый объем работы для реализации приложения" становится недостатком платформы?
В огороде бузина, а в Киеве дядька. При чем тут платформа ? Речь просто шла об объеме работы, необходимом для курсовой.
S>Это у тебя так браузер выглядит. У других людей он выглядит по другому. К примеру, по дефолту в IE7 есть только адрес бар и строка с табами.
Кому что нравится.
PD>>Ну-ну. Виноваты кривые руки того, кто это сделал не в соответствии со стандартом Merge Menu. В 99.9% случаев это все нормально работает, а ты нашел ошибку и на этом основании делаешь далеко идущие выводы. S>Кто сделал что? Word 2007?
Не знаю, кто именно, но что имеет место, ясно — какая-то нестыковка старых и новых правил. Проще говоря, кто-то что-то не додумал.
PD>>Что за чушь ? Я ему про Фому, а он мне про Ерему. Я ему про то, что тулбар, коли он есть , и меню, коли оно есть, должно быть сделано по стандартам системы , а он мне — а ведь можно и без меню и без тулбара обойтись. PD>>Можно. И на google для этого идти не надо. FAR запусти. Нет там тулбара. И не будет S>Ну и отлично. Какие тогда претензии к wikimapia? Или FAR — это плохое приложение?
Ну и аргументы! Если у FAR'а нет тулбара (консольное приложение с тулбаром — это круто!), то стало быть, у других приложений тулбар(меню) можно делать как бог на душу положит!
PD>>Какое мне дело до того, какое именно меню викимапии нужно ? Не нужно ей — так не нужно. Я тебе про то, что меню, коль оно нужно (а то, что оно нужно — см хотя бы www.rsdn.ru) не должно быть в странице, а должно быть там , где ему положено, а он мне — а зачем викимапии меню! S>Ну да, ты же викимапию критикуешь? Или ты просто все свои комплексы относительно приложений собрался высказать?
Я не столько ее критикую, сколько отмечаю, что по стандартам десктопных приложений она очень и очень примитивна. Может, это действительно очень хорошее web-приложение, но это лишь говорит о том, насколько web-приложения пока что далеки по качеству от десктопных. Если угодно, я могу просто так, не думая, еще несколько замечаний накидать
1. Выделение области курсором мыши (об этом я уже говорил)
2. Best fit in window. Выделяем курсором мыши, нажимаем кнопку, и выделенная область оккупирует все текущее окно наилучшим образом, т.е с автоматическим выбором зума
3. Сохранение locations. Вот, к примеру, собираешься ты в Омск. И я хочу тебе сообщить о ряде мест, которые стоит посетить. Пощелкал я в разных местах, сделал подписи (которые никого, кроме нас с тобой, не касаются), сохранил все это в файл, и этот файл тебе переслал. Ты его открыл , и в окне крестиками помечены разные места, с подписями.
4. Координатную сетку нанесите! И так, чтобы убрать можно было.
5. Расстояния. Ткнул мышкой в одно место, ткнул в другое и показали, сколько между ними метров или километров.
Ну и т.д.
S>>>Меню на JS реализуются гораздо более продвинутые, чем на Windows API. Я custom draw в свое время очень близко изучал, так что знаю что к чему. PD>>Ай-яй-яй! Ты про owner draw меню когда-нибудь слышал ? S>Конечно слышал. Это предыдущая технология, на смену которой и пришло custom draw для toolbar controls. Павел, просто поверь на слово — я все эти штуки на брюхе прополз от и до.
S>Ну вот ява и есть это решение. "недавно студент показывал"... Этой технологии больше 10 лет. Увы, не сыграла. S>Даже джава приложения, загружаемые из браузера, не сыграли. Потому, что не отвечает эта "прямая архитектура" реальным потребностям. А вот веб-приложения, сделанные на смешном джаваскрипте и без тулбаров в браузере, прямо-таки жгут напалмом.
S>Кстати, Print Screen — наиболее нормальный вариант. И наиболее близкий к аналогу от десктопного приложения.
Ну и ну! Посоветуй это авторам Photoshop, AutoCad и т.д.
PD>>Конечно, если приложение этого не позволяет, ты этого не сделаешь. И если в нем нет никаких картинок, а есть только форма с кнопками и т.д, то, конечно, этого там нет. S>Ну так о чем речь? Нет таких приложений в природе.
Чего нет в природе ? Приложений, которые позволяют картинки просматривать, мышкой куски выделять и Ctrl-Ins делать ?
Держи
http://www.irfanview.com/
PD>>Но если в программе есть картинки, и есть смысл выделять и сохранять куски изображения, то выделение резиновым контуром и сохранение в клипбоард делается за полчаса. Я это упражнение даю студентам на 2 месяце курса по Win32. Приезжай в Омск, я тебя к ним отведу, они тебе расскажут , как это делается и покажут все. S>Гы-гы. Ну ладно, я пожалуй подожду от тебя релиза Earth.exe с этой функциональностью. За полчаса для резинового контура, плюс, сталобыть, три недели на "показ картинок". Ок. Жду. Вернемся к вопросу в конце мая.
Да бога ради. Открой финансирование, обсудим, сделаю Ну и , конечно, с тебя документация по протоколу получения этих картинок. Я их из пальца не высосу, своего спутника у меня нет.
S>Выделение резиновым контуром и сохранение картинки в веб приложении делается не намного сложнее, чем в win32.
Вот и сделайте.
PD>>При том, что весь этот www.wikimapia.org есть попросту viewer битовых карт с зумом и скроллингом. S>На таком уровне любое десктопное приложение суть всего лишь стейтмашина для обработки потока Windows сообщений.
Я тебя более страшную вещь скажу. Любое приложение (хоть web, хоть не web) — есть просто набор команд, выполняемых CPU.
>И что? Вопрос-то в том, каких карт.
Именно. Все хорошее в этой wikimapia — это предметная область. Потому что таких карт ни у кого больше нет. В этом и состоит действительная ценность. А в остальном — карты как карты, картинки то есть, и вьюер как вьюер, примитивный довольно-таки.
>Кстати, там не только зум и скроллинг. А еще и показ user-defined объектов.
Ай-яй-яй! Нарисовать некоторое количество прямоугольников белым цветом с прозрачным фоном и текстом поверх картинок — это, конечно, выдающееся достижение для web-приложения, но, скажу тебе по секрету, WHITE_BRUSH, NULL_PEN и TextOut были еще в Windows 3.0, а может, и в Windows 1.0.
PD>>OK. Тогда у меня просьбочка небольшая. Нельзя ли на базе веб-приложений приличный на уровне пусть не Word, но хоть WordPad текстовый редактор сюда встроить вместо того, в котором я это пишу. Когда тут нормальный WYSIWYG будет, с цветами и шрифтами? S>Когда у нас появится время его прикрутить. Никакой принципиальной проблемы в этом нету. См. напр. Outlook Web Access.
Ну что же, раз нет принципиальной проблемы — будем ждать от web-программистов, когда они нам продемонстрируют web-продукты, сравнимые по возможностям с соответсвующими десктопными приложениями. С Photoshop и AutoCad, Media Player и WinAmp, Word и Excel, Power Point и Corel Draw. Так, чтобы можно было из файлов в эти приложения сохраненные объекты загружать, править, сохранять, из одного в другое приложение передавать через Clipboard или Drag & Drop. Чтобы мог я в web-Excel табличку соорудить, там же ее просчитать, лкгким движением руки в web-Word вставить, и чтобы она там в WYSIWIG была. Чтобы мог я в этом самом броузерном окне всякие разные ppt, wmv, mpg, avi, xls, doc просматривать без того, чтобы презренное десктопное приложение запускать.
И чтобы в этих продуктах ActiveX не использовались! Потому что используя ActiveX, вы теряете свое единственное преимущество — платформонезависимость. Более того, с ActiveX у вас даже хуже получится — десктопные приложения хоть под любой версией Windows работают, а ActiveX — только в IE. Так что будьте добры все это на своем JavaScript и делать. Потому что ничего другого на стороне клиента у вас и нет...
Вот когда сделаете — тогда я публично признаю свою неправоту. А до тех пор мне беспокоиться не о чем.
А в заключение — пара вопросов.
Не подскажешь ли, как мне определить версию web-приложения ? Для десктопных — все ясно, само сообщит. Вот сделал я продукт, версия 1.0, выпустил его в мир. Если хоть один байт я в нем поменяю, я его выпущу под номером 1.1 или 1.01. И если пользоователю мое изменение в 1.01 не понравится, он может вернуться обратно к 1.0 .
А как быть с web-приложением ? Оно, пока я спал, никак не изменилось ? А если да — почему мне не сообщили ? Мне, может, совсем не все равно. А если мне не понравилось — как к прежней версии вернуться ?
И последний вопрос. Настольное приложение, после того, как я его скачал — навсегда у меня. Даже если автор его давно им не занимается или вообще помер. А что мне делать, если мое любимое web-приложение вдруг исчезнет из сети ? Кому жаловаться ?
Здравствуйте, Mamut, Вы писали:
M>Наткнулся вот на такое: http://blog.blist.com/index.php/2008/01/30/blist-demo-08-launch-video/ (видеопрезентация)
M>Подумалось... Все же люди начинают делать веб-приложения с упором на слово приложение, несмотря на всю кривизну HTML+CSS+Javascript. Предстоит нам бум таких приложений или все же нет?
Пока в основе будет лежать HTML и броузер, все останется как есть. Попытка с негодными средствами.
Здравствуйте, VGn, Вы писали:
VGn>Т.е. если мы отказываемся от листания, истории и закладок, мы должны отказаться о мультибраузера как такового
Именно. Инструмент, изначально предназначенный совсем для других целей (свободное блуждание между статическими тогда страницами) стал использоваться для разработки интерактивных приложений со своей логикой, в общем, не имеющей никакого отношения к свободному блужданию.
>либо он должен сам отключать доступность этих действий в отношении нашего приложения по нашему же желанию.
Или так, хотя это паллиатив. Не это — так другое. Back и history просто очень уж на виду. А как насчет других опций Интернета, которые могут повлиять на поведение приложения ? Например, запрет/разрешение кэширования страниц на локальном диске...
VGn>При существующих реалиях выхода только 2: VGn>- описанная суррогатная поддержка листания,
Вот этот суррогат и живет пока что.
VGn>- отказ от мультибраузера, т.е. заключение движка браузера в собственном лёгком клиенте с подвластным нам интерфейсом.
Нет. В идеале — отказ от браузера как такового, потому что он не нужен. Не нужен же тебе браузер в десктопных приложениях ? И тут не нужен. Не для того он.
Решил еще раз вернуться к твоему примеру
S>Рассмотрим эти особенности повнимательнее. Вот, к примеру, пользователь набирает в браузере maps.google.com. S>Благодаря а) у него на машине волшебным образом образуется замечательный клиент, который умеет обращаться к картографическому сервису гугла. Этот клиент конечно ограничен по своим возможностям, но большинство существующих, к примеру, Delphi приложений не дотягивают до его функционала на века.
Ладно, Delphi оставим в покое, все же, похоже, уходящая технология.
И по твоим словам, это очень хорошее 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-приложений.
Здравствуйте, GlebZ, Вы писали:
GZ>Простота распространения как в Web + нормальный адекватный интерфейс + нормальный доступ к ресурсам локального компа. Но это мечты.
Почему мечты? WPF + ClickOnce либо Swing + JavaWebStart.
... << RSDN@Home 1.2.0 alpha rev. 796 on Windows Vista 6.0.6001.65536>>
M>>Подумалось... Все же люди начинают делать веб-приложения с упором на слово приложение, несмотря на всю кривизну HTML+CSS+Javascript. Предстоит нам бум таких приложений или все же нет?
PD>Пока в основе будет лежать HTML и броузер, все останется как есть. Попытка с негодными средствами.
Здравствуйте, Mamut, Вы писали:
M>>>Подумалось... Все же люди начинают делать веб-приложения с упором на слово приложение, несмотря на всю кривизну HTML+CSS+Javascript. Предстоит нам бум таких приложений или все же нет?
PD>>Пока в основе будет лежать HTML и броузер, все останется как есть. Попытка с негодными средствами.
M>Пока не видно годных средств
На самом деле Java Applet концептуально это то что нужно для UI productive application. Или близко к тому.
Я бы сделал ревизию AWT, принципы security policy пересмотрел бы и/или сделал бы local storage.
Базовые идеи Java Applet работали и работают. [network]ClassLoader как концепт, это вообще замечательная идея.
В принципе Silverlight v.2.0 это по большому счету реинкарнация идеи Java Applet. Может быть с другим акцентом/креном но представляется сходной конструкцией.
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 могу меняться со временем. И какое это вообще к архитектуре отношение имеет ? Если поменять листбокс на листвью — что, архитектура изменится ?
Здравствуйте, 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, и практически все. Остальные проблемы кладем на сервак. Ну про недоверие эксплорера и виндов к коду — выполняющемся на нем, я не говорю.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Заходим вот сюда, как ты и рекомендовал
PD>http://www.wikimapia.org/#lat=54.769231&lon=83.101251&z=18&l=1&m=a&v=2
PD>И по твоим словам, это очень хорошее web-приложение, использующее правильный подход к построению web-приложений в отличие от неправильного подхода, который также бывает.
Совершенно верно.
PD>Не спорю, хорошее web-приложение. С удовольствием на свой дом посмотрел. Я, правда, и раньше Омск с высоты птичьего полета не раз видел — самолеты в Омске садятся и взлетают прямо над центром города
Вообще-то ссылка была на Бердск.
Судя по твоим другим комментариям, ты так и не понял, чем отличается ссылка на приложение от ссылки внутрь приложения. PD>web-приложение хорошее. А теперь давай оценим его с точки зрения пользовательского интерфейса. И критерии будут здесь по максимуму, то есть сравню я с хорошим UI настольных приложений.
Но прикол-то в том, что самые основные вещи твое хорошее приложение не делает: в него нельзя дать ссылку. Всё, приехали. Как выполняется прокрутка — малосущественно на фоне этого фатального недостатка. Но я все же откомментирую эти нерелевантные придирки.
PD>Во-первых, отмечу, что с технической точки зрения это не бог весть что по сложности реализации. Подумаешь — картинки рисовать квадратно-гнездовым способом со скроллингом и зумом. Дайте только источник этих картинок (сокет, к примеру), ну и областей там прямоугольных с их названиями. Пожалуй, такую работу я бы не принял в качестве курсовой на 3 курсе — маловато для курсовой.
А что, мерилом работы мы непременно считаем усталость? Типа если не задолбался — не считается? PD>Теперь о UI. PD>Органы управления (ползунок с зумом и стрелки) находятся не на своем месте. Они расположены в клиентской области и заслоняют часть изображения. Им место не здесь, а на тулбаре.
Кто это сказал? Во-первых, они занимают очень мало место относительно площади экрана. Тулбар с ними отожрал бы больше. PD>Тут неделю назад получил я частное письмо от одного RSDN-овца с просьбой помочь. Ему нужен тулбар, который встраивался бы в IE, Mozilla, Opera... Он нашел на RSDN мой постинг 3-летней давности и попросил совета.
Павел, а какое отношение это имеет к веб-приложениям? Браузер для веб-приложений — это то же самое, что Windows для десктопных. Ок, давай я тоже напишу тебе частное письмо и спрошу, как мне встроить свою таску в modern view контрольной панели в Windows XP? Ты уверен, что решение, которое ты предложишь, будет совместимо с vista и win2k? Нет? PD>Что я мог ему ответить ? Если бы тулбар для десктопных приложений — да бога ради, хоть на Win32, хоть на MFC, хоть на Delphi, да даже на .Net. Но ему нужно тулбар, встраиваемый в броузеры. PD>Про разработку тулбаров для IE я краем уха слышал. Если покопаюсь — может, разберусь за некоторое время. Не уверен, правда, что тулбар для IE7 будет работать для IE6. PD>Но вот в чем совершенно уверен — это в том, что для Mozilla придется начинать все сначала, а про ее тулбары я слышал краем от края уха. Опера — вообще не знаю. Сафари ? Вы что, издеваетесь ? PD>И при этом речь идет все же о исполняемом (x86) коде, неком плагине, который встраивается в броузер и не зависит от страницы.
Ок, простим это отступление от темы. PD>А как насчет модификации тулбара IE из HTML страницы ?
Не надо этого делать. Зачем приложению тулбар IE? Все попытки манипулировать чужими тулбарами — ересь и дебилизм. Возьмем, к примеру, OLE. Вот уж где раздолье для Merge Menu и прочего. И что? Посмотрим на Ворд 2007, поредактируем в нем ембеднутую Visio-картинку. Упс! Визио некуда встроить своё убогое меню. Потому, что в новом ворде устройство интерфейса поменялось. Кто виноват? Правильно, Visio и OLE.
Когда разрабатывался OLE, интерфейс приложения не мыслился иначе как комбинация меню и тулбаров. Самые смелые педеровики производства рисковали высказывать мысль, что меню — это тоже такой тулбар, только без картинок.
Спустя меньше двадцати лет выяснилось, что огромный класс приложений прекрасно живут безо всяких тулбаров. Павел, не бойся, зайди на google.com — нахрена ему тулбар? А между тем, это приложение умеет делать очень много всего, и всё это прекрасно работает. Может быть, есть претензии к UI google.com? Нет, это общепризнанно передовой пользовательский интерфейс.
PD>Пойдем дальше. Меню.
PD>Открыть новое окно броузера без верхнего меню — раз плюнуть, а вот можно ли его убрать в текущем окне броузера — не знаю, не видел такого. А хотелось бы вместо этого меню, которое вообще ни к чему на www.wikimapia.org, иметь то меню, которое для этой страницы наиболее подходит.
Например, какое? Всё меню викимапии доступно в викимапии. И ведет себя так, как должно. PD>Как насчет модификации меню любого броузера из страницы, а ?
Если страница даже ухитрится поменять меню браузера, то никто этого не заметит. Просто потому, что пользователь, когда пользуется страницей, смотрит на страницу, а не на меню. PD>В результате имеем, что имеем. Когда на странице нужно меню, его начинают из подручных средств изготавливать. Из гиперлинков, проще говоря, с JavaScript, чтобы эффект выпадения подменю сделать. Каждый на свой лад делает. ДОСовские времена напоминает, когда каждый свое меню изобретал (помнишь меню Лексикона, ранних версий Нортон Утилит, Supercalc ?). Причем ранние ДОСовские времена — в поздние времена были уже Turbo Professional, Turbo Vision...
Как ни парадоксально, именно веб показал, что не обязательно делать весь UI совершенно одинаковым, как военная форма. Достаточно иметь близкие концепции — и у людей не будет трудностей с освоением.
Меню на JS реализуются гораздо более продвинутые, чем на Windows API. Я custom draw в свое время очень близко изучал, так что знаю что к чему.
PD>Дальше пойдем. Правая кнопка, контекстное меню.
PD>В обычном окне броузера там — сам знаешь что. Причем, конечно, в разных броузерах по-разному. И даже в одном броузере зависит от того, где щелкнешь. И большая часть пунктов никакого отношения к текущей странице не имеет. Вот, например, есть там у меня Download All with Flashget. PD> Это мне туда Flashget вставил.
Сочувствую. Это я по поводу флешгет — я им уж лет шесть не пользуюсь примерно. Браузер и так всё качает совершенно волшебно. PD>Хорошее дело, если речь идет просто о странице со ссылками, а вот на www.wikimapia.org оно нужно ? Земной шар себе перекачать ? Не нужно. Поэтому на www.wikimapia.org это контекстное меню отключили вообще. Правильно, конечно, сделали, но почему бы вместо него свое не установить ? Пустяковая, прямо вам скажу, работа для десктопных приложений. А для броузера как ? Чтобы в любом броузере работало! Ась ?
Могли и установить. Насчет десктопных приложений — ты сначала сделай контекстное меню, чтоб работало хотя бы на винде/маке/линуксе. А я посмотрю.
А вот вебных меню, работающих в 97% браузеров, я встречал. Десктопу до такого покрытия еще развиваться и развиваться.
PD>Дальше пойдем. Вот нашел я свой дом и захотел этот кусочек себе на память вытащить. Попробовал мышкой выделить регион для последующего Ctrl-Ins — не выделяется. PD>Вместо этого карта сдвигаться начинает. Ладно, допустим, это так задумано — не давать мне возможности грабить куски (хотя и непонятно, зачем).
Нет, задумано это для другого — просто panning в этом приложении используется значительно чаще, чем selection.
PD>Пойду-ка я на другую страницу (http://www.google.ru/). Лого там у них сверху красивое. Хочу кусочек из него вырезать и сохранить. Нет, тоже не получается. Придется мне эту картинку целиком сохранить, а потом (ай-яй-яй) запустить некий десктопный графический редактор, чтобы вырезать нужный кусок.
Ок, покажи мне, как ты вырезаешь картинку из десктопного приложения. Придется тебе целиком всё окно сохранить, через Alt+PtScr, а потом (ай-яй-яй) запустить некий десктопный графический редактор, чтобы вырезать нужный кусок.
PD>Обложился. Все прекрасно, все угрозы с RSDN блокированы. Да вот беда — что-то www.wikimapia.org тоже работать перестала. Не показывается карта, хоть тресни. Вместо картинок одни placeholders. И показать отдельный кусок нельзя — контекстное меню-то заблокировано. М-да... Это что же за web-приложение такое, которое можно элементарно заставить не работать, поменяв ему настройки без его ведома ?
Павел, в твоем возрасте баловаться наркотой опасно для жизни. Ты меняешь настройки браузера? Ок, давай я поменяю настройки винды. Покажи мне своё вымышленное десктопное приложение? Ручаюсь, что я сломаю его в Internal Error банальными настройками секурити реестра и файлухи. При этом никакое контекстное меню работать не будет.
Поэтому этот аргумент вообще никакого отношения к реальности не имеет.
PD>Только вот мусору у меня много в Temporary Internet Files что-то скопилось. Пожалуй, сотру я его. И стер (правда, стер). PD>А тут как на грех Интернет обрушился (это уже фантазия). Печально. Ладно, пока он не работает, на карту из www.wikimapia.org посмотрю. Хм, а куда она делась ? Нет ее почему-то... Броузер пытается заново все квадраты подкачать. Это кто же у моего web-приложения текущие данные удалил и его даже в известность не поставил ?
Настойчиво повторяю призыв к здоровому образу жизни. Потому что этот пример показывает преимущества вебного приложения перед десктопным. Если убить данные настольного приложения, то оно как правило тупо ляжет. А викимапия всего лишь будет подольше грузиться.
Далее, напомню, что мы говорим о сетевых приложениях. При отключенном интернете мало какое из них сможет корректно работать.
Да, есть такая тема — occasionally connected applications, но лично я в них разочаровываюсь всё больше и больше. Например, Outlook Web Access потребляет на порядок меньше трафика, чем обычный Outlook — потому, что ему не надо "синхронизовать всю базу". Если я подключусь к своему мэйлбоксу пустым аутлуком, он наверное сутки будет развлекаться синхронизацией.
И все это ради того, чтобы дать мне сомнительную возможность "написать письма пока я в оффлайне". На практике occasionally коннектится приходится постоянно — потому что мы работаем с быстроменяющейся ситуацией, и если я не проверял почту в течение часа, то мои ответы скорее всего уже устарели.
Практически единственная область с совместной работой, которая пока что бенефитит от десктопа — это разработка софта. Хотя я начинаю подозревать, что чисто онлайновая студия была бы даже круче, чем настольная. Вот, к примеру, если у меня вдруг сдохнет комп посредине написания этого сообщения, ты его не увидишь. А если бы я писал его в GMail, то спокойно бы пересел на другую машину, и продолжил писать почти с того же места.
PD>Ладно, хватит, хотя можно бы еще столько же накатать...
PD>И при этом речь идет о хорошем web-приложении. Что уж тогда о плохих говорить ?
О плохих говорить не будем. Давайте говорить о хороших. PD>И как же быть с Delphi приложениями, которые не дотягивают до этого функционала на века ?
Предлагаю выкинуть. PD>Неужели только через 100 лет мы сумеем картинки в настольных приложениях показывать ? Ты часом не из 19 века это письмо писал ?
При чем тут картинки? PD>Попытка с негодными средствами — вот самое точное определение т.н. web-приложений.
Ну, пока что годные средства развиваются в значительной мере на основе тех же веб-приложений.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>ветки реесра я так же стираю через легальный общедоступный интерфейс
Не совсем общедоступный. На реестр должны быть права. А главное документация.
Здравствуйте, Sinclair, Вы писали:
A>>Я между прочим то же самое сказал. Я так же упомянул, что писал веб-приложение работающее с сервисом Janus'а. А также я написал, что интерфейс взаимодействия обсуждаем. S>Фишка в том, что если бы янус был веб приложением, то его можно было бы гораздо быстрее развивать. И проблемы типа "у меня F# не раскрашивается" — "поставь себе новый билд" не возникали бы в принципе.
Меня бы вполне устроило, если бы янус предлагал обновиться, а потом применял изменения без перезапуска. Сегодняшние подходы и технологии такое позволяют. Я бы не ощутил никакой разницы. Хотя да, мне не пришлось бы жать на добаный Ctrl+F5 в firefox.
Почему-то все выставляют отсутствие необходимости развертывания web-приложения как преимущество прямо-таки неповторимое.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Kisloid, Вы писали: K>Мне начинает казаться, что ваши примеры ограничиваются одними лишь maps.google.com, google docs, wikimapia, etc. Ну покажите мне редактор видео файлов с функционалом как у Adobe Premiere Pro, 3D Max, Photoshop и прочих.
K>Не говоря уж о том, что некоторый софт вообще не логично делать веб приложениями. Например хотя бы мессенджер,
Это ты случайно не про ICQ2GO? K>ну или софт для записи видео на диск.
K>Я к тому, что веб и десктоп приложения не взаимоисключают друг друга, а лишь дополняют.
Да, есть быстро сужающаяся ниша приложений, которые не получается перевести в веб.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, LaPerouse, Вы писали:
LP>Inductive UI — это когда, к примеру, приложение строится на основе мастеров? Т. е. ведущим отличием inductive от productive — это наличие состояния у productive ui? К примеру, нужно примонтировать образ диска и что-то с ним сделать. Тогда в inductive это будет сделано: нажали на одну кнопку, появился диалог, ввели путь к диску, нажали далее, диск примонтировался, выбрали действие над дисков, совершили. А в productive: нажали на кнопку, примонтировали диск. Потом нажали на другую и выбрали действие. При этом при нажатии на вторую кнопку нужно проверить, примонтирован ли диск. Я правильно понял суть?
Неправильно. Inductive — это когда программа целенаправленно ведет тебя по предписанным маршрутам, в каждый конкретный момент предоставляя возможность принять небольшое количество понятных решений. Типичный пример — банкомат. Главный плюс — не требует никаких или очень мало предварительных знаний.
В Productive же все заточено под максимально простой и удобный способ выполнения часто используемых действий, однако он требует знания того, что нужно предпринять для получения какого либо результата. Типичные фишки — хоткеи, тулбары, контекстные меню.
А есть состояние, или нет его, к делу отношение имеет весьма опосредованное.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1050 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Sinclair, Вы писали:
PD>>Не спорю, хорошее web-приложение. С удовольствием на свой дом посмотрел. Я, правда, и раньше Омск с высоты птичьего полета не раз видел — самолеты в Омске садятся и взлетают прямо над центром города S>Вообще-то ссылка была на Бердск.
Я просто про Омск написал.
S>Но прикол-то в том, что самые основные вещи твое хорошее приложение не делает: в него нельзя дать ссылку.
Поясни, что значит "нельзя дать ссылку". Я тебе привел пример с XML файлом, который перешлю тебе для указания места, который мой гипотетический настольный EARTH покажет. Что тебе еще надо ? Передать этот файл через RSDN, как ты сделал. Передай, если хочешь, простым текстом, я его возьму Ctrl-Ins, а свой EARTH сделаю clipboard viewer, который при наличии XML с определенными тегами будет его брать и показывать это место. Что тебе еще надо ?
>Всё, приехали. Как выполняется прокрутка — малосущественно на фоне этого фатального недостатка. Но я все же откомментирую эти нерелевантные придирки.
Прокрутка, конечно, мелочь, но этот фатальный недостаток просто не существует.
Найди два различия.
PD>>Во-первых, отмечу, что с технической точки зрения это не бог весть что по сложности реализации. Подумаешь — картинки рисовать квадратно-гнездовым способом со скроллингом и зумом. Дайте только источник этих картинок (сокет, к примеру), ну и областей там прямоугольных с их названиями. Пожалуй, такую работу я бы не принял в качестве курсовой на 3 курсе — маловато для курсовой. S>А что, мерилом работы мы непременно считаем усталость? Типа если не задолбался — не считается?
Усталость тут ни при чем, речь идет о объеме работы, который необходим сделать. И такое приложение я в качестве курсовой не дам — объем работы слишком мал.
PD>>Теперь о UI. PD>>Органы управления (ползунок с зумом и стрелки) находятся не на своем месте. Они расположены в клиентской области и заслоняют часть изображения. Им место не здесь, а на тулбаре. S>Кто это сказал? Во-первых, они занимают очень мало место относительно площади экрана. Тулбар с ними отожрал бы больше.
Почему это отожрал бы ? Он и так отжирает, сидит себе, где ему положено. А выше меню сидит. А еще выше строка с URL и кнопками вперед-назад. Так что добавить пару кнопок на тулбар — места никакого не надо.
S>Павел, а какое отношение это имеет к веб-приложениям? Браузер для веб-приложений — это то же самое, что Windows для десктопных.
Ну и ну! После этого о чем еще говорить! Сравнил!
PD>>Что я мог ему ответить ? Если бы тулбар для десктопных приложений — да бога ради, хоть на Win32, хоть на MFC, хоть на Delphi, да даже на .Net. Но ему нужно тулбар, встраиваемый в броузеры. PD>>Про разработку тулбаров для IE я краем уха слышал. Если покопаюсь — может, разберусь за некоторое время. Не уверен, правда, что тулбар для IE7 будет работать для IE6. PD>>Но вот в чем совершенно уверен — это в том, что для Mozilla придется начинать все сначала, а про ее тулбары я слышал краем от края уха. Опера — вообще не знаю. Сафари ? Вы что, издеваетесь ? PD>>И при этом речь идет все же о исполняемом (x86) коде, неком плагине, который встраивается в броузер и не зависит от страницы. S>Ок, простим это отступление от темы.
Да, конечно, сказать же нечего.
PD>>А как насчет модификации тулбара IE из HTML страницы ? S>Не надо этого делать. Зачем приложению тулбар IE?
Да не нужен, конечно! И впрямь, зачем ? Лучше свою пародию на тулбар (скорее меню) создадим!
>Все попытки манипулировать чужими тулбарами — ересь и дебилизм.
А использовать способность чужого приложения отрабатывать гиперлинки — не ересь и дебилизм ? Интересно ты рассуждаешь. Нашли себе контейнер, он предоставляет разные возможности, все равнодоступны юзеру, но вот пока этот юзер те возможности использует, которые нам нравятся, это хорошо, это правильно, а как он начинает другие использовать — ересь и дебилизм.
>Возьмем, к примеру, OLE. Вот уж где раздолье для Merge Menu и прочего. И что? Посмотрим на Ворд 2007, поредактируем в нем ембеднутую Visio-картинку. Упс! Визио некуда встроить своё убогое меню. Потому, что в новом ворде устройство интерфейса поменялось. Кто виноват? Правильно, Visio и OLE.
Ну-ну. Виноваты кривые руки того, кто это сделал не в соответствии со стандартом Merge Menu. В 99.9% случаев это все нормально работает, а ты нашел ошибку и на этом основании делаешь далеко идущие выводы.
S>Спустя меньше двадцати лет выяснилось, что огромный класс приложений прекрасно живут безо всяких тулбаров. Павел, не бойся, зайди на google.com — нахрена ему тулбар? А между тем, это приложение умеет делать очень много всего, и всё это прекрасно работает. Может быть, есть претензии к UI google.com? Нет, это общепризнанно передовой пользовательский интерфейс.
Что за чушь ? Я ему про Фому, а он мне про Ерему. Я ему про то, что тулбар, коли он есть , и меню, коли оно есть, должно быть сделано по стандартам системы , а он мне — а ведь можно и без меню и без тулбара обойтись. Можно. И на google для этого идти не надо. FAR запусти. Нет там тулбара. И не будет
PD>>Пойдем дальше. Меню.
PD>>Открыть новое окно броузера без верхнего меню — раз плюнуть, а вот можно ли его убрать в текущем окне броузера — не знаю, не видел такого. А хотелось бы вместо этого меню, которое вообще ни к чему на www.wikimapia.org, иметь то меню, которое для этой страницы наиболее подходит. S>Например, какое? Всё меню викимапии доступно в викимапии. И ведет себя так, как должно.
Какое мне дело до того, какое именно меню викимапии нужно ? Не нужно ей — так не нужно. Я тебе про то, что меню, коль оно нужно (а то, что оно нужно — см хотя бы www.rsdn.ru) не должно быть в странице, а должно быть там , где ему положено, а он мне — а зачем викимапии меню!
PD>>Как насчет модификации меню любого броузера из страницы, а ? S>Если страница даже ухитрится поменять меню браузера, то никто этого не заметит. Просто потому, что пользователь, когда пользуется страницей, смотрит на страницу, а не на меню.
Потому что вы приучили его туда не смотреть. Если бы при загрузке страницы, которой меню нужно, оно там бы и появлялось — смотрел бы.
S>Как ни парадоксально, именно веб показал, что не обязательно делать весь UI совершенно одинаковым, как военная форма. Достаточно иметь близкие концепции — и у людей не будет трудностей с освоением.
Как ни странно, но все развитие выч. техники вообще и UI в частности показало, что когда стандартизируются стандартизируемые элементы, то от этого пользователю только хорошо будет. Потому что какое бы приложение в Windows я не запустил, я, еще ни разу его окна не увидев, уже знаю, где у него открытие файла, где сохранение, и где хелп. И поэтому я могу не тратить свое время на то, чтобы выяснить, как это делается здесь, что мы наблюдали в старые добрые ДОСовские времена, когда впору было спецкурс по разным типам меню и работе с ними делать для пользователей.
Потому что мне как пользователю совсем не хочется тратить даже 10 секунд на выяснение этого. Это должно быть здесь, также как руль в автомобиле должен быть перед водителем, а не где-то в салоне. И все.
S>Меню на JS реализуются гораздо более продвинутые, чем на Windows API. Я custom draw в свое время очень близко изучал, так что знаю что к чему.
Ай-яй-яй! Ты про owner draw меню когда-нибудь слышал ?
S>Сочувствую. Это я по поводу флешгет — я им уж лет шесть не пользуюсь примерно. Браузер и так всё качает совершенно волшебно.
Завидую. У тебя Интернет хороший. У меня похуже, так что при закачке чего-то в 100> Мб во флашгете хлть несколько Retry да будет. А в броузере (IE7) порой просто виснет.
S>Могли и установить. Насчет десктопных приложений — ты сначала сделай контекстное меню, чтоб работало хотя бы на винде/маке/линуксе. А я посмотрю.
Вот это единственно серьезный аргумент. Я все ждал, когда ты его выскажешь. Все твои прочие рассуждения, извини, несерьезны, а вот это — да. И не меню, конечно. Сказал бы проще — ты сделай приложение, чтобы на винде/маке/линуксе работало, а потом уже и о меню, и о тулбаре и т.д. поговорим.
Не сделаю. Средств нет. Есть, конечно, Ява, мог бы я заявить, что , мол, на Яве напишу, да только мне самому стыдно будет такое говорить. На AWT я его напишу, что ли ? Убого слишком.
И здесь мы к основному подходим. Не web-приложения надо было делать, а некое решение (библиотеку, фреймворк, не знаю что), которое позволяло писать приложения для неопределенной ОС, так чтобы в реальнсти оно могло работать в любой ОС. Чтобы я мог в программе использовать абстрактный листвью, а в Windows использовался бы при этом WC_LISTVIEW, в Линукс — что там у них есть и т.д. Нет соответсвующего — эмулировался бы. Ну и программы сами чтобы работали.
Может, это решение должно было бы пойти по пути Явы (кстати, нечто подобное есть во фреймворке Эклипса, мне недавно мой студент показывал, программа на Яве, а контролы от Windows, выгляди вполне прилично). Может — по пути .Net, если бы ее перенос на другие платформы реализовался бы толком. Может, что-то вообще иное. S>А вот вебных меню, работающих в 97% браузеров, я встречал. Десктопу до такого покрытия еще развиваться и развиваться.
S>Нет, задумано это для другого — просто panning в этом приложении используется значительно чаще, чем selection.
Пусть так, а как все же selection сделать- то ? Ну хочу я очень себе на память картинку со своим домом взять. Мне теперь что, кэш браузера изучать или Print Screen нажимать ?
PD>>Пойду-ка я на другую страницу (http://www.google.ru/). Лого там у них сверху красивое. Хочу кусочек из него вырезать и сохранить. Нет, тоже не получается. Придется мне эту картинку целиком сохранить, а потом (ай-яй-яй) запустить некий десктопный графический редактор, чтобы вырезать нужный кусок. S>Ок, покажи мне, как ты вырезаешь картинку из десктопного приложения. Придется тебе целиком всё окно сохранить, через Alt+PtScr, а потом (ай-яй-яй) запустить некий десктопный графический редактор, чтобы вырезать нужный кусок.
Ну ты даешь! Сказал бы такое мой студент — я бы ему сказал все, что о его знаниях думаю!
Конечно, если приложение этого не позволяет, ты этого не сделаешь. И если в нем нет никаких картинок, а есть только форма с кнопками и т.д, то, конечно, этого там нет. Но если в программе есть картинки, и есть смысл выделять и сохранять куски изображения, то выделение резиновым контуром и сохранение в клипбоард делается за полчаса. Я это упражнение даю студентам на 2 месяце курса по Win32. Приезжай в Омск, я тебя к ним отведу, они тебе расскажут , как это делается и покажут все.
S>Павел, в твоем возрасте баловаться наркотой опасно для жизни.
Антон, прекрати, пожалуйста, свои дурацкие пассажи, иначе мне придется прекратить дискуссию. Когда аргументов нет — вот такие аргументы используют
>Ты меняешь настройки браузера? Ок, давай я поменяю настройки винды
Я уже писал , почему считаю это сравнение неубедительным.
. Покажи мне своё вымышленное десктопное приложение? Ручаюсь, что я сломаю его в Internal Error банальными настройками секурити реестра и файлухи. При этом никакое контекстное меню работать не будет.
Я тебе еще один совет дам , как его сломать. FORMAT C: Ты уж совсем глупости говорить начал.
S>Настойчиво повторяю призыв к здоровому образу жизни. Потому что этот пример показывает преимущества вебного приложения перед десктопным. Если убить данные настольного приложения, то оно как правило тупо ляжет. А викимапия всего лишь будет подольше грузиться.
А не объяснит ли уважаемый сэр, с чего это оно тупо ляжет ? Писать программы аккуратно надо, а не давать советы вроде этого
S>О плохих говорить не будем. Давайте говорить о хороших. PD>>И как же быть с Delphi приложениями, которые не дотягивают до этого функционала на века ? S>Предлагаю выкинуть.
Delphi или Web ? Кстати, лет 10 назад я участвовал в проекте на Delphi 5 с весьма серьезной графикой, двумерное моделирование трехмерных объектов, проще говоря — Fashion mapper, посмотреть, как на данном человеке будет рубашка выглядеть, если такую-то ткань употребить.
PD>>Неужели только через 100 лет мы сумеем картинки в настольных приложениях показывать ? Ты часом не из 19 века это письмо писал ? S>При чем тут картинки?
При том, что весь этот www.wikimapia.org есть попросту viewer битовых карт с зумом и скроллингом.
PD>>Попытка с негодными средствами — вот самое точное определение т.н. web-приложений. S>Ну, пока что годные средства развиваются в значительной мере на основе тех же веб-приложений.
OK. Тогда у меня просьбочка небольшая. Нельзя ли на базе веб-приложений приличный на уровне пусть не Word, но хоть WordPad текстовый редактор сюда встроить вместо того, в котором я это пишу. Когда тут нормальный WYSIWYG будет, с цветами и шрифтами ? И за каким богом я должен для предпросмотра отсылать текст в Москву, чтобы мне его тут же вернули обратно ? Утверждаете Вы его там, что ли ? Для справки — у меня Dual Athlon 4200+ и 2 Gb памяти, и я выражаю уверенность, что этого вполне достаточно, чтобы отформатировать 3 Кб текста на моей машине без помощи сервера.
Left2 wrote:
> K>>Я к тому, что веб и десктоп приложения не взаимоисключают друг друга, > а лишь дополняют. > S>Да, есть быстро сужающаяся ниша приложений, которые не получается > перевести в веб. > Я бы даже сказал "пока не получается". Вон, ещё 5 лет назад все бы > посмеялись если бы им рассказали об Excel-таблице в веб-браузере. А > сейчас думаю MS уже становится не смешно при виде Google Docs 2D графика > вон тоже потихоньку перелазит, думаю в ближайшем будещем стОит ждать и 3D. http://wiki.mozilla.org/Canvas:3D http://canvex.lazyilluminati.com/
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Mamut, Вы писали:
M>Какие десктоп-приложения это умеют делать? maps.google.com это умеет
M>Похожая функциональность давно в google docs, например, есть
M>maps.google.com
Мне начинает казаться, что ваши примеры ограничиваются одними лишь maps.google.com, google docs, wikimapia, etc. Ну покажите мне редактор видео файлов с функционалом как у Adobe Premiere Pro, 3D Max, Photoshop и прочих.
Не говоря уж о том, что некоторый софт вообще не логично делать веб приложениями. Например хотя бы мессенджер, ну или софт для записи видео на диск.
Я к тому, что веб и десктоп приложения не взаимоисключают друг друга, а лишь дополняют.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
K>Нет, во-первых я хочу, чтобы мой мессенджер сидел в трее (icq2go так умеет?). K>Во-вторых запускать еще один экземпляр браузера только ради одного мессенджера не хочу. K>В третьих, это что за нездравая мания, пытаться все запихать в веб?
K>Вот тот самый ваш любимый гугл, который все время приводится в пример, почему-то google talk сделал не веб приложением.
Есть возможность общаться напрямую из GMail'а
Никто и не говорит, что прямо таки все надо запихать в веб. Но есть приложения, которые ложатся в веб идеально, отлично и/или очень хорошо
Здравствуйте, Mamut, Вы писали:
M>Подумалось... Все же люди начинают делать веб-приложения с упором на слово приложение, несмотря на всю кривизну HTML+CSS+Javascript. Предстоит нам бум таких приложений или все же нет?
Как всегда все прогнозы о серебряных пулях не оправдались. Ныне есть полный спектр решений и технологий от всяких аяксовых приблуд типа google mail, через online и occasionally connected смартклиентов, и до классических приложений вроде офиса. В каждом конкретном случае можно выбрать оптимум. Что еще нужно для полного счастья?
... << RSDN@Home 1.2.0 alpha rev. 790 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Как всегда все прогнозы о серебряных пулях не оправдались. Ныне есть полный спектр решений и технологий от всяких аяксовых приблуд типа google mail, через online и occasionally connected смартклиентов, и до классических приложений вроде офиса. В каждом конкретном случае можно выбрать оптимум. Что еще нужно для полного счастья?
Простота распространения как в Web + нормальный адекватный интерфейс + нормальный доступ к ресурсам локального компа. Но это мечты.
Здравствуйте, Mamut, Вы писали:
M>>>Подумалось... Все же люди начинают делать веб-приложения с упором на слово приложение, несмотря на всю кривизну HTML+CSS+Javascript. Предстоит нам бум таких приложений или все же нет?
PD>>Пока в основе будет лежать HTML и броузер, все останется как есть. Попытка с негодными средствами.
M>Пока не видно годных средств
Не видно понимания, какими должны быть эти средства.
А будет понимание — средства появятся.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
AVK>>>Гы, черточка, гы. Под это определение можно подогнать абсолютно любой плагин для расширения возможностей UI. Например тот же XUL runner. В таком раскладе я конечно согласен — и аплеты, и SL, и Flash/Flex/Как_там_он_сейчас_называется, и XUL, и дотнетный System.Windows.Forms.UserControl и даже ActiveX — одна фигня.
CS>>Абсолютно верно. Концептуально это одно и то же
AVK>Все понятно. Дальше продолжать разговор смысла нет.
А чего начинал-то тогда ? Сказать чего хотел в тему топика или так просто?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Mamut, Вы писали:
M>>Решена ли эта проблема для SL, который в виде плагина к FF, Safari, Opera?
AVK>Решена. Состояние, разумеется, хранить нужно будет на сервере или в URL, это уже ограничения собственно модели браузера.
Еще раз, что конкретно решено из этих проблем:
1) Applet получает нотификацию от том что page goes out of view but not destroyed.
2) У тебя есть возможность дифференцировать ситуацию что пользователь ушел вообще или Карлсон обещал вернуться?
?
Я утверждаю что ничего не решено из-за именно "ограничения собственно модели браузера".
"Состояние, разумеется, хранить нужно будет на сервере или в URL" — это не решение в большинстве практических случаев.
Я готов выслушать способ сохранения состояния скажем <div contenteditable="true"> в url или хотя бы на сервере.
Под состоянием имеется ввиду например стек undo/redo операций, selection и пр.
Также очень интересует собственно реализация способа посылки состояния на сервер.
Скажем в событии SL onunload (какие еще кстати есть события на тему page-goes-out-of-view?) каким образом
предполагается посылать сообщения на сервер? Через асинхронный Ajax request? Если "да" то кто получит нотификацию о завершении?
Частичным решением могло бы быть client side storage. Но этого нет ни в silverlight ни в Java Applet ни в Flex.
Есть попытка решить сие в Google Gears но опять же до стека undo/redo операций не добраться вообще.
Здравствуйте, VGn, Вы писали:
VGn>Это нынешний тренд развития тонких клиентов.
Нынешний тренд это смартклиенты — т.е. приложения с богатым интерфейсом, наличием кастомной логики на клиенте, наличие персистентного кеша для данных в клиенте и, по возможности, occasionally connected режим. Ну, к примеру, Google Earth.
... << RSDN@Home 1.2.0 alpha 3 rev. 883 on Windows Vista 6.0.6001.65536>>
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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>Да, но только эти "определённые преимущества" мы получим в обмен на вполне конкретное преимущество незнания сервера о клиенте. И вместо того, чтобы знать только об интерфейсе взаимодействия с клиентом, серверу нужно будет знать и его внутренее устройство. Можно сказать, что в данном случае нарушается свойство инкапсуляции клиента. (:
Ну, в таком случае мы плавно переходим к вопросу о способах проектирования веб сервисов.
Существующая архитектура веб приложений удовлетворяет всем требованиям. Хочешь инкапсулированного клиента — вот тебе инкапсулированный клиент.
Хочешь комбинированный сервер с клиентом — вот тебе комбинированный сервер с клиентом.
Да, современные веб-приложения как правило выигрывают от разделения сервиса и клиентской части.
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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Меня не интересуют детали. Вот представь себе , что вся работа идет по одному урлу. Вначале запрашиваем эту страницу (GET). Потом посылаем обратно данные (POST). Потом эта страница опять приезжает сюда в несколько ином виде , так ?
Нет. Зачем мне представлять, что "вся работа идет по одному урлу"? Это противоречит базовой концепции веб-приложений — "адресуемости". PD>Потом POST опять. И т.д. Зачем все эти пересылки ? PD>Только не надо мне про кеширование на стороне клиента говорить.
S>>Павел, я надеюсь вы научитесь отличать неудачные ASP.NET приложения от хороших веб-приложений. PD>Не-а. Не сумею, так как при "броузерной" архитектуре последних просто быть не может
Павел, я по прежнему продолжаю не понимать, почему ты выбираешь какие-то плохие примеры, и заявляешь, что хороших приложений не бывает.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, artelk, Вы писали: A>Напрягает, что общение между клиентом и сервером осуществляется в терминах событий представления. Типа: нажали такую-то кнопку, выбрали в комбобоксе другой пункт и т.п. Причем каждый раз с клиента отправляется все состояние представления — viewstate, значения во всех контролах (должен же сервер знать все что содержиться в представлении!.. ). Вся эта страничка воссоздается на сервере, вызывается наконец-то обрабочик этого события, формируется новая страница и отправляется клиенту... Не могу понять, почему это кем-то считаеться правильным?!
Это никем не считается правильным. Учись делать хорошие веб-приложения, а не тяп-ляп-говно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>Любое десктоп-приложение будет вести себя похоже, за исключением некоторых примитивных. Предлагаю поупражняться в удалении веток из реестра, например
Ага, ты еще посоветуй долбонуть по системнику кувалдой. Изменение настроек браузера и удаление веток реестра не одно и то же. Изменение настроек браузера можно сравнить с изменением настроек десктоп приложения.
Ну или если рассматривать все вот с такой точки зрения, что браузер является хостом для твоего веб приложения, а ОС для твоего десктоп приложения. Изменения настроек браузера делаются в Tools -> Internet Options, а настройки ОС в Control Panel. Я почему-то сомневаюсь, что изменения настроек в Control Panel как-то негативно воздействуют на мое десктоп приложение, а вот насчет Internet Options, уверен на 90%.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали: K>Круто
А то. Вот это — пример компонента для хорошего приложения. S>>
K>Интересно что бы это значило? Просто тебя послушаешь, веб это наше все, все остальное отстой и убожество.
Ничего подобного я не говорил. Я просто пытаюсь защитить веб приложения от людей, которые по скудоумию считают их "костылями", "кривой архитектурой" и "негодными средствами". K> Будто десктопные приложения это прошлый век Или я ошибаюсь?
Ну, смотря для чего. За нишу occasionally connected приложений борьба всё еще идет. А вот, к примеру, десктопное CRM приложение сейчас имеет мало шансов на успех. Не поймут-с.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Прокрутка, конечно, мелочь, но этот фатальный недостаток просто не существует.
PD>Поясняю еще раз. На пальцах.
PD>Ты — ссылка имеет вид
PD>http://www.wikimapia.org/#lat=54.769231&lon=83.101251&z=18&l=1&m=a&v=2
PD>Так ?
PD>Я : ссылка имеет вид PD>EARTH.EXE /#lat=54.769231&lon=83.101251&z=18&l=1&m=a&v=2 PD>(или в XML) PD>Найди два различия.
Первая — работает. Вторая — нет. Какие еще отличия нужны?
Получается, что ты будешь давать 2 (две) ссылки: одну на само приложение, вторую — на файл с данными для приложения.
Польза второго — крайне ограничена.
S>>А что, мерилом работы мы непременно считаем усталость? Типа если не задолбался — не считается? PD>Усталость тут ни при чем, речь идет о объеме работы, который необходим сделать. И такое приложение я в качестве курсовой не дам — объем работы слишком мал.
Так это же замечательно! С каких пор "малый объем работы для реализации приложения" становится недостатком платформы?
PD>Почему это отожрал бы ? Он и так отжирает, сидит себе, где ему положено. А выше меню сидит. А еще выше строка с URL и кнопками вперед-назад. Так что добавить пару кнопок на тулбар — места никакого не надо.
Это у тебя так браузер выглядит. У других людей он выглядит по другому. К примеру, по дефолту в IE7 есть только адрес бар и строка с табами.
S>>Павел, а какое отношение это имеет к веб-приложениям? Браузер для веб-приложений — это то же самое, что Windows для десктопных. PD>Ну и ну! После этого о чем еще говорить! Сравнил!
А в чем проблема?
PD>А использовать способность чужого приложения отрабатывать гиперлинки — не ересь и дебилизм ? Интересно ты рассуждаешь. Нашли себе контейнер, он предоставляет разные возможности, все равнодоступны юзеру, но вот пока этот юзер те возможности использует, которые нам нравятся, это хорошо, это правильно, а как он начинает другие использовать — ересь и дебилизм.
Не очень понятно, какие "другие" возможности имеются в виду. Фишка именно в том, что есть встроенные возможности браузера, это как бы программа-минимум для веб приложения. Кнопки Back и Forward, возможности Save as и Print, управление безопасностью — всё это является общими возможностями. Частные возможности веб приложений
реализуются внутри окна браузера.
>>Возьмем, к примеру, OLE. Вот уж где раздолье для Merge Menu и прочего. И что? Посмотрим на Ворд 2007, поредактируем в нем ембеднутую Visio-картинку. Упс! Визио некуда встроить своё убогое меню. Потому, что в новом ворде устройство интерфейса поменялось. Кто виноват? Правильно, Visio и OLE.
PD>Ну-ну. Виноваты кривые руки того, кто это сделал не в соответствии со стандартом Merge Menu. В 99.9% случаев это все нормально работает, а ты нашел ошибку и на этом основании делаешь далеко идущие выводы.
Кто сделал что? Word 2007?
PD>Что за чушь ? Я ему про Фому, а он мне про Ерему. Я ему про то, что тулбар, коли он есть , и меню, коли оно есть, должно быть сделано по стандартам системы , а он мне — а ведь можно и без меню и без тулбара обойтись. PD>Можно. И на google для этого идти не надо. FAR запусти. Нет там тулбара. И не будет
Ну и отлично. Какие тогда претензии к wikimapia? Или FAR — это плохое приложение?
PD>Какое мне дело до того, какое именно меню викимапии нужно ? Не нужно ей — так не нужно. Я тебе про то, что меню, коль оно нужно (а то, что оно нужно — см хотя бы www.rsdn.ru) не должно быть в странице, а должно быть там , где ему положено, а он мне — а зачем викимапии меню!
Ну да, ты же викимапию критикуешь? Или ты просто все свои комплексы относительно приложений собрался высказать?
Ок, предположим, что мы рассматриваем rsdn.ru, где меню таки нужно.
Откуда взялась догма "не должно быть в странице, а должно быть там , где ему положено"? Павел, откуда? Кто тебе это сказал? Якоб Нильсен? Эдвард Тафти? Кто именно настаивает на том, чтобы все функции приложения были доступны через классическое меню.
Посмотри на офис 2007 — там меню почти нигде не осталось. Вместо него теперь сплошь и рядом ribbon, smart tags и local toolbar. Представления людей об удобном UI всё-таки несколько изменились за последние двадцать лет, и, в частности, под воздействием веб приложений. А ты всё еще пытаешься выяснить, где же именно у порш кайенн подпругу затянуть.
PD>Потому что вы приучили его туда не смотреть. Если бы при загрузке страницы, которой меню нужно, оно там бы и появлялось — смотрел бы.
Так или иначе, но проблема решена.
S>>Как ни парадоксально, именно веб показал, что не обязательно делать весь UI совершенно одинаковым, как военная форма. Достаточно иметь близкие концепции — и у людей не будет трудностей с освоением.
PD>Как ни странно, но все развитие выч. техники вообще и UI в частности показало, что когда стандартизируются стандартизируемые элементы, то от этого пользователю только хорошо будет. Потому что какое бы приложение в Windows я не запустил, я, еще ни разу его окна не увидев, уже знаю, где у него открытие файла, где сохранение, и где хелп.
Насчет "все развитие" — это ты загнул. Ты практически цитируешь работы Тео Мандела. Но этот старпер был актуален примерно в 1990 году. С тех пор выяснились новые подробности.
Как ни странно, но бурное развитие веб-приложений показало, что 100% стандартизация элементов управления не является обязательной. Достаточно соблюдать общие принципы, чтобы всё заработало.
S>>Меню на JS реализуются гораздо более продвинутые, чем на Windows API. Я custom draw в свое время очень близко изучал, так что знаю что к чему. PD>Ай-яй-яй! Ты про owner draw меню когда-нибудь слышал ?
Конечно слышал. Это предыдущая технология, на смену которой и пришло custom draw для toolbar controls. Павел, просто поверь на слово — я все эти штуки на брюхе прополз от и до.
PD>Не сделаю. Средств нет. Есть, конечно, Ява, мог бы я заявить, что , мол, на Яве напишу, да только мне самому стыдно будет такое говорить. На AWT я его напишу, что ли ? Убого слишком.
PD>И здесь мы к основному подходим. Не web-приложения надо было делать, а некое решение (библиотеку, фреймворк, не знаю что), которое позволяло писать приложения для неопределенной ОС, так чтобы в реальнсти оно могло работать в любой ОС. PD>Чтобы я мог в программе использовать абстрактный листвью, а в Windows использовался бы при этом WC_LISTVIEW, в Линукс — что там у них есть и т.д. Нет соответсвующего — эмулировался бы. Ну и программы сами чтобы работали. PD>Может, это решение должно было бы пойти по пути Явы (кстати, нечто подобное есть во фреймворке Эклипса, мне недавно мой студент показывал, программа на Яве, а контролы от Windows, выгляди вполне прилично). Может — по пути .Net, если бы ее перенос на другие платформы реализовался бы толком. Может, что-то вообще иное.
Ну вот ява и есть это решение. "недавно студент показывал"... Этой технологии больше 10 лет. Увы, не сыграла.
Даже джава приложения, загружаемые из браузера, не сыграли. Потому, что не отвечает эта "прямая архитектура" реальным потребностям. А вот веб-приложения, сделанные на смешном джаваскрипте и без тулбаров в браузере, прямо-таки жгут напалмом.
S>>Нет, задумано это для другого — просто panning в этом приложении используется значительно чаще, чем selection. PD>Пусть так, а как все же selection сделать- то ? Ну хочу я очень себе на память картинку со своим домом взять. Мне теперь что, кэш браузера изучать или Print Screen нажимать ?
Кстати, Print Screen — наиболее нормальный вариант. И наиболее близкий к аналогу от десктопного приложения.
PD>>>Пойду-ка я на другую страницу (http://www.google.ru/). Лого там у них сверху красивое. Хочу кусочек из него вырезать и сохранить. Нет, тоже не получается. Придется мне эту картинку целиком сохранить, а потом (ай-яй-яй) запустить некий десктопный графический редактор, чтобы вырезать нужный кусок. S>>Ок, покажи мне, как ты вырезаешь картинку из десктопного приложения. Придется тебе целиком всё окно сохранить, через Alt+PtScr, а потом (ай-яй-яй) запустить некий десктопный графический редактор, чтобы вырезать нужный кусок.
PD>Ну ты даешь! Сказал бы такое мой студент — я бы ему сказал все, что о его знаниях думаю!
PD>Конечно, если приложение этого не позволяет, ты этого не сделаешь. И если в нем нет никаких картинок, а есть только форма с кнопками и т.д, то, конечно, этого там нет.
Ну так о чем речь? Нет таких приложений в природе. PD>Но если в программе есть картинки, и есть смысл выделять и сохранять куски изображения, то выделение резиновым контуром и сохранение в клипбоард делается за полчаса. Я это упражнение даю студентам на 2 месяце курса по Win32. Приезжай в Омск, я тебя к ним отведу, они тебе расскажут , как это делается и покажут все.
Гы-гы. Ну ладно, я пожалуй подожду от тебя релиза Earth.exe с этой функциональностью. За полчаса для резинового контура, плюс, сталобыть, три недели на "показ картинок". Ок. Жду. Вернемся к вопросу в конце мая.
Выделение резиновым контуром и сохранение картинки в веб приложении делается не намного сложнее, чем в win32.
>>Ты меняешь настройки браузера? Ок, давай я поменяю настройки винды PD>Я уже писал , почему считаю это сравнение неубедительным.
Нет, не писал. Впрочем, это неважно. [i]Браузер является платформой для веб-приложения. Винда является платформой для десктопного приложения. Это медицинский факт. И если ты начинаешь крутить настройки платформы (заметь, совершенно легальным образом), то можешь получить любые непредсказуемые результаты. Это ничего не говорит о качестве приложения.
S>>Настойчиво повторяю призыв к здоровому образу жизни. Потому что этот пример показывает преимущества вебного приложения перед десктопным. Если убить данные настольного приложения, то оно как правило тупо ляжет. А викимапия всего лишь будет подольше грузиться.
PD>А не объяснит ли уважаемый сэр, с чего это оно тупо ляжет ? PD>Писать программы аккуратно надо, а не давать советы вроде этого
S>>О плохих говорить не будем. Давайте говорить о хороших. PD>>>И как же быть с Delphi приложениями, которые не дотягивают до этого функционала на века ? S>>Предлагаю выкинуть.
PD>Delphi или Web ? Кстати, лет 10 назад я участвовал в проекте на Delphi 5 с весьма серьезной графикой, двумерное моделирование трехмерных объектов, проще говоря — Fashion mapper, посмотреть, как на данном человеке будет рубашка выглядеть, если такую-то ткань употребить.
PD>>>Неужели только через 100 лет мы сумеем картинки в настольных приложениях показывать ? Ты часом не из 19 века это письмо писал ? S>>При чем тут картинки?
PD>При том, что весь этот www.wikimapia.org есть попросту viewer битовых карт с зумом и скроллингом.
На таком уровне любое десктопное приложение суть всего лишь стейтмашина для обработки потока Windows сообщений. И что? Вопрос-то в том, каких карт. Кстати, там не только зум и скроллинг. А еще и показ user-defined объектов.
PD>OK. Тогда у меня просьбочка небольшая. Нельзя ли на базе веб-приложений приличный на уровне пусть не Word, но хоть WordPad текстовый редактор сюда встроить вместо того, в котором я это пишу. Когда тут нормальный WYSIWYG будет, с цветами и шрифтами?
Когда у нас появится время его прикрутить. Никакой принципиальной проблемы в этом нету. См. напр. Outlook Web Access.
PD>И за каким богом я должен для предпросмотра отсылать текст в Москву, чтобы мне его тут же вернули обратно ? Утверждаете Вы его там, что ли ?
Нет, опровергаем PD>Для справки — у меня Dual Athlon 4200+ и 2 Gb памяти, и я выражаю уверенность, что этого вполне достаточно, чтобы отформатировать 3 Кб текста на моей машине без помощи сервера.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Всякий раз, когда нам нужно выбирать между простотой пользователя и простатой программиста, мы выбираем простоту пользователя. Потому что настоящему программисту простата не нужна
Всякий раз, когда нам нужно выбирать между простотой пользователя и простатой программиста, мы выбираем простоту пользователя. Потому что настоящему программисту простата не нужна
Да здравствуют девушки-программистки!
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Sinclair, Вы писали:
GZ>>Простейший способ реализации — все таки get. S>
Всякий раз, когда нам нужно выбирать между простотой пользователя и простатой программиста, мы выбираем простоту пользователя. Потому что настоящему программисту простата не нужна
Здравствуйте, Mamut, Вы писали:
PD>>1. Выделение области курсором мыши (об этом я уже говорил)
M>А какие десктоп-приложения это позволяют делать?
1. Irfan View, о котором я уже писал
2. Практически все графические редакторы
3. В отношении других приложений — могу лишь Ильфа и Петрова процитировать
-- Я сам в желтых ботинках. В Москве еще двести тысяч
человек в желтых ботинках ходят. Может быть, вам
нужно узнать их адреса? Тогда пожалуйста. Я брошу всякую
работу и займусь этим делом. Через полгода вы будете
знать все адреса. Я занят, гражданка.
4. Упражнения, которые выполняют мои третьекурсники.
PD>>2. Best fit in window. Выделяем курсором мыши, нажимаем кнопку, и выделенная область оккупирует все текущее окно наилучшим образом, т.е с автоматическим выбором зума
M>Какие десктоп-приложения это умеют делать? maps.google.com это умеет
Ну что же, хорошо, прогресс есть
PD>>3. Сохранение locations. Вот, к примеру, собираешься ты в Омск. И я хочу тебе сообщить о ряде мест, которые стоит посетить. Пощелкал я в разных местах, сделал подписи (которые никого, кроме нас с тобой, не касаются), сохранил все это в файл, и этот файл тебе переслал. Ты его открыл , и в окне крестиками помечены разные места, с подписями.
M>Похожая функциональность давно в google docs, например, есть
А на wikipedia нет. Но обрати внимание, ты это преподносишь как достижение, в то время как для десктопных приложений это мелочь, так, мимоходом сделать
PD>>4. Координатную сетку нанесите! И так, чтобы убрать можно было.
M>Зачем? Учитывая, что это просто картинки, это не сложно
Несложно, но сделайте. А то я не всегда понимаю, где я нахожусь.
PD>>5. Расстояния. Ткнул мышкой в одно место, ткнул в другое и показали, сколько между ними метров или километров.
M>maps.google.com
Тоже хорошо.
Кстати, объясни мне один вопрос. Почему нельзя из web-приложения читать/записывать файлы на локальный компьютер ? Или можно все же ? Вот это сообщение я набираю второй раз. Уже набрал, послал — ошибка сервера. Back — не сработал. И потерял я свой текст, теперь опять набираю. Я понимаю, что запись из JavaScript — это опасно, но, в конце концов, запускать .EXE из Интернета тоже опасно, но ведь запускаю же я скачанные с www.microsoft.com EXE, да еще такие, которые мне часть ОС изменяют. Почему же это можно, а вот из скрипта с того же www.microsoft.com — нельзя ? Или из редактора, в котором я сейчас пишу — почему нельзя текст перед посылкой в файл сохранить ?
А пока что я перед посылкой Ctrl-A, Ctrl-Ins сделаю. Чтобы в третий раз не набирать.
PD>Кстати, объясни мне один вопрос. Почему нельзя из web-приложения читать/записывать файлы на локальный компьютер ? Или можно все же ? Вот это сообщение я набираю второй раз. Уже набрал, послал — ошибка сервера. Back — не сработал. И потерял я свой текст, теперь опять набираю. Я понимаю, что запись из JavaScript — это опасно, но, в конце концов, запускать .EXE из Интернета тоже опасно, но ведь запускаю же я скачанные с www.microsoft.com EXE, да еще такие, которые мне часть ОС изменяют. Почему же это можно, а вот из скрипта с того же www.microsoft.com — нельзя ? Или из редактора, в котором я сейчас пишу — почему нельзя текст перед посылкой в файл сохранить ?
PD>А пока что я перед посылкой Ctrl-A, Ctrl-Ins сделаю. Чтобы в третий раз не набирать.
Ты опять недостатки конкретной реализации выдаёшь за недостатки архитектуры в целом. Посмотри на gmail — там максимум сможешь потерять изменения за последние пару минут. Или на другие google docs — приложение автоматически сохраняет изменения (не на жёсткий диск, а на сервер — но обычному-то юзеру какая разница?) каждые N минут или M секунд. А ещё есть Google Gears которые расширяют "песочницу" веб-приложений и позволяют к тому же возможность работы в offline.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кстати, в таком сохранении на сервере промежуточного варианта есть одна маленькая неэтичность. Совсем маленькая, но все же есть. Я готов доверить gmail мое готовое письмо, иначе зачем бы я их услугами пользовался ? Но из этого не следует, что я готов доверить ему свой черновик в процессе работы над ним.
А если ты находишься в Мухосратостане в интернет кафе под зазванием UltraSicure Intirnet, ты кому больше будешь доверять — локальному почтовому клиенту или gmail?
... <<RSDN@Home 1.2.0 alpha 4 rev. 1052 on Windows Vista 6.0.6001.65536>>
M>>Почему возможности одного-двух десктоп-приложений выдаются как непременный атрибут веб-приложений вообще?
PD>Что-то я не понял. При чем тут web-приложения вообще. И в чем тут проблема, если эта задача по сложности сравнима с упражнениями третьекурсников ?
В упрек викимапии было поставлено то, что нельзя произвольную область окна выделить и скопировать в виде отдельного приложения. Причем аргументом было "я так хочу". Я вон тоже хочу в настольном приложении WIndows Media Player или Google Earth такую же фнкциональность. А нету! Все, дектоп-приложения отстой!
PD>>>А на wikipedia нет. Но обрати внимание, ты это преподносишь как достижение, в то время как для десктопных приложений это мелочь, так, мимоходом сделать
M>>Мелочь? Мимоходом? Не помню ни одного такого приложения
PD>Я сам такое писал
Я тоже много чего писал. Но вот collaboraon в прикладных приложениях мало где видел
PD>>>Кстати, объясни мне один вопрос. Почему нельзя из web-приложения читать/записывать файлы на локальный компьютер ?
M>>Зачем?
PD>Ну знаешь ли... Затем же, зачем это есть в десктопных приложениях. Вот если web-приложения будут на сервере и выполняться (Web Terminal Server — тогда не надо. А пока они все же работают на клиенте, я хочу иметь возможность на только сохранить картинку средствами броузера или всю страницу его же средствами, но и вставить из файла в редвктор, сохранить и т.д. Что тут ненормального ?
Тогда это, в целом, вопрос к стандартизации поведения сред выполнения ака браузерам.
Pavel Dvorkin,
PD>>>Ты — ссылка имеет вид PD>>>http://www.wikimapia.org/#lat=54.769231&lon=83.101251&z=18&l=1&m=a&v=2 PD>>>Так ? PD>>>Я : ссылка имеет вид PD>>>EARTH.EXE /#lat=54.769231&lon=83.101251&z=18&l=1&m=a&v=2 PD>>>(или в XML)
S>>Первая — работает. Вторая — нет. Какие еще отличия нужны?
PD>Да, если уж тебе приходится к таким аргументам прибегать — значит других не осталось.
Я не понимаю в вашых высоких материях нифига, и рассуждаю как обычный простой в деревянную доску пользователь.
Пример нумбер 1. Вот я ползу по интернету и натыкаюсь на чего-то интересное (скажем небольшие логические игрушки люблю, сокобаны там, судоку...). Хочу. Что делаю? Тыкаю на ссылку. А потом? Если ссылка имеет вид "бла-бла-бла/get?file=earth.exe" (а если ещё рядом фигурирует слово shareware, уж простят меня шароварщики) я сразу напрягаюсь, чешу репу и рассуждаю на тему: "Качать или не качать? А ну её в баню, ломает меня нафиг. Это ведь надо ещё инсталлировать, хз троян ещё какой подцеплю... ", давлю интерес и закрываю таб. Вуаля: пользователь остался без программы, программа осталась без пользовательского внимания.
Если ссылка открывается прямо в браузере, то блин никаких проблем. Я щаслив, создатели получили +1 за ещё один показ какой-нть рекламы мне.
Пример нумбер 2. Вот меня просят заплатить за шаровару. Да блииин, это ж опять переться в банк, стоять очередях, заполнять эти идиотские бумажки... Нет уж, спасибо, я скачаю кряк, а моя совесть пусть отдувается. Мне не денег жалко, мне просто лень! А вот когда появилась оплата через СМС, стало намного (намного!) комфортнее — не отрывая задницу от стуля чик — и готово.
Пример нумбер 3. Публичные шары. Когда попадаю на ссылку на rapidshare — меня напрягает конечно, но можно пережить. А когда ссылку на letitbit — ну уж нет, пусть они идут со своей закачкой на один общеизвестный адрес. Причина: с рапиды можно скачать хоть и с гемороем но без мусора, а для letitbit — заходить из-под IE (он меня бесит по идейным соображениям), качать спецкачалку (которая оказывается с трояном!), ставить этот мусор себе и только потом скачать файлик.
В качестве заключение вот мой простой философский итог:
Товарищи, которые занимаются коммерцией в инете похоже просекли, что внимание пользователя — это тоже небесплатный ресурс, поэтому его (пользователя с его пользовательским вниманием) нужно как можно быстрее зацепить с минимальным количеством накладных расходов. Поэтому весьма популярны регистрации и форумы с помощью капчей (раньше было в-основном с помощью мыла), оплата через СМС, публичные шары (как быстро вы сможете получить хостинг) и флэш-игры.
так что earth.exe — это не наш путь. А с джава-апплетами идея провалилась похоже потому, что ГУЙ там выглядел по-уродски.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Означает ли это, что вообще никакие программы .exe нельзя скачивать ? Как же в таком случае быть с теми программами, которые есть ? Вот я сейчас новую версию Open Office скачал и установил. А вдруг туда Sun троян подсунула ? PD>Не загружайте программы с подозрительных сайтов. И вообще не ходите туда. Там и без EXE троян подцепить можно.
Предлагаешь убить всех мелких и средних разработчиков ПО?
Здравствуйте, Sinclair, Вы писали:
K>>Не говоря уж о том, что некоторый софт вообще не логично делать веб приложениями. Например хотя бы мессенджер, S>Это ты случайно не про ICQ2GO?
Нет, во-первых я хочу, чтобы мой мессенджер сидел в трее (icq2go так умеет?).
Во-вторых запускать еще один экземпляр браузера только ради одного мессенджера не хочу.
В третьих, это что за нездравая мания, пытаться все запихать в веб?
Вот тот самый ваш любимый гугл, который все время приводится в пример, почему-то google talk сделал не веб приложением.
K>>Я к тому, что веб и десктоп приложения не взаимоисключают друг друга, а лишь дополняют. S>Да, есть быстро сужающаяся ниша приложений, которые не получается перевести в веб.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Не означает, конечно, но я о другом говорил. Я говорил о том, что программа должна привлекать пользователя. И если программа будет .exe, то она будет гораздо менее привлекательна.
Привлекательна, не привлекательна, самое главное, чтобы она была удобна для пользователя. Веб или десктоп это уже вопрос вторичный. Веб приложения неудобны как минимум тем, что невозможно поработать офф-лайн.
Вот работать с почтой в gmail мне удобнее, чем с outlook. Пользоваться Miranda удобнее, чем icq2go. Пользоваться Jira удобнее, чем с PVS Tracker. Корректировать фотографии удобнее в встроенной в Висте программе, чем где нибудь в вебе.
Я это к тому, что, что-то удобнее в виде веб приложений, а что-то в виде десктоп приложений и вряд ли это кардинально изменится в ближайшем будущем.
Можно помечтать. Я бы был очень рад, если будет доступен почти в любом месте высокоскоростной интернет с 99.9% надежностью. Абсолютно все хранится на каких-либо супер серверах, в том числе и сама OS, а компы играют роль лишь тонких клиентов.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Mamut, Вы писали:
M>>>А в каких десктоп приложениях есть подобная функциональность???
PD>>Irfan View.
M>Вау! Целых одно приложеие! Почему возможность выделить произвольный кусок области приложения и сохранить этот кусок в как картинку объявляется обязательным для веб приложений?
Ты не понял, похоже, хитрую подтасовку от Павла. Irfan View — графический редактор. Ясен пень, в нем будет работа с изображением и разрезкой его на части.
А мне бы хотелось посмотреть, как Павел предлагает сохранить в виде картинки, например, кусок тулбара из MS Word...
Подумалось... Все же люди начинают делать веб-приложения с упором на слово приложение, несмотря на всю кривизну HTML+CSS+Javascript. Предстоит нам бум таких приложений или все же нет?
Здравствуйте, AndrewVK, Вы писали:
GZ>>Простота распространения как в Web + нормальный адекватный интерфейс + нормальный доступ к ресурсам локального компа. Но это мечты. AVK>Почему мечты? WPF + ClickOnce либо Swing + JavaWebStart.
Мы используем WebStart. Это, конечно, очень классная технология развертывания приложений. Но вот это точно не "Web-приложения", а просто способ для запуска обычных десктопных.
Здравствуйте, Cyberax, Вы писали:
C>Мы используем WebStart. Это, конечно, очень классная технология развертывания приложений. Но вот это точно не "Web-приложения", а просто способ для запуска обычных десктопных.
А я и не говорил, что это Web-приложение. ClickOnce тоже не оно. Но позволяет затраты по деплойменту свести к минимуму.
C>Ну и ClickOnce я не видел в дикой природе ВООБЩЕ.
А я видел. Просто природа у него большей частью довольно специфичная — в основном корпоративная среда.
... << RSDN@Home 1.2.0 alpha rev. 796 on Windows Vista 6.0.6001.65536>>
Let’s start with XBAP… XBAP (or Xml Browser Application) really just refers to a standard WPF application deployed via clickonce over the internet – and hosted within the browser. Clickonce, of course, allows for incremental updates – so most of the time you don’t need to re-download your presentation layer.
Здравствуйте, Curufinwe, Вы писали:
C>Let’s start with XBAP… XBAP (or Xml Browser Application) really just refers to a standard WPF application deployed via clickonce over the internet – and hosted within the browser.
Ключевое отличие я выделил.
... << RSDN@Home 1.2.0 alpha rev. 800 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
C>>Let’s start with XBAP… XBAP (or Xml Browser Application) really just refers to a standard WPF application deployed via clickonce over the internet – and hosted within the browser.
AVK>Ключевое отличие я выделил.
И что это меняет? XBAP — частный случай ClickOnce приложения. Я же не утвердал что все ClickOnce или WPF приложения являются XBAP.
Честно говоря не вижу здесь предмета спора
Здравствуйте, AndrewVK, Вы писали:
AVK>Почему мечты? WPF + ClickOnce либо Swing + JavaWebStart.
Насчет Java — не знаю. А вот с ClickOnce — тоже не все в порядке. Во первых, эта шняга не доверяет по умолчанию нормальному толстому приложению уже на уровне локальной сети. Во-вторых — не весь код является managed.
Для того чтобы сделать подпись с помощью нестандартного криптопровайдера, или сканировать изображение, уже не хватает прав. Не хватает прав по умолчанию, на просто сохранение файлов. Надо с доменом кочевряжиться. А еще бывает, что серваки загоняют в отдельный домен. И тогда становится совсем все нехорошо.
Вобщем, вся трабла в том, что компьютеры защищаются не только от врагов, но и от друзей. И соответвенно — мечта остается мечтой. А правильная инсталяция — с диска.
Здравствуйте, GlebZ, Вы писали:
GZ>Насчет Java — не знаю. А вот с ClickOnce — тоже не все в порядке. Во первых, эта шняга не доверяет по умолчанию нормальному толстому приложению уже на уровне локальной сети.
Логично. Тут уж либо безопасность, либо удобство. В корпоративной среде можно подкрутить политику на AD сервере.
GZ>Вобщем, вся трабла в том, что компьютеры защищаются не только от врагов, но и от друзей. И соответвенно — мечта остается мечтой. А правильная инсталяция — с диска.
Только вот веб-приложения тут не помогут, у них с правами еще хуже.
... << RSDN@Home 1.2.0 alpha rev. 801 on Windows Vista 6.0.6001.65536>>
C>Ну и ClickOnce я не видел в дикой природе ВООБЩЕ.
Народ еще "не прохавал". С помощью неё удобно не просто деплоить, но и вызывать уже продеплоенные приложения с некоторым передаваемым контекстом, что делает её вдвойне полезной.
Здравствуйте, GlebZ, Вы писали:
GZ>А вот с ClickOnce — тоже не все в порядке. Во первых, эта шняга не доверяет по умолчанию нормальному толстому приложению уже на уровне локальной сети. Во-вторых — не весь код является managed.
У нас деплоятся unmanaged DLL-ки в составе этого толстого приложения без проблем.
GZ>Для того чтобы сделать подпись с помощью нестандартного криптопровайдера, или сканировать изображение, уже не хватает прав. Не хватает прав по умолчанию, на просто сохранение файлов.
Кого интересуют права по-умолчанию в толстом приложении?
Здравствуйте, c-smile, Вы писали:
CS>В принципе Silverlight v.2.0 это по большому счету реинкарнация идеи Java Applet.
Ни в коем разе. реинкарнация джавовских аплетов в дотнете была с самой первой версии (правда в 1.0 были проблемы с CAS), просто она не имела своего отдельного имени, но UserControl спокойно можно было втыкать внутрь странички навроде апплета.
Silverlight это несколько иное, это скорее закос в сторону Flash/Flex, но круче и изначально с рассчетом на построение UI.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, c-smile, Вы писали:
CS>Flash/Flex это тоже в принципе такой applet. applet c точки зрения host page это embeddable конструкция которая "исполняет" "активные" документы — т.е. некий код и имеет свой markup (optional).
Ну знаешь, если все внедряемые конструкции апплетами называть, то тогда конечно.
CS>К сожалению для полномасштабных UI существует изначальная проблема browser — проблема наличия "back button". Это суровое ограничение которое ни Java Applet ни Silverlight в приниципе победить не могут.
В silverlight могут (в xbap тоже), там есть специальное API для этого.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
CS>>К сожалению для полномасштабных UI существует изначальная проблема browser — проблема наличия "back button". Это суровое ограничение которое ни Java Applet ни Silverlight в приниципе победить не могут. AVK>В silverlight могут (в xbap тоже), там есть специальное API для этого.
Flex/Flash тоже могут, кстати.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
CS>>Flash/Flex это тоже в принципе такой applet. applet c точки зрения host page это embeddable конструкция которая "исполняет" "активные" документы — т.е. некий код и имеет свой markup (optional).
AVK>Ну знаешь, если все внедряемые конструкции апплетами называть, то тогда конечно.
define: Applet
A program, intended for delivery over the Internet, which can be included in an HTML page, just as an image can be included.
Most often refers to a small Java program designed to run in a Web browser. Java applets run in a sandbox, so they can't perform unauthorized functions like file reading or opening Net connections to other computer from your computer.
Ключевые и принципиальные слова: "included in an HTML page" и "applets run in a sandbox".
CS>>К сожалению для полномасштабных UI существует изначальная проблема browser — проблема наличия "back button". Это суровое ограничение которое ни Java Applet ни Silverlight в приниципе победить не могут.
AVK>В silverlight могут (в xbap тоже), там есть специальное API для этого.
Сомневаюсь я по поводу Mozilla например. В gecko такое в общем-то безобидное действо как изменение CSS атрибута display приводит к пересозданию окна и соответсвенно к потере состояния. Я уже не говорю о тыканием мышой в back button. SetWindowHook — не предлагать ибо хак вульгарный.
Здравствуйте, c-smile, Вы писали:
CS>Сомневаюсь я по поводу Mozilla например.
Не сомневайся. В WPF поддержка браузерного стиля встроена изначально. Более того, даже если такое приложение (полноценный WPF, а не SL) запустить без браузера, оно таки все равно отрисует окошко с кнопками Back и Forward.
CS> В gecko такое в общем-то безобидное действо как изменение CSS атрибута display приводит к пересозданию окна и соответсвенно к потере состояния.
Состояние в SL независимо от состояния страницы.
CS> Я уже не говорю о тыканием мышой в back button. SetWindowHook — не предлагать ибо хак вульгарный.
Interop все равно запрещен для всего кроме Full Trust сборок.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
CS>>Сомневаюсь я по поводу Mozilla например.
AVK>Не сомневайся. В WPF поддержка браузерного стиля встроена изначально. Более того, даже если такое приложение (полноценный WPF, а не SL) запустить без браузера, оно таки все равно отрисует окошко с кнопками Back и Forward.
CS>> В gecko такое в общем-то безобидное действо как изменение CSS атрибута display приводит к пересозданию окна и соответсвенно к потере состояния.
AVK>Состояние в SL независимо от состояния страницы.
CS>> Я уже не говорю о тыканием мышой в back button. SetWindowHook — не предлагать ибо хак вульгарный.
AVK>Interop все равно запрещен для всего кроме Full Trust сборок.
Мы наверное говорим о разных вещах.
Представь себе скажем некий applet (Java, SL — неважно), скажем редактор, и ситуацию когда пользователь жмет на host странице гиперлинк.
Текущая страница замещается — уходит в стек history (или на новый tab) и новая появляется в том же view. Ты утверждаешь следующее:
1) Applet получает нотификацию от том что page goes out of view but not destroyed.
2) У тебя есть возможность дифференцировать ситуацию что пользователь ушел вообще или Карлсон обещал вернуться?
Здравствуйте, c-smile, Вы писали:
CS>Представь себе скажем некий applet (Java, SL — неважно), скажем редактор, и ситуацию когда пользователь жмет на host странице гиперлинк. CS>Текущая страница замещается — уходит в стек history (или на новый tab) и новая появляется в том же view. Ты утверждаешь следующее: CS> 1) Applet получает нотификацию от том что page goes out of view but not destroyed. CS> 2) У тебя есть возможность дифференцировать ситуацию что пользователь ушел вообще или Карлсон обещал вернуться?
Я тебе еще раз повторяю — проблема эта решена в WPF/SL изначально, оно там сразу закладывалось. Продробно — кури соответствующую документацию и примеры. Начать можно с класса Page. Еще раз повторю — SL, а уж тем паче XBAP приложение совершенно не обязано встраиваться в HTML, это не апплет.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
CS>>Представь себе скажем некий applet (Java, SL — неважно), скажем редактор, и ситуацию когда пользователь жмет на host странице гиперлинк. CS>>Текущая страница замещается — уходит в стек history (или на новый tab) и новая появляется в том же view. Ты утверждаешь следующее: CS>> 1) Applet получает нотификацию от том что page goes out of view but not destroyed. CS>> 2) У тебя есть возможность дифференцировать ситуацию что пользователь ушел вообще или Карлсон обещал вернуться?
AVK>Я тебе еще раз повторяю — проблема эта решена в WPF/SL изначально, оно там сразу закладывалось. Продробно — кури соответствующую документацию и примеры. Начать можно с класса Page. Еще раз повторю — SL, а уж тем паче XBAP приложение совершенно не обязано встраиваться в HTML, это не апплет.
Я ему про Фому, а он мне про Ерему. Я говорю исключительно про Silverlight и web browser based UI. При чем здесь XBAP?
Так какая из перечисленных мной проблем решена в Silverlight (котрый встраивается на страницу через <object> или <embed>?
Еще раз: забудь о [большом]WPF и XBAP которые предполагают наличие UA (User Agent/Application) принципиально другого типа. Мы говорим о сугубо web browsers.
Здравствуйте, c-smile, Вы писали:
CS>Я ему про Фому, а он мне про Ерему. Я говорю исключительно про Silverlight и web browser based UI. При чем здесь XBAP?
При том что SL 2.0 это облегченная версия XBAP с упрощенным CLR, встраиваемым в плагин. И если уж проводить аналогии с джавовскими апплетами, требующими JRE, то XBAP к ним куда как ближе.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, c-smile, Вы писали:
CS>Сомневаюсь я по поводу Mozilla например. В gecko такое в общем-то безобидное действо как изменение CSS атрибута display приводит к пересозданию окна и соответсвенно к потере состояния. Я уже не говорю о тыканием мышой в back button. SetWindowHook — не предлагать ибо хак вульгарный.
Это делается с помощью простого трюка с anchor'ами.
Погугли по словам "GWT anchor back button" — я сейчас на dialup.
Здравствуйте, c-smile, Вы писали:
CS>Мы наверное говорим о разных вещах. CS>Представь себе скажем некий applet (Java, SL — неважно), скажем редактор, и ситуацию когда пользователь жмет на host странице гиперлинк. CS>Текущая страница замещается — уходит в стек history (или на новый tab) и новая появляется в том же view. Ты утверждаешь следующее:
Этого не происходит, если происходит переход на другой anchor...
А дальше дело техники — кодируем состояние апплета в виде anchor'а и ставим history listener.
CS> 1) Applet получает нотификацию от том что page goes out of view but not destroyed. CS> 2) У тебя есть возможность дифференцировать ситуацию что пользователь ушел вообще или Карлсон обещал вернуться? CS>Что из этого true?
Ничего, это к делу не относится.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
CS>>Я ему про Фому, а он мне про Ерему. Я говорю исключительно про Silverlight и web browser based UI. При чем здесь XBAP?
AVK>При том что SL 2.0 это облегченная версия XBAP с упрощенным CLR, встраиваемым в плагин. И если уж проводить аналогии с джавовскими апплетами, требующими JRE, то XBAP к ним куда как ближе.
Мне кажется ты сам не понимаешь о чем говоришь. Или не понимаешь принципов встраивания тех же <applet>.
Silverlight is a cross platform, cross browser .NET plug-in that enables designers and developers to build rich media experiences and RIAs for browsers.
Это в принципе то же самое что и Java plug-in который использует JRE. Т.е. Silverlight предназначен для встраивания в web page (html) и использует .NET Framework вместо JRE.
XBAP is Windows only and requires .Net 3 Framework to be installed on your machine. It is used for creating heavyweight .Net applications that take advantage of the full capabilities of .Net 3 Framework.
Silverlight(TM) is a small component that is plugged into the browser. It is cross platform and does not require the installation of .Net 3 Framework.
Silverlight(TM) supports only a subset of XAML. You may think of Silverlight(TM) (WPF/E) as Microsoft's equivalent to Flash Player.
В IE XBAP player это отдельное view в котором html и не пахнет. Это фактически все тот же ActiveX.Document — это то как IE открывает Word или Excel файлы.
Я надеюсь разница между ActiveX.Control и ActiveX.Document очевидна и объяснять отличия не нужно.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, c-smile, Вы писали:
CS>>Мы наверное говорим о разных вещах. CS>>Представь себе скажем некий applet (Java, SL — неважно), скажем редактор, и ситуацию когда пользователь жмет на host странице гиперлинк. CS>>Текущая страница замещается — уходит в стек history (или на новый tab) и новая появляется в том же view. Ты утверждаешь следующее: C>Этого не происходит, если происходит переход на другой anchor...
C>А дальше дело техники — кодируем состояние апплета в виде anchor'а и ставим history listener.
"кодируем состояние апплета в виде anchor'а" — тема не раскрыта. Как конкретно это делается?
CS>> 1) Applet получает нотификацию от том что page goes out of view but not destroyed. CS>> 2) У тебя есть возможность дифференцировать ситуацию что пользователь ушел вообще или Карлсон обещал вернуться? CS>>Что из этого true? C>Ничего, это к делу не относится.
У меня есть редактор (WYSIWYG HTML editor) который хостится как <applet>. Я хочу например чтобы стек undo/redo сохранялся при навигациях с/на страницу.
Короче для формулировки что заявлена Mamut в начале:
Все же люди начинают делать веб-приложения с упором на слово приложение, несмотря на всю кривизну HTML+CSS+Javascript. Предстоит нам бум таких приложений или все же нет?
Я берусь утверждать что круг "приложений" достаточно сильно ограничен. Не все можно положить во ViewState.
Это все вопрос про разницу толстый/тонкий клиент. А если толстый то какими правами обладает.
Здравствуйте, c-smile, Вы писали:
AVK>>При том что SL 2.0 это облегченная версия XBAP с упрощенным CLR, встраиваемым в плагин. И если уж проводить аналогии с джавовскими апплетами, требующими JRE, то XBAP к ним куда как ближе.
CS>Мне кажется ты сам не понимаешь о чем говоришь.
CS>Silverlight is a cross platform, cross browser .NET plug-in that enables designers and developers to build rich media experiences and RIAs for browsers.
CS>Это в принципе то же самое что и Java plug-in
Гы, черточка, гы. Под это определение можно подогнать абсолютно любой плагин для расширения возможностей UI. Например тот же XUL runner. В таком раскладе я конечно согласен — и аплеты, и SL, и Flash/Flex/Как_там_он_сейчас_называется, и XUL, и дотнетный System.Windows.Forms.UserControl и даже ActiveX — одна фигня.
CS> который использует JRE. Т.е. Silverlight предназначен для встраивания в web page (html) и использует .NET Framework вместо JRE.
Silverlight не использует .NET, в том числе и SL 2.0. Дотнет использует XBAP. Собственно, это главная разница между ним и SL. Еще дотнет использует UserControl (это полная аналогия апплетов по внешней архитектуре).
CS>
CS>XBAP is Windows only and requires .Net 3 Framework to be installed on your machine. It is used for creating heavyweight .Net applications that take advantage of the full capabilities of .Net 3 Framework.
CS>Silverlight(TM) is a small component that is plugged into the browser. It is cross platform and does not require the installation of .Net 3 Framework.
CS>Silverlight(TM) supports only a subset of XAML. You may think of Silverlight(TM) (WPF/E) as Microsoft's equivalent to Flash Player.
Я все это знаю. Ты к чему это процитировал?
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, c-smile, Вы писали:
C>>Этого не происходит, если происходит переход на другой anchor... C>>А дальше дело техники — кодируем состояние апплета в виде anchor'а и ставим history listener. CS>"кодируем состояние апплета в виде anchor'а" — тема не раскрыта. Как конкретно это делается?
Да хоть как. От приложения зависит.
Представь, что у тебя апплет с тремя табами на странице "http://blah.blah.com/someapp". Ты кликаешь на tab2. Это вызывает перход на "http://blah.blah.com/someapp#tab2". Браузер остаётся на той же странице и генерируется событие, которое перехватывается апплетом или связующим JavaScript'ом. Событие "переход на якорь #tab2" затем передаётся движку апплета, который его обрабатывает как ему там нужно.
При нажатии кнопки "Назад" — оно точно так же перейдёт на страницу с пустым якорем.
Это всё уже РЕАЛЬНО РАБОТАЕТ в Flex'е и GWT, я сам это использовал в одном приложении на GWT. http://google-web-toolkit.googlecode.com/svn/javadoc/1.4/com/google/gwt/user/client/History.html — для GWT.
C>>Ничего, это к делу не относится. CS>У меня есть редактор (WYSIWYG HTML editor) который хостится как <applet>. Я хочу например чтобы стек undo/redo сохранялся при навигациях с/на страницу.
Делаешь на каждое действие по уникальному id и передаёшь их в виде anchor'ов. Могу помочь.
CS>Я берусь утверждать что круг "приложений" достаточно сильно ограничен. Не все можно положить во ViewState.
Есть ещё серверные сессии
CS>Это все вопрос про разницу толстый/тонкий клиент. А если толстый то какими правами обладает.
Большую часть можно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
AVK>>>При том что SL 2.0 это облегченная версия XBAP с упрощенным CLR, встраиваемым в плагин. И если уж проводить аналогии с джавовскими апплетами, требующими JRE, то XBAP к ним куда как ближе.
CS>>Мне кажется ты сам не понимаешь о чем говоришь.
AVK>Видимо аргументы кончились. Пошло обсуждение собеседника.
Аргументы кончились у кого?
Я задал вопросы:
1) Applet(java или silverlight applet) получает нотификацию от том что page goes out of view but not destroyed.
2) У тебя есть возможность дифференцировать ситуацию что пользователь ушел вообще или Карлсон обещал вернуться?
Все жду аргументы.
CS>>
CS>>Silverlight is a cross platform, cross browser .NET plug-in that enables designers and developers to build rich media experiences and RIAs for browsers.
CS>>Это в принципе то же самое что и Java plug-in
AVK>Гы, черточка, гы. Под это определение можно подогнать абсолютно любой плагин для расширения возможностей UI. Например тот же XUL runner. В таком раскладе я конечно согласен — и аплеты, и SL, и Flash/Flex/Как_там_он_сейчас_называется, и XUL, и дотнетный System.Windows.Forms.UserControl и даже ActiveX — одна фигня.
Абсолютно верно. Концептуально это одно и то же: содержимое code behind встраиваемого контента/компонента загруженного с пом. <embed> или <object> на web страницу. По определению такие технологии не могут изменить browser model — history, modeless execution и пр.
CS>> который использует JRE. Т.е. Silverlight предназначен для встраивания в web page (html) и использует .NET Framework вместо JRE.
AVK>Silverlight не использует .NET, в том числе и SL 2.0. Дотнет использует XBAP. Собственно, это главная разница между ним и SL. Еще дотнет использует UserControl (это полная аналогия апплетов по внешней архитектуре).
SL использует свою собственную VM что принципиально ничего не меняет. JRE тоже могут быть разными но суть от этого не меняется.
CS>>
CS>>XBAP is Windows only and requires .Net 3 Framework to be installed on your machine. It is used for creating heavyweight .Net applications that take advantage of the full capabilities of .Net 3 Framework.
CS>>Silverlight(TM) is a small component that is plugged into the browser. It is cross platform and does not require the installation of .Net 3 Framework.
CS>>Silverlight(TM) supports only a subset of XAML. You may think of Silverlight(TM) (WPF/E) as Microsoft's equivalent to Flash Player.
AVK>Я все это знаю. Ты к чему это процитировал?
Это я к тому что xbap не является технологией встраиваемой в web page content.
xbap это приложение принципиально другого типа. Общего с web browser там только способ доставки контента — over the wire.
Еще раз: в этом топике мы говорим про: "веб-приложения с упором на слово приложение, несмотря на всю кривизну HTML+CSS+Javascript."
Мысль моя заключается в том что никакие существующие встраиваемые в HTML средства не могут решить принципиальные ограничения этой технологии.
Здравствуйте, Cyberax, Вы писали:
C>>>Ничего, это к делу не относится. CS>>У меня есть редактор (WYSIWYG HTML editor) который хостится как <applet>. Я хочу например чтобы стек undo/redo сохранялся при навигациях с/на страницу. C>Делаешь на каждое действие по уникальному id и передаёшь их в виде anchor'ов. Могу помочь.
Я вставил в редактор image из клипборда. Как мне закодировать сие действо? В частности как этот image там разместить?
И потом какова глубина history?
CS>>Я берусь утверждать что круг "приложений" достаточно сильно ограничен. Не все можно положить во ViewState. C>Есть ещё серверные сессии
Есть. И?
CS>>Это все вопрос про разницу толстый/тонкий клиент. А если толстый то какими правами обладает. C>Большую часть можно.
"Приложение большей частью работает" звучит как "рыба почти свежая".
Здравствуйте, c-smile, Вы писали:
AVK>>Гы, черточка, гы. Под это определение можно подогнать абсолютно любой плагин для расширения возможностей UI. Например тот же XUL runner. В таком раскладе я конечно согласен — и аплеты, и SL, и Flash/Flex/Как_там_он_сейчас_называется, и XUL, и дотнетный System.Windows.Forms.UserControl и даже ActiveX — одна фигня.
CS>Абсолютно верно. Концептуально это одно и то же
Все понятно. Дальше продолжать разговор смысла нет.
... << RSDN@Home 1.2.0 alpha 2 rev. 872 on Windows Vista 6.0.6001.65536>>
Здравствуйте, c-smile, Вы писали:
C>>Делаешь на каждое действие по уникальному id и передаёшь их в виде anchor'ов. Могу помочь. CS>Я вставил в редактор image из клипборда. Как мне закодировать сие действо? В частности как этот image там разместить? CS>И потом какова глубина history?
Кодируешь это действие как переход на "http://some.blah.com/editor#actionId=5412" и сохраняешь это изображение в своём undo stack'е команду с этим ID. Т.е. переход на страницу с якорем "#actionId=5412" будет означать для твоего редактора "переход на состояние undo stack'а с ID вершины равным 5412".
При переходе между якорями страница не перезагружается, так что undo stack будет сохраняться.
Теперь более понятно?
CS>>>Я берусь утверждать что круг "приложений" достаточно сильно ограничен. Не все можно положить во ViewState. C>>Есть ещё серверные сессии CS>Есть. И?
При желании, можно рассматривать HTML как _очень_ тонкий клиент.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, c-smile, Вы писали: C>>>Делаешь на каждое действие по уникальному id и передаёшь их в виде anchor'ов. Могу помочь. CS>>Я вставил в редактор image из клипборда. Как мне закодировать сие действо? В частности как этот image там разместить? CS>>И потом какова глубина history? C>Кодируешь это действие как переход на "http://some.blah.com/editor#actionId=5412" и сохраняешь это изображение в своём undo stack'е команду с этим ID. Т.е. переход на страницу с якорем "#actionId=5412" будет означать для твоего редактора "переход на состояние undo stack'а с ID вершины равным 5412".
C>При переходе между якорями страница не перезагружается, так что undo stack будет сохраняться.
C>Теперь более понятно?
А не между якорями? А если просто по ссылке пользователь куда-то ушел?
CS>>>>Я берусь утверждать что круг "приложений" достаточно сильно ограничен. Не все можно положить во ViewState. C>>>Есть ещё серверные сессии CS>>Есть. И? C>При желании, можно рассматривать HTML как _очень_ тонкий клиент.
Он фактически и есть очень тонкий клиент. Я о том и говорю что не все типы приложенияй эту тонкость оценивают.
Здравствуйте, c-smile, Вы писали:
C>>При переходе между якорями страница не перезагружается, так что undo stack будет сохраняться. C>>Теперь более понятно? CS>А не между якорями? А если просто по ссылке пользователь куда-то ушел?
Тут никак в общем случае. Варианты такие:
1) Попытаться сохранить состояние на сервере с помощью AJAX-запроса при уходе со страницы.
2) Показывать пользователю диалог "вы действительно хотите уйти с этой страницы?".
3) Открывать такие страницы в новом табе/окне — самый правильный вариант.
CS>>>Есть. И? C>>При желании, можно рассматривать HTML как _очень_ тонкий клиент. CS>Он фактически и есть очень тонкий клиент. Я о том и говорю что не все типы приложенияй эту тонкость оценивают.
Можно его сделать ОЧЕНЬ тонким клиентом. На уровне терминального сервера.
Здравствуйте, Cyberax, Вы писали:
CS>>>>Есть. И? C>>>При желании, можно рассматривать HTML как _очень_ тонкий клиент. CS>>Он фактически и есть очень тонкий клиент. Я о том и говорю что не все типы приложенияй эту тонкость оценивают. C>Можно его сделать ОЧЕНЬ тонким клиентом. На уровне терминального сервера.
А зачем нам тогда html? x-window терминал и вперед. Но это уже другая "пестня".
Здравствуйте, c-smile, Вы писали:
C>>>>При желании, можно рассматривать HTML как _очень_ тонкий клиент. CS>>>Он фактически и есть очень тонкий клиент. Я о том и говорю что не все типы приложенияй эту тонкость оценивают. C>>Можно его сделать ОЧЕНЬ тонким клиентом. На уровне терминального сервера. CS>А зачем нам тогда html? x-window терминал и вперед. Но это уже другая "пестня".
Ты видел x-терминал в диких условиях? Я вот тоже не видел.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
CS>>Представь себе скажем некий applet (Java, SL — неважно), скажем редактор, и ситуацию когда пользователь жмет на host странице гиперлинк. CS>>Текущая страница замещается — уходит в стек history (или на новый tab) и новая появляется в том же view. Ты утверждаешь следующее: CS>> 1) Applet получает нотификацию от том что page goes out of view but not destroyed. CS>> 2) У тебя есть возможность дифференцировать ситуацию что пользователь ушел вообще или Карлсон обещал вернуться?
AVK>Я тебе еще раз повторяю — проблема эта решена в WPF/SL изначально, оно там сразу закладывалось. Продробно — кури соответствующую документацию и примеры. Начать можно с класса Page. Еще раз повторю — SL, а уж тем паче XBAP приложение совершенно не обязано встраиваться в HTML, это не апплет.
Решена ли эта проблема для SL, который в виде плагина к FF, Safari, Opera?
Здравствуйте, Curufinwe, Вы писали:
C>Здравствуйте, c-smile, Вы писали:
CS>>Частичным решением могло бы быть client side storage. Но этого нет ни в silverlight ни в Java Applet ни в Flex. CS>>Есть попытка решить сие в Google Gears но опять же до стека undo/redo операций не добраться вообще.
C>Для Silverlight есть Isolated Storage C>По умолчанию доступно 100Кб, можно увеличить по согласию пользователя.
О! Спасибо, это уже значительно ближе к теме обсуждения.
И на самом деле это лучше чем то что Google пытается всучить. Там предагается SQLite ни много ни мало в HTML5 стандарт "запузырить".
Virtual File System как бы более универсальна и storage квота поддается предсказуемому расчету.
Правда следующее:
An application on a domain shares the quota group with all the other applications on that domain. This enables multiple applications in the same domain to share a single quota. Note that domain in this context refers to a virtual host domain, such as Microsoft.com, not to an application domain.
здесь
несколько ограничивает применение — один домен не всегда только одна quota group. Но и так жить можно.
Но вообще все правильно — убогие cookies должны быть давно уже заменены на нечто подобное.
В общем идея верна, но не согласен с выводами.
Имхо если у приложения есть визуальные кнопки, то они должны работать адекватно
Т.е. если мы отказываемся от листания, истории и закладок, мы должны отказаться о мультибраузера как такового, либо он должен сам отключать доступность этих действий в отношении нашего приложения по нашему же желанию.
При существующих реалиях выхода только 2:
— описанная суррогатная поддержка листания,
— отказ от мультибраузера, т.е. заключение движка браузера в собственном лёгком клиенте с подвластным нам интерфейсом.
PD>Нет. В идеале — отказ от браузера как такового, потому что он не нужен. Не нужен же тебе браузер в десктопных приложениях ? И тут не нужен. Не для того он.
Нужен. Браузер — это способ отображения графического интерфеса, на основе некой декларативной логики, заключённой в данных, получаемых от сервиса.
Это нынешний тренд развития тонких клиентов.
AVK>Нынешний тренд это смартклиенты — т.е. приложения с богатым интерфейсом, наличием кастомной логики на клиенте, наличие персистентного кеша для данных в клиенте и, по возможности, occasionally connected режим. Ну, к примеру, Google Earth.
Смартклиенты при явно большей функциональности менее гибки в отношении деплоймента. Всему своё место.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нынешний тренд это смартклиенты — т.е. приложения с богатым интерфейсом, наличием кастомной логики на клиенте, наличие персистентного кеша для данных в клиенте и, по возможности, occasionally connected режим. Ну, к примеру, Google Earth.
Я бы так сказал — это тренд для серьезных компаний — та же Google. Но не для большинства компаний, увы...
Здравствуйте, VGn, Вы писали:
VGn>Нужен. Браузер — это способ отображения графического интерфеса, на основе некой декларативной логики, заключённой в данных, получаемых от сервиса. VGn>Это нынешний тренд развития тонких клиентов.
Тогда объясни, почему он не нужен для десктопных приложений. Там тоже вполне умеют "отображать графический интерфейс, на основе некой декларативной логики, заключённой в данных, получаемых от "... впрочем, неважно, откуда получаемых. Но без броузера великолепно обходятся.
PD>Тогда объясни, почему он не нужен для десктопных приложений. Там тоже вполне умеют "отображать графический интерфейс, на основе некой декларативной логики, заключённой в данных, получаемых от "... впрочем, неважно, откуда получаемых. Но без броузера великолепно обходятся.
AVK>Дело не в серьезности компании, а в серьезности человека, принимающего решения. А пока масса народа носится с горящими глазами и криками AJAX, AJAX и с PHP наперевес ...
Потому что пока проще нарисовать какой-никакой гуи в ХТМЛ и связать их с логикой на сервере, чем в нынешних тулзах для десктоп-приложений
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Cyberax, Вы писали:
C>>>>Ничего, это к делу не относится. CS>>>У меня есть редактор (WYSIWYG HTML editor) который хостится как <applet>. Я хочу например чтобы стек undo/redo сохранялся при навигациях с/на страницу. C>>Делаешь на каждое действие по уникальному id и передаёшь их в виде anchor'ов. Могу помочь.
CS>Я вставил в редактор image из клипборда. Как мне закодировать сие действо? В частности как этот image там разместить? CS>И потом какова глубина history?
Погоди. Давай не будем смешивать undo/redo и back/forward.
Даже в pure html эти "проблемы" не решены: попробуй сделать back на форму с textarea. С вероятностью 50% тебя вернут на пустую форму, а не в ту, где у тебя был набран текст.
И даже если вернут на форму, где в textarea таки есть текст, то Ctrl-Z в ней будет работать совсем не так, как работал до навигации "вперед", с формы.
Теперь всё становится понятнее: back/forward управляют навигацией. Поэтому там, где твой Applet (в широком смысле) занимается навигацией, он должен синхронизировать свою историю навигации с браузером. Это достигается использованием hash в адресе.
Для AJAX см. wikimapia.org, для Flash см. store.nike.com.
Если хочется чтобы undo/redo делался черех back/forward, то велком в подход GMail: апплет регулярно сохраняет версии на сервер. Модификация этого подхода — с поддержкой номера версии в hash — как раз позволит вернуть назад твою вставленную картинку.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Который (back button) вообще-то абсолютно ни к чему ни в каких "web приложениях", поскольку ничего, кроме головной боли, не создает.
Это заблуждение. К примеру, в таком совершенно не веб приложении, как MS Money, back button работает просто на ура.
PD>Вот в статических HTML сайтах, да, он имеет смысл. Здесь же логика действий пользователя должна контролироваться приложением, а оно это делать толком не может, так как пользователь с помощью back button может вполне отправиться черт знает куда, а потом вернуться.
Ну, вообще-то приложение, которое хочет диктовать пользователю логику действий, должно уйти на свалку истории.
PD>Да разве только back button ? А возможность зайти на любую страницу, где уже был через history ? В том числе и на страницу, на которую вообще не положено заходить прямо, а только с некоей иной страницы ? Вот и ведут web-программисты отчаяную борьбу с тем, с чем вообще бороться и не надо бы, потому что этого не должно быть.
Вот это очень странно. Страница, на которую не положено заходить прямо — это плод травмированного головного мозга. Если на это не положено заходить прямо, то у этого не может быть URL.
PD>Да и прочего идиотизма хватает. Одни только "серверные элементы управления" чего стоят! Серверный комбобокс — это как ? Я что-то вообще его с большим трудом себе представляю . И за каким чертом серверу знать, что где-то на клиенте за 1000 км от него есть комбобокс
Это просто непонимание разработчиками того, что такое веб-приложение.
PD>ИМХО действительно идея Java-апплетов является наилучшей. Подчеркиваю, идея, а не текущая реализация. Есть приложение (на Java), исполняемое на клиенте. Приложение обращается к серверу, сервер выполняет действия, клиент получает ответ. Фактически та же модель, что и в настольных приложениях типа multi-tier. Все.
Угу. Forward to the past.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
PD>>Да разве только back button ? А возможность зайти на любую страницу, где уже был через history ? В том числе и на страницу, на которую вообще не положено заходить прямо, а только с некоей иной страницы ? Вот и ведут web-программисты отчаяную борьбу с тем, с чем вообще бороться и не надо бы, потому что этого не должно быть. S>Вот это очень странно. Страница, на которую не положено заходить прямо — это плод травмированного головного мозга. Если на это не положено заходить прямо, то у этого не может быть URL.
Такая страница может быть промежуточной частью некой бизнес-транзакции. И да — у неё не должно быть прямой url, либо, что логичнее, страница по её url должна отслеживать состояние транзакции.
Здравствуйте, Sinclair, Вы писали:
S>Это заблуждение. К примеру, в таком совершенно не веб приложении, как MS Money, back button работает просто на ура.
Всегда можно найти пример, который не подходит под общий случай. Иногда, может быть, да, он нужен и полезен.
PD>>Вот в статических HTML сайтах, да, он имеет смысл. Здесь же логика действий пользователя должна контролироваться приложением, а оно это делать толком не может, так как пользователь с помощью back button может вполне отправиться черт знает куда, а потом вернуться. S>Ну, вообще-то приложение, которое хочет диктовать пользователю логику действий, должно уйти на свалку истории.
Я не совсем точно выразился, не придирайся к словам, я думаю, ты понял, что я имел в виду.
S>Вот это очень странно. Страница, на которую не положено заходить прямо — это плод травмированного головного мозга. Если на это не положено заходить прямо, то у этого не может быть URL.
Может быть, и не может, но ведь есть, и нередко.
PD>>Да и прочего идиотизма хватает. Одни только "серверные элементы управления" чего стоят! Серверный комбобокс — это как ? Я что-то вообще его с большим трудом себе представляю . И за каким чертом серверу знать, что где-то на клиенте за 1000 км от него есть комбобокс S>Это просто непонимание разработчиками того, что такое веб-приложение.
Нет, не согласен. Все же если в технологию закладывается то, что не очень-то осмысленно (а серверный комбобокс не очень осмысленная вещь), то виновата технология, а не разработчики. Да и что им, прости, понимать или не понимать, если он есть и с ним работать надо!
PD>>ИМХО действительно идея Java-апплетов является наилучшей. Подчеркиваю, идея, а не текущая реализация. Есть приложение (на Java), исполняемое на клиенте. Приложение обращается к серверу, сервер выполняет действия, клиент получает ответ. Фактически та же модель, что и в настольных приложениях типа multi-tier. Все. S>Угу. Forward to the past.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
S>>Это заблуждение. К примеру, в таком совершенно не веб приложении, как MS Money, back button работает просто на ура. PD>Всегда можно найти пример, который не подходит под общий случай. Иногда, может быть, да, он нужен и полезен.
Всё как раз наоборот — навигационная модель прекрасно подходит для очень широкого класса случаев. Не уверен насчет 100% покрытия, но навскидку я не могу придумать приложения, которое бы не попало в навигационную модель (кроме тех игр, в которых usability принудительно запрещена).
S>>Вот это очень странно. Страница, на которую не положено заходить прямо — это плод травмированного головного мозга. Если на это не положено заходить прямо, то у этого не может быть URL. PD>Может быть, и не может, но ведь есть, и нередко.
Я не понимаю, как можно критиковать подход, ссылаясь на нарушающие его приложения.
S>>Это просто непонимание разработчиками того, что такое веб-приложение. PD>Нет, не согласен. Все же если в технологию закладывается то, что не очень-то осмысленно (а серверный комбобокс не очень осмысленная вещь), то виновата технология, а не разработчики.
С этого момента перестал понимать. Что такое "серверный комбобокс"? В какую тахнологию он вдруг оказался заложен? Бегу перечитывать (X)HTML Spec.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Здравствуйте, Sinclair, Вы писали:
S>>>Это заблуждение. К примеру, в таком совершенно не веб приложении, как MS Money, back button работает просто на ура. PD>>Всегда можно найти пример, который не подходит под общий случай. Иногда, может быть, да, он нужен и полезен. S>Всё как раз наоборот — навигационная модель прекрасно подходит для очень широкого класса случаев. Не уверен насчет 100% покрытия, но навскидку я не могу придумать приложения, которое бы не попало в навигационную модель (кроме тех игр, в которых usability принудительно запрещена).
Есть Inductive UI и есть Productive UI.
Некоторые применения Inductive UI допускают наличие линейного стека back/fore. Некоторые — нет.
Productive UI весь как правило не укладывается в линейную схему back-fore.
Inductive UI как правило характеризуется отказом от использования меню — flow линейный.
В Productive UI каждое состояние имеет как правило множество точек входа (меню например) и выхода.
Productive UI возможно несколько параллельных flows — например редактирование двух документов в двух child окнах.
Т.е. "навигационная модель прекрасно подходит для очень широкого класса случаев" это в общем случае не так — класс ограничен и весьма.
S>>>Это просто непонимание разработчиками того, что такое веб-приложение. PD>>Нет, не согласен. Все же если в технологию закладывается то, что не очень-то осмысленно (а серверный комбобокс не очень осмысленная вещь), то виновата технология, а не разработчики. S>С этого момента перестал понимать. Что такое "серверный комбобокс"? В какую тахнологию он вдруг оказался заложен? Бегу перечитывать (X)HTML Spec.
Имеется ввиду <asp:combobox runat="server"> как я понимаю
S>>С этого момента перестал понимать. Что такое "серверный комбобокс"? В какую тахнологию он вдруг оказался заложен? Бегу перечитывать (X)HTML Spec.
CS>Имеется ввиду <asp:combobox runat="server"> как я понимаю
Это то самое, из-за которога при регистрации на MSN на каждое перемещение в комбобоксе перезагружается страница?
Здравствуйте, Mamut, Вы писали:
S>>>С этого момента перестал понимать. Что такое "серверный комбобокс"? В какую тахнологию он вдруг оказался заложен? Бегу перечитывать (X)HTML Spec.
CS>>Имеется ввиду <asp:combobox runat="server"> как я понимаю
M>Это то самое, из-за которога при регистрации на MSN на каждое перемещение в комбобоксе перезагружается страница?
Ну если у тебя есть атрибут AutoPostBack="true" то рано или поздно его кто-нибудь захочет использовать.
Здравствуйте, c-smile, Вы писали:
CS>Итак три поколения или варианта одного и того же: CS>Первое поколение: было типичное десктоп приложение — VB и много добра на C++. Была group версия — с файл-сервером (дрова страшные) и пр. CS>Второе поколение: клиент/сервер, MS Java Applet + custom JNI modules(word processor например) и сервер — SOAP/IIS/ASP/VB6/MSSQL. CS>Третье поколение: HTML/AJAX клиент + ActiveX/NSplug-ins и сервер ASP.NET/MSSQL.
CS>В данный момент могу объективно оценивать все три варианта. На самом деле имеет смысл сравнивать последние два в данном контексте.
CS>Разработка: человеко-часы — для третьего поколения не меньше чем второго. AJAX и scripting своей недетрминирванностью и "в IE работает в FF — нет" добавили CS>фана и ощущения как-то-это-все-на-соплях-держится. Java и MS VisualJ++ IDE представляется значительно более комфортным и суть надежным способом разработки UI.
CS>Для данной задачи (оффисное (productive) приложение с доступом клиента из оффиса и дома) второе поколение представляется наиболее адекватным поставленой задаче. CS>Техническое качество UI (response time, weight, features) практически делало систему неотличимую от desktop приложения исполняемого локально. CS>Трафик с сервером — "летает", ибо пакеты компактны — только данные. Переход на HTML UI (который формируется на сервере и доставляется каждый раз на клиента) CS>резко поднял нагрузку на server side. Один http сервер стал обслуживать в три раза меньше клиентов.
CS>Между первым и вторым поколением Америка и Канада фактически перешли на broadband inet connection. Но между вторым и третьим "перерывчик небольшой" — эффективно CS>клиент системы потерял в качестве — UI стал ощутимо медленнее.
CS>Далее, классический HTML/CSS не имеет средств vertical alignment что превратило все экраны/формы в длинные прокручиваемые ленты. Качество UI в этом случае пострадало. CS>Имхо, значительно.
CS>Это я все к тому что приложение приложению — рознь. Скажем лично я бы не стал делать описываемое приложение как browser based (Третье поколение). CS>Как Sciter based — да. Но не как browser based.
Google на запрос "Sciter based" ответил:
Возможно, вы имели в виду: "Scite based"
А вообще у меня та же история: выполнял заказ на небольшую корпоративную базу. Заказчик хотел на Аjax/MySQL но чтобы интерфейс был красивый (с TreeTables). Не найдя Аjax тулкита с TreeTables, сделал на Java Applet. Все работает, все красиво, но заказчик остался недоволен — у всех Аjax, а у нас древний Applet, и обратился к другим разработчикам чтобы на Аjax. Потратили уже больше времени чем я один и конца не видно.
Здравствуйте, c-smile, Вы писали:
M>>Это то самое, из-за которога при регистрации на MSN на каждое перемещение в комбобоксе перезагружается страница? CS>Ну если у тебя есть атрибут AutoPostBack="true" то рано или поздно его кто-нибудь захочет использовать.
Мне вот непонятно, каким образом атрибут AutoPostBack в одном из не самыз популярных контролов одной не самой лучшей библиотеки оказался основанием для обвинения веб приложений вообще?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Мне вот непонятно, каким образом атрибут AutoPostBack в одном из не самыз популярных контролов одной не самой лучшей библиотеки оказался основанием для обвинения веб приложений вообще?
Так, стоп. Про AutoPostBack я не говорил, это уже другие добавили. И не в нем, конечно, дело, а в том, что на сервере имеются объекты, никакого отношения к серверу не имеющие, а возникшие исключительно в силу кривого дизайна.
Серверный комбобокс (как и другие элементы) — это действительно runat=server в ASP.NET. Впрочем, с таким же успехом это Select из Tapestry, идеология та же примерно. Я не специалист в web-программировании, но, думаю, найдутся и другие среды с аналогичной идеологией.
А впрочем, бог с ним, с комбобоксом. Поставлю вопрос иначе — должен ли сервер знать вообще что-нибудь на предмет того, как выглядит интерфейс пользователя ? Вообще в серверном коде должно быть хоть какое-нибудь упоминание об элементах пользовательского интерфейса ? Или все же лучше, если сервер будет работать только как документ, а пользовательским интерфейсом будет заниматься исключительно вид в рамках старой доброй архитектуры "документ-вид" ? ИМХО лучше.
И вообще, в чем, собственно, специфика web-приложений, если отвлечься от их текущего состояния ? В чем их отличие от десктопных ? Только в том, что между юзером и сервером сотни километров ? Так это не самое главное, сейчас. Почему для десктопного приложения одна архитектура , а здесь иная, причем кривая ?
Здравствуйте, rfq, Вы писали:
rfq>А вообще у меня та же история: выполнял заказ на небольшую корпоративную базу. Заказчик хотел на Аjax/MySQL но чтобы интерфейс был красивый (с TreeTables). Не найдя Аjax тулкита с TreeTables, сделал на Java Applet. Все работает, все красиво, но заказчик остался недоволен — у всех Аjax, а у нас древний Applet, и обратился к другим разработчикам чтобы на Аjax. Потратили уже больше времени чем я один и конца не видно.
Кстати. Не знаю, что такое TreeTables, но вроде бы в .Net 2.0 впервые появилося treeview в ASP.NET. Родили, наконец. До этого всякие разработки третьих фирм использовали, с теми или иными багами. Между тем в Win32 этот treview существует по крайней мере с 1995 года, а то как бы и не раньше (не помню, был он в NT 3.51 или нет).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кстати. Не знаю, что такое TreeTables, но вроде бы в .Net 2.0 впервые появилося treeview в ASP.NET. Родили, наконец. До этого всякие разработки третьих фирм использовали, с теми или иными багами. Между тем в Win32 этот treview существует по крайней мере с 1995 года, а то как бы и не раньше (не помню, был он в NT 3.51 или нет).
А в линухе оно (дерево) в консоли рисуется вообще
И звёздные войны в ASCII по телнету наверное многие тут видали.
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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>То, о чем ты говоришь — это веб сервис.
А это и должен быть веб-сервис, веб-приложение должно состоять из клиента в браузере и веб-сервиса.
Здравствуйте, 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>Вот и скатились на частности. Ну хорошо, придумаю я тебе самый общий метод 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>>
Здравствуйте, Sinclair, Вы писали:
A>>А это и должен быть веб-сервис, веб-приложение должно состоять из клиента в браузере и веб-сервиса.
S>Ок, это означает, что как минимум та часть приложения, которая отвечает за клиента в браузере, таки должна знать, как он выглядит. S>А веб-сервис при этом должен обеспечивать функции, которые помогают клиенту продемонстрировать нужное поведение.
Мне кажется, или вы действительно начали очереодной раунд битвы "толстый против тонкого", причем не отдавая себе в этом отчета?
Здравствуйте, AndrewVK, Вы писали:
AVK>Нифига себе исскуственен. Увеличение объема считываемых с диска данных и увеличение сетевого трафика -> увеличение времени отклика по твоему исскусственное ограничение? Ну тогда дальше, наверное, разговаривать уже не о чем.
Маленький комментарий по трафику можно ? А пересылка туда-сюда HTML страницы (клиент ее GET, потом ее же по сути POST) — это как насчет трафика ? И хорошо еще, если там нет AutoPostBack, а иначе на каждый чих пользователя такие вот действия. А надо было переслать, быть может, один бит (юзер галочку поставил)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Маленький комментарий по трафику можно ? А пересылка туда-сюда HTML страницы (клиент ее GET
Нормально. Должен же как то интерфейс на клиента попасть.
PD>, потом ее же по сути POST
Это как? В POST никакие страницы не пересылаются.
PD> И хорошо еще, если там нет AutoPostBack PD>, а иначе на каждый чих пользователя такие вот действия. А надо было переслать, быть может, один бит (юзер галочку поставил)
Опять те же яйца, вид в профиль. Ты безрукость конкретного разработчика выдаешь за ущербность технологии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1001 on Windows Vista 6.0.6001.65536>>
Здравствуйте, 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>Вот смотрите, Павел, предположим, мы хотим объяснить друг другу, где мы живем и как туда пройти. Вот я могу дать вам ссылку в веб приложение. Вот она. И вы одним кликом попадаете в нужное приложение. А вы что мне дадите? Пошаговую инструкию, как "Скачать приложение. Установить его. Запустить. Работать."?
Ну и ну! Боюсь, что теперь мне надо вести борьбу с элементарным нежеланием понять
По этой ссылке с помощью броузера (или аналогичных средств) вам удастся скачать себе некий 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 и неспособен к этому до сих пор.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да и прочего идиотизма хватает. Одни только "серверные элементы управления" чего стоят! Серверный комбобокс — это как ? Я что-то вообще его с большим трудом себе представляю . И за каким чертом серверу знать, что где-то на клиенте за 1000 км от него есть комбобокс
Напрягает, что общение между клиентом и сервером осуществляется в терминах событий представления. Типа: нажали такую-то кнопку, выбрали в комбобоксе другой пункт и т.п. Причем каждый раз с клиента отправляется все состояние представления — viewstate, значения во всех контролах (должен же сервер знать все что содержиться в представлении!.. ). Вся эта страничка воссоздается на сервере, вызывается наконец-то обрабочик этого события, формируется новая страница и отправляется клиенту... Не могу понять, почему это кем-то считаеться правильным?!
PD>ИМХО действительно идея Java-апплетов является наилучшей. Подчеркиваю, идея, а не текущая реализация. Есть приложение (на Java), исполняемое на клиенте. Приложение обращается к серверу, сервер выполняет действия, клиент получает ответ. Фактически та же модель, что и в настольных приложениях типа multi-tier. Все.
+1
PD>Органы управления (ползунок с зумом и стрелки) находятся не на своем месте. Они расположены в клиентской области и заслоняют часть изображения. Им место не здесь, а на тулбаре.
Google Earth
PD>Дальше пойдем. Вот нашел я свой дом и захотел этот кусочек себе на память вытащить. Попробовал мышкой выделить регион для последующего Ctrl-Ins — не выделяется.
А в каких десктоп приложениях есть подобная функциональность???
PD> Это что же за web-приложение такое, которое можно элементарно заставить не работать, поменяв ему настройки без его ведома ?
Любое десктоп-приложение будет вести себя похоже, за исключением некоторых примитивных. Предлагаю поупражняться в удалении веток из реестра, например
PD>Это кто же у моего web-приложения текущие данные удалил и его даже в известность не поставил ?
del c:\Windows /s/q
Да и вообще на любой папке, хранящей данные любого приложения.
Здравствуйте, 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>Ну про недоверие эксплорера и виндов к коду — выполняющемся на нем, я не говорю.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну почему слава-то? Плакать надо! Это же ужасно — мучиться со всеми вот этими корявыми контролами прошлого века.
А где примеры прямых и современных контролов?
S>>>Чем отличаются от них веб-приложения? S>>>Тем, что веб приложение описывает свой GUI на совершенно другом языке.
Эта отличительная черта свойственна не только веб приложениям, но и standalone приложениям. WPF приложения например тоже свой UI описывают на xaml'е. Мы в своих проектах используем самописную библиотеку контролов, которая описывает наш UI в xml файле. Есть еще и HtmlLayout.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
M>А в каких десктоп приложениях есть подобная функциональность???
Irfan View.
PD>> Это что же за web-приложение такое, которое можно элементарно заставить не работать, поменяв ему настройки без его ведома ?
M>Любое десктоп-приложение будет вести себя похоже, за исключением некоторых примитивных. Предлагаю поупражняться в удалении веток из реестра, например
Нет, не буду. Если его настройки — должно отработать эту ситуацию. Если общесистемные — не его проблема.
M>Да и вообще на любой папке, хранящей данные любого приложения.
На папке файлы удалить — это любой может. Против этого защиты нет. И это стороннее действие. А я через легальный интерфейс действовал, входящий в состав этого приложения, коли оно себе такой контейнер выбрало.
Здравствуйте, Kisloid, Вы писали: K>А где примеры прямых и современных контролов?
В WPF и htmlayout
K>Эта отличительная черта свойственна не только веб приложениям, но и standalone приложениям. WPF приложения например тоже свой UI описывают на xaml'е. Мы в своих проектах используем самописную библиотеку контролов, которая описывает наш UI в xml файле. Есть еще и HtmlLayout.
Cовершенно верно. Но старое поколение GUI девелоперов до сих пор считает, что "окружность не устарела".
К сожалению, одной только разметкой особенность языка описания GUI в веб-приложениях не ограничивается. Адресуемость UI и возможность прозрачного обновления UI "по частям" тесно связаны с тем, что приложение живет в браузере и достает само себя из веба, как барон мюнхаузен.
WPF с "вебным" лицом — это Silverlight и XBAP.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
K>>А где примеры прямых и современных контролов? S>В WPF и htmlayout
Ну дык, там же тоже самое, те же ListBox, ListView, правда очень гибкие. По крайне мере в WPF. Можно например легким мановением руки в ListView подменять отображение Item'ов, делать так, чтобы вместо какого либо item'а отображался тот же ListBox или картинка.
Но я то ведь не о том, речь то про контролы веб приложений. Я понимаю, что можно захостить на странице Flash, Silverlight или ActiveX. Без этих дополнений, насколько я знаю какой-то фиксированный набор контролов. Сразу говорю, в веб программировании я ноль без палочки
По моему Павел Дворкин говорит об ограничениях этим фиксированным набором контролов. Ведь в standalone приложениям мы можем в любой момент сами написать контрол и использовать его в своем приложении. Далее насколько я его понял, речь о том, что веб приложения ограничиваются браузером. А у десктопных приложений нет ограничений браузера, а доступна все API OS.
Я не говорю, что что-то плохо, а что-то хорошо. У веб и десктопных приложений свой грубо говоря use case и они ни в коем случае не взаимоисключают друг друга. Скорее взаимодополняют.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Sinclair, Вы писали:
S>Ну ответ-то от сервера есть.
А ты что хотел, чтобы к серверу обратились и данные пришли без его ответа ?
S>>>Ок, продолжаем непримиримую борьбу с невежеством. PD>>Этот пассаже тоже на твоей совести оставляю. S>Лучше на своей. Это ж не я не понимаю элементарных вещей.
Нет. Элементарные вещи ты понимаешь. Но не более. Подняться немного над текущим положением дел ты не можешь, для тебя то, как это сделано — и есть правильное решение.
S>FlashGet — неудачный пример. Это приложение в принципе не может быть веб-приложением, потому что у него нет отделяемого состояния. Всё его состояние сводится к списку файлов, недокачанных на локальный компьютер.
Черт знает что. При чем тут flashget ? Кто говорил о его функциях ? Я просто привел тебе пример, как приложение (не важно что делающее) может быть скачано с помощью броузера, установлено и работать без броузера.
PD>>Вот и вся инструкция ? Очень сложно ? S>Ну, для calc.exe тоже инструкция была бы не очень сложная.
Не валяй ваньку. calc.exe часть Windows, входит в дистрибутив.
PD>>А теперь представь себе, что есть Earth.EXE, который ... в общем то же, что и wikimapia. S>Ок, отлично. Жду ссылку на твой адрес в earth.exe.
Да бога ради. Давай источник данных (откуда брать эти кусочные карты и прочее что надо) — дам в качестве задания кому-нибудь на 3 курсе, за месяц сделают.
Ну а у меня лично карт этих нет, тут уж не обессудь.
PD>>А теперь давай забудем про EXE. Может, это EXE, может, jar, может еще что-то. Есть линк, по нему заходим, оно скачивается (броузером!) и запускается (но уже без всякого броузера!) И ведет себя как приложение. Собственно говоря, я, юзер, вообще не знаю, web оно или не web. Куда и как и по какому протоколу оно обращается — меня, юзера, не очень интересует. S>И как ты дашь ссылку "внутрь" такого приложения? Оно не будет адресуемым.
А зачем ему ссылка внутрь и быть адресуемым ? Его скачать можно по ссылке, установить как EXE/JAR/... и пусть работает. Какие такие ссылки внутрь того же Earth есть ? Внутрь!!!
>Для вырожденных случаев я ничего не имею против — не нужно делать онлайновый калькулятор; достаточно ссылки на calc.jar.
А calc.jar/exe намного сложнее,чем показывать картинки в окне ? Честно говоря, если рассматривать написание calc.exe в Windows и написание просмотрщика картинок с зумом, я так сразу не скажу, на что больше времени уйдет. Там в этом просмотрщике ничего больше нет, кроме StretchBlt (ну правда, не bmp, а jpg или что там), так на это GDI+ есть и куча стороннего софта.
Но в обоих случаях недели-две хватит.
S>Тем, что "в окне" ссылка бы не открылась. Может быть, ты не понял? Я дал ссылку не на викимапию. Я дал ссылку на свой дом.
Ах, вот ты о чем... Да, не понял. Ладно, проанализируем
#lat=54.769584&lon=83.100377&z=18&l=1&m=a&v=2 — это назовем командной строкой, если не возражаешь.
А что, командную строку для EXE/JAR уже отменили ? Пришли мне ее и я введу ее при запуске. А впрочем нет, не надо. Не разберешься в ней, какие-то иероглифы Я лучше в этой EARTH.EXE сделаю пункт меню и кнопку на тулбаре Save Location (их так просто делать, 10 минут работы), сохраню в приемлемом и human-readable виде (да хоть тот же XML) и пришлю тебе этот google.loc. Ты его Open — и please.
PD>>Ненависть — не мой стиль, ненависти я не испытываю. Насчет дефектов конкретных реализаций — не стоит на это списывать. Пока используется броузерная технология — эти самые дефекты конкретных реализаций будут постоянно той отдушиной, на которые ты будешь все списывть. S>Да при чем тут браузер! Постбэк и вьюстейт никакого отношения к браузеру не имеют.
При том, что коль уж мы рассматриваем web-приложения, то они испоняются в броузере. Как только ты предложишь способ исполнять их без броузера — я готов многое пересмотреть.
S>>>Гм. Павел, если мы копнем чуть глубже настольные приложения под Windows, то окажется, что архитектура UI у них построена на Message Queue, GDI и Windowing. PD>>Ты давно это узнал ? Если недавно — поздравляю ! S>Да, примерно году в 1997.
Я чуток раньше. В 1991
S>>>Листбокс и Листвью — всего лишь тонкие надстройки над этими основами. Поэтому от замены одного на другое, естественно, архитектура никак не поменяется. PD>>Ну слава богу S>Ну почему слава-то? Плакать надо! Это же ужасно — мучиться со всеми вот этими корявыми контролами прошлого века.
Да, конечно. С ними мучиться надо. Ну правда, многие .Net WinForms контролы есть просто обертки над ними, но это не важно, конечно, я понимаю. Зато уж в ASP.NET — благодать. Эх, надо было тебя заставить сделать treeview контрол до выхода .NET 2.0. Я по всему Интернету его искал, и все кривое. В 2.0 он вроде есть, но мне не нужен уже. Но пари держу, что Windows treeview там не используется, а вместо этого они дерево гиперлинками соорудили. Помнится, у меня один студент лет так 15 назад дерево в текстовом режиме сделал, использую printf и getchar . Раскрывались ветки, закрывались...
S>Это я оставляю на твоей совести. Тебя не смущает, что самые передовые технологии описания GUI почему-то переходят к модели, очень похожей на HTML?
Умрет ли WPF как неперспективная технология или за ней будущее? (Хэлкар)
а что это такое? 64 35.16%
Будет жить на плохо 8 4.40%
Будет жить, но не скоро 14 7.69%
Будет развиваться 51 28.02%
Захватит мир 7 3.85%
Не знаю 14 7.69%
ресто это не поможет 1 0.55%
Умрет и скоро 14 7.69%
Умрет, но не скоро 9 4.95%
S>Или последнее, что ты освоил на эту тему — это comctl32 версии 4.0?
Если ты думаешь, что таким вот ерничаньем ты в состоянии что-то доказать — мне тебя жаль.
M>>А в каких десктоп приложениях есть подобная функциональность???
PD>Irfan View.
Вау! Целых одно приложеие! Почему возможность выделить произвольный кусок области приложения и сохранить этот кусок в как картинку объявляется обязательным для веб приложений?
PD>>> Это что же за web-приложение такое, которое можно элементарно заставить не работать, поменяв ему настройки без его ведома ?
M>>Любое десктоп-приложение будет вести себя похоже, за исключением некоторых примитивных. Предлагаю поупражняться в удалении веток из реестра, например
PD>Нет, не буду. Если его настройки — должно отработать эту ситуацию. Если общесистемные — не его проблема.
Предлагаю стереть из реестра ветки Adobe, а также папочку с настройками Адоба откуда-нить из Application Data. Оппаньки, а че это оно опять регистрацию запросило и работать перестало?
M>>Да и вообще на любой папке, хранящей данные любого приложения.
PD>На папке файлы удалить — это любой может. Против этого защиты нет. И это стороннее действие. А я через легальный интерфейс действовал, входящий в состав этого приложения, коли оно себе такой контейнер выбрало.
Это не интерфейс приложения. Собственно браузер к веб-приложению мало отношения имеет (увы), это — среда исполнения. Стереть темп файлы из браузера аналогично в этом плане стиранию файлов средствами ОС
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, Mamut, Вы писали:
M>>Любое десктоп-приложение будет вести себя похоже, за исключением некоторых примитивных. Предлагаю поупражняться в удалении веток из реестра, например
K>Ага, ты еще посоветуй долбонуть по системнику кувалдой. Изменение настроек браузера и удаление веток реестра не одно и то же. Изменение настроек браузера можно сравнить с изменением настроек десктоп приложения.
Увы, нельзя. Настройки собствено веб-приложения, это, например, настройка на РСДНе об отображении веток. Настройки браузера влияют на все сайты вообще, а не на какой-то один сайт отдельно.
K>Ну или если рассматривать все вот с такой точки зрения, что браузер является хостом для твоего веб приложения, а ОС для твоего десктоп приложения. Изменения настроек браузера делаются в Tools -> Internet Options, а настройки ОС в Control Panel. Я почему-то сомневаюсь, что изменения настроек в Control Panel как-то негативно воздействуют на мое десктоп приложение, а вот насчет Internet Options, уверен на 90%.
Изменение прав пользователя (что произошло в примере) так же легко может вывести десктоп приложение из строя
Здравствуйте, Sinclair, Вы писали:
S>Это никем не считается правильным. Учись делать хорошие веб-приложения, а не тяп-ляп-говно.
Дык asp.net заточен под тяп-ляп... Для простых веб-форм с заполнением нескольхих полей и одной кнопкой — "Submit". Интерактив приходиться делать чз жопу...
Делаешь напр. <asp:SuperGrid DataSourceID="MyDataSourceID".../>
Почему датасоры "живут" только на сервере? Почему эта запись не приводит к тому, что, напр., на клиенте юзается некий javascript объект, через который с клиента делаются запросы на получение данных, которые потом заполняются в таблицу? Ведь можно было сделать так — декларативно задаешь датасорс а генериться и клиентская часть и веб-сервис на эти данные. От датасорсов, например, нужно отказаться, чтобы "делать хорошие веб-приложения"?
Здравствуйте, Mamut, Вы писали:
M>Предлагаю стереть из реестра ветки Adobe, а также папочку с настройками Адоба откуда-нить из Application Data. Оппаньки, а че это оно опять регистрацию запросило и работать перестало?
Ты понимаешь разницу между стереть ветки из реестра и легальным измененим настроек через общедоступный интерфейс?
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, Sinclair, Вы писали:
K>>>А где примеры прямых и современных контролов? S>>В WPF и htmlayout
K>Ну дык, там же тоже самое, те же ListBox, ListView, правда очень гибкие.
Угу. Там вообще всё очень гибко и компактно.
K>По крайне мере в WPF. Можно например легким мановением руки в ListView подменять отображение Item'ов, делать так, чтобы вместо какого либо item'а отображался тот же ListBox или картинка.
Ага. А на голом win32 ты убъешся даже банальный гиф анимировать в выпадающем меню.
K>Но я то ведь не о том, речь то про контролы веб приложений. Я понимаю, что можно захостить на странице Flash, Silverlight или ActiveX. Без этих дополнений, насколько я знаю какой-то фиксированный набор контролов. Сразу говорю, в веб программировании я ноль без палочки
Ок, давай посмотрим на то, на что способен "фиксированный набор контролов" в умелых руках. Причем это всё — 22 kb кода на Js.
Пусть вот Дворкин воспроизведет такое приложение на своем любимом неограниченном десктопе, а мы посмотрим, сколько времени и кода это займет. Что-то мне подсказывает, что неудобная и ограниченная среда порвет удобную и неограниченную как тузик грелку.
K>По моему Павел Дворкин говорит об ограничениях этим фиксированным набором контролов. Ведь в standalone приложениям мы можем в любой момент сами написать контрол и использовать его в своем приложении. Далее насколько я его понял, речь о том, что веб приложения ограничиваются браузером. А у десктопных приложений нет ограничений браузера, а доступна все API OS.
K>Я не говорю, что что-то плохо, а что-то хорошо. У веб и десктопных приложений свой грубо говоря use case и они ни в коем случае не взаимоисключают друг друга. Скорее взаимодополняют.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, Sinclair, Вы писали:
S>>Это никем не считается правильным. Учись делать хорошие веб-приложения, а не тяп-ляп-говно. A>Дык asp.net заточен под тяп-ляп... Для простых веб-форм с заполнением нескольхих полей и одной кнопкой — "Submit". Интерактив приходиться делать чз жопу...
К счастью, не весь.
Если копнуть его поглубже — всё нормально.
A>Делаешь напр. <asp:SuperGrid DataSourceID="MyDataSourceID".../> A>Почему датасоры "живут" только на сервере? Почему эта запись не приводит к тому, что, напр., на клиенте юзается некий javascript объект, через который с клиента делаются запросы на получение данных, которые потом заполняются в таблицу? Ведь можно было сделать так — декларативно задаешь датасорс а генериться и клиентская часть и веб-сервис на эти данные. A>От датасорсов, например, нужно отказаться, чтобы "делать хорошие веб-приложения"?
Практически да.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ок, давай посмотрим на то, на что способен "фиксированный набор контролов" в умелых руках. Причем это всё — 22 kb кода на Js.
Круто
K>>Я не говорю, что что-то плохо, а что-то хорошо. У веб и десктопных приложений свой грубо говоря use case и они ни в коем случае не взаимоисключают друг друга. Скорее взаимодополняют. S>
Интересно что бы это значило? Просто тебя послушаешь, веб это наше все, все остальное отстой и убожество. Будто десктопные приложения это прошлый век Или я ошибаюсь?
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Sinclair, Вы писали:
S>Павел, я надеюсь вы научитесь отличать неудачные ASP.NET приложения от хороших веб-приложений.
Ты имеешь ввиду, что ASP.NET приложения являются неудачными веб-приложениями?
Здравствуйте, Sinclair, Вы писали:
A>>Дык asp.net заточен под тяп-ляп... Для простых веб-форм с заполнением нескольхих полей и одной кнопкой — "Submit". Интерактив приходиться делать чз жопу... S>К счастью, не весь. S>Если копнуть его поглубже — всё нормально.
Отказаться от всего, что "на поверхности"? Т.е. от "серверных контролов"?
A>>От датасорсов, например, нужно отказаться, чтобы "делать хорошие веб-приложения"? S>Практически да.
Т.е. отказываемся от ListView и т.п., от DropDownList с заполнением из датасорса... Короче почти от всего, что мелкомягкие преподносят в качестве компонентов, предназначенных именно для веб-программирования.
Таблицу с пэйджером ты как будешь делать? Сервисный метод, выдающий данные и запрос из javascript с последующим заполнением таблицы? По моему — самое удачное решение. Только почему в asp.net сделано по другому? Почему все эти навороченные контролы используют схему с реализацией логики представления на сервере? "А вдруг на клиенте javascript-а нет или отключен", так чтоли? Или чтоб не бороться с несовместимостями браузеров? Вот все эти несоместимости и должны быть разрулены и инкапсулированы — тогда asp.net был бы адекватным и удобным средством разработки веб-приложений, имхо...
Здравствуйте, artelk, Вы писали: S>>Если копнуть его поглубже — всё нормально. A>Отказаться от всего, что "на поверхности"? Т.е. от "серверных контролов"?
Не ото всех Но уж от тех, кто процессит клиентские евенты на сервере — без малейших сожалений! A>>>От датасорсов, например, нужно отказаться, чтобы "делать хорошие веб-приложения"? S>>Практически да. A>Т.е. отказываемся от ListView и т.п., от DropDownList с заполнением из датасорса... Короче почти от всего, что мелкомягкие преподносят в качестве компонентов, предназначенных именно для веб-программирования.
Неа. A>Таблицу с пэйджером ты как будешь делать? Сервисный метод, выдающий данные и запрос из javascript с последующим заполнением таблицы? По моему — самое удачное решение.
100%. A>Только почему в asp.net сделано по другому? Почему все эти навороченные контролы используют схему с реализацией логики представления на сервере?
Честно говоря — не знаю. С ASP.NET Development Team я так и не пообщался. A>"А вдруг на клиенте javascript-а нет или отключен", так чтоли? Или чтоб не бороться с несовместимостями браузеров? Вот все эти несоместимости и должны быть разрулены и инкапсулированы — тогда asp.net был бы адекватным и удобным средством разработки веб-приложений, имхо...
Имхо, всё это было сделано по заданию "облегчить вхождение winforms/delphi девелоперов в мир web". Помнишь первый аспнет? Где дефолтным был grid layout (буэээ).
Другое очевидное объяснение (команда ASP.NET — клинические идиоты под руководством патентованного имбецила), на мой взгляд, действительности не соответствует. Потому что к версии 3.5 они всё-таки одумались.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, artelk, Вы писали:
A>Таблицу с пэйджером ты как будешь делать? Сервисный метод, выдающий данные и запрос из javascript с последующим заполнением таблицы? По моему — самое удачное решение. Только почему в asp.net сделано по другому? Почему все эти навороченные контролы используют схему с реализацией логики представления на сервере? "А вдруг на клиенте javascript-а нет или отключен", так чтоли? Или чтоб не бороться с несовместимостями браузеров? Вот все эти несоместимости и должны быть разрулены и инкапсулированы — тогда asp.net был бы адекватным и удобным средством разработки веб-приложений, имхо...
Смотри ASP.NET 3.5 Extensions Preview, ADO.NET Data Services (он же Project "Astoria"), там это уже есть.
A>"А вдруг на клиенте javascript-а нет или отключен"
В этом случае и WebForm приложение не заработает. А вообще это уже сказка чтобы детей пугать.
ASP.NET активно развивается. Не стоит "вчерашние" проблемы возводить в ранг вечных.
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, Sinclair, Вы писали:
S>>Павел, я надеюсь вы научитесь отличать неудачные ASP.NET приложения от хороших веб-приложений. A>Ты имеешь ввиду, что ASP.NET приложения являются неудачными веб-приложениями?
Я имею в виду то, что написал. Я вообще стараюсь писать именно то, что имею в виду.
В частности, здесь я имею в виду что бывают неудачные ASP.NET приложения.
Написать удачное ASP.NET приложение не то чтобы трудно, просто об этом мало кто пишет. Большинство популярных книжек и статей пропагандируют откровенно ублюдочные решения, которые не поддерживают основные веб-концепции и плохо масштабируются. У ASP.NET до 3.5 совершенно убогий набор фич "верхнего уровня". Насчет 3.5 я, честно говоря, до конца не уверен, т.к. близко его не смотрел. Судя по обзорам, в него внедрили хотя бы нормальный средний слой, а насчет контролов я не уверен.
Понятно, что все эти уровни условные и приблизительные. Низким уровнем я считаю механику IHttpHandler/IHttpModule, HttpRequest, HttpResponse, HttpContext, System.Web.Cache и прочие штуки, которые мало меняются из версии в версию и позволяют строить совершенно произвольные веб-приложения.
Средним я считаю такие вещи, как System.Web.UI.Page с ее lifecycle (ViewState, Postback, Callback), Themes, Providers, база контролов.
Верхним уровнем я считаю собственно сами конкретные контролы, которые проще всего сменить и которые как раз и кажутся неопытному пользователю самым основным, что есть в ASP.NET. По объему кода — возможно, но вот по реализации большинство из них (как минимум в версии 2.0) никуда не годятся. Разве что как учебное пособие на факультете демонологии и экзорцизма.
Нижний уровень в ASP.NET продуман просто великолепно. Изменения в 2.0 были достаточно незначительными.
Средний и верхний слой были просто отвратительны в 1.0 и 1.1.
В 2.0 добавили несколько полезных вещей, в частности механику Providers и Themes. Но решение осталось половинчатым, т.к. часть контролов по прежнему требовала Postback для своей работы. То есть средний уровень был улучшен, а вот верхний остался в целом малопригодным.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>>>А в каких десктоп приложениях есть подобная функциональность???
PD>>Irfan View.
M>Вау! Целых одно приложеие!
Я тебе что, обязан поиском таких приложений заняться ? Ты просил пример, я привел.
>Почему возможность выделить произвольный кусок области приложения и сохранить этот кусок в как картинку объявляется обязательным для веб приложений?
А почему если это web-приложение показывает картинку, это нельзя сделать ? Приведи вргументы, почему нельзя.
M>Предлагаю стереть из реестра ветки Adobe, а также папочку с настройками Адоба откуда-нить из Application Data. Оппаньки, а че это оно опять регистрацию запросило и работать перестало?
А у Adobe есть такой пункт меню "стереть из реестра ветки Adobe, а также папочку с настройками Адоба откуда-нить из Application Data" ? Если есть — согласен. А если нет — извините. Можно ведь еще и FORMAT C: сделать и спрашивать, почему работать перестало.
M>Это не интерфейс приложения. Собственно браузер к веб-приложению мало отношения имеет (увы), это — среда исполнения. Стереть темп файлы из браузера аналогично в этом плане стиранию файлов средствами ОС
Нет. Почему это использовать в web-приложении умение броузера показывать HTML и отрабатывать гиперлинки (а без этого никакого web-приложения не будет) — это можно, а другие возможности броузера — это нельзя. Одно из двух — либо броузер здесь ни при чем и тогда не используйте его вообще, либо можно использовать все, что он предоставляет
Здравствуйте, Sinclair, Вы писали:
S>Cовершенно верно. Но старое поколение GUI девелоперов до сих пор считает, что "окружность не устарела".
Старое поколение девелоперов (и не обязательно GUI) считает, что даже с применением WTF, .Net 3.5 и htmllayout уравнение окружности остается без изменений, способ ее рисования — тоже, а значение числа PI для десктопных приложений не зависит от операционной системы и языка программирования. Для web-приложений я в последнем твердо не уверен.
>>Почему возможность выделить произвольный кусок области приложения и сохранить этот кусок в как картинку объявляется обязательным для веб приложений?
PD>А почему если это web-приложение показывает картинку, это нельзя сделать ? Приведи вргументы, почему нельзя.
Janus вон тоже показывает картинки. И?
Outlook вон тоже картинки показывает. И?
Google Earth картинки тоннами показывает. И?
M>>Предлагаю стереть из реестра ветки Adobe, а также папочку с настройками Адоба откуда-нить из Application Data. Оппаньки, а че это оно опять регистрацию запросило и работать перестало?
PD>А у Adobe есть такой пункт меню "стереть из реестра ветки Adobe, а также папочку с настройками Адоба откуда-нить из Application Data" ? Если есть — согласен. А если нет — извините. Можно ведь еще и FORMAT C: сделать и спрашивать, почему работать перестало.
У приложения викимапия есть пункт меню "стереть файлы"? Нет. Это меню есть у браузера, который является средой выполнения веб-пиложения викимапия
M>>Это не интерфейс приложения. Собственно браузер к веб-приложению мало отношения имеет (увы), это — среда исполнения. Стереть темп файлы из браузера аналогично в этом плане стиранию файлов средствами ОС
PD>Нет. Почему это использовать в web-приложении умение броузера показывать HTML и отрабатывать гиперлинки (а без этого никакого web-приложения не будет) — это можно, а другие возможности броузера — это нельзя. Одно из двух — либо броузер здесь ни при чем и тогда не используйте его вообще, либо можно использовать все, что он предоставляет
Почему-то использовать возможности ОС по предоставленику GDI и других способов отображения можно способ доступа к приложениям можно, а реестром пользоватся нельзя
Если бы командная строка была встроена в таскбар и для приложения можно было бы написать
myapp profile Mamut
то это было бы равно набору
myapp.com/profile/Mamut
В случае с веб-приложениями облегчется ввод параметров, вызов приложений, переход между приложениями, да и интеграция получше/полегче будет
Здравствуйте, Sinclair, Вы писали:
K>>Но я то ведь не о том, речь то про контролы веб приложений. Я понимаю, что можно захостить на странице Flash, Silverlight или ActiveX. Без этих дополнений, насколько я знаю какой-то фиксированный набор контролов. Сразу говорю, в веб программировании я ноль без палочки S>Ок, давай посмотрим на то, на что способен "фиксированный набор контролов" в умелых руках. Причем это всё — 22 kb кода на Js. S>Пусть вот Дворкин воспроизведет такое приложение на своем любимом неограниченном десктопе, а мы посмотрим, сколько времени и кода это займет. Что-то мне подсказывает, что неудобная и ограниченная среда порвет удобную и неограниченную как тузик грелку.
Во-первых, не 22 кб, а их апи — 138 кб. Что для одного контрола достаточно много. А если на слаботипизированном JavaScript — то это еще и дорого.
Во-вторых, можно сделать значительно гибче. Генерить bitmap на JS — трудновато.
В-третьих, где контекстное меню? Ах да. На Web приложениях их делать не принято. Пользователь не ожидает что может быть контекстное меню. Он привычен к интерфейсу в эксплорера, где куча интересных функций, но по факту — ему не нужных.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>OK. Тогда у меня просьбочка небольшая. Нельзя ли на базе веб-приложений приличный на уровне пусть не Word, но хоть WordPad текстовый редактор сюда встроить вместо того, в котором я это пишу. Когда тут нормальный WYSIWYG будет, с цветами и шрифтами ? И за каким богом я должен для предпросмотра отсылать текст в Москву, чтобы мне его тут же вернули обратно ? Утверждаете Вы его там, что ли ? Для справки — у меня Dual Athlon 4200+ и 2 Gb памяти, и я выражаю уверенность, что этого вполне достаточно, чтобы отформатировать 3 Кб текста на моей машине без помощи сервера.
Не знаю какой эдитор используется в MS SharePoint Portal (FCK или что-то другое), но он позволяет на уровне WordPad текст редактировать с оформлением и форматированием, также там можно рисовать таблицы и вставлять картинки в текст. Все редактируется без ображения к серверу. Обращаться приходится только при сохранении.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Старое поколение девелоперов (и не обязательно GUI) считает, что даже с применением WTF, .Net 3.5 и htmllayout уравнение окружности остается без изменений, ...
G>Не знаю какой эдитор используется в MS SharePoint Portal (FCK или что-то другое), но он позволяет на уровне WordPad текст редактировать с оформлением и форматированием, также там можно рисовать таблицы и вставлять картинки в текст. Все редактируется без ображения к серверу. Обращаться приходится только при сохранении.
Здравствуйте, GlebZ, Вы писали: S>>Пусть вот Дворкин воспроизведет такое приложение на своем любимом неограниченном десктопе, а мы посмотрим, сколько времени и кода это займет. Что-то мне подсказывает, что неудобная и ограниченная среда порвет удобную и неограниченную как тузик грелку. GZ>Во-первых, не 22 кб, а их апи — 138 кб.
Где ты насчитал 138kb?
У меня все ходы записаны.
Или ты про разжатый js? Ну, я не виноват, что win32 PE так плохо поддерживает сжатие.
GZ>Что для одного контрола достаточно много. А если на слаботипизированном JavaScript — то это еще и дорого. GZ>Во-вторых, можно сделать значительно гибче. Генерить bitmap на JS — трудновато. GZ>В-третьих, где контекстное меню?
Здесь — нету. GZ>Ах да. На Web приложениях их делать не принято.
Вообще говоря да. В веб приложениях принято обходиться одним кликом. Хотя контекстное меню могло бы и быть.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, GlebZ, Вы писали: GZ>Особенность та, что ты можешь сделать свое ListView. В достаточно короткие сроки. (вопрос будет ли лучше стандартного — не поднимаю).
"Достаточно короткие сроки" — это, простите, трендеж. Я делал, я знаю. "стандартный listview" поддерживает столько функций, что воспроизводить ты их устанешь.
Классический тест на совместимость: нажмите Shift+Ctrl+gray+. Cделать свой аналог стандартного HTML контрола можно зачастую даже с меньшими затратами, чем в win32.
GZ>Не всегда подобное возможно. На какой-то версии IE мне так и не удалось побороть таким образом. Токмо через get.
Ну вот у гугла почему-то всё работает, а тебе токмо через гет. Будут трудности — приходи, вместе потрассируем
S>> Один из недостатков HTML. Но, как я уже неоднократно намекал, HTML не единственный язык разметки для веб-приложений. S>>К примеру, хорошие аплоадилки народ пишет на Flash. А он сейчас имеет 97% покрытие целевой аудитории. GZ>Для данной целевой аудитории — безусловно. А вот для бизнес — все значительно хуже.
Ничего не понял. Что такое "для бизнес"? Для бизнеса всё просто зашибись. GZ>Да и время ответа увеличивается из-за лишнего оверхеда перегрузки логики приложения на локал. Иногда это бывает важно.
Это тоже непонятно. Вон рядом Дворкин настаивает, чтобы логика приложения срочно переехала к нему на локал. А то у него ДуалАтлон простаивает.
GZ>Именно. У google maps — своя специфика. Это очень дорогое решение, с большим количеством серверов, которые в комплексе очень высокопроизводительные и которое не каждый может себе позволить. И при этом я должен терпеть из-за загрузки их картинок по моему медленному и весьма латентному каналу.
А у тебя нет альтернативы. Покажи мне приложение, которое работает лучше. Сколько DVD займет карта мира с детализацией как у Google? Сколько тебе будет стоить регулярный апдейт базы этого приложения?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
S>>Cовершенно верно. Но старое поколение GUI девелоперов до сих пор считает, что "окружность не устарела".
PD>Старое поколение девелоперов (и не обязательно GUI) считает, что даже с применением WTF, .Net 3.5 и htmllayout уравнение окружности остается без изменений, способ ее рисования — тоже,
Прикольное заблуждение. Ну вот, скажем, нарисуй мне "старым способом" окружность толщиной 1.5 пиксела. PD>а значение числа PI для десктопных приложений не зависит от операционной системы и языка программирования. Для web-приложений я в последнем твердо не уверен.
Смотря что понимать под "значением". Если в смысле "ценность", то для десктопных приложений число пи значения практически не имеет. Зато имеют значения числа (1+sqrt(5))/2 и 7(+/-2).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Судя по твоим другим комментариям, ты так и не понял, чем отличается ссылка на приложение от ссылки внутрь приложения.
Говорить о том что в толстяках внутренних ссылок нет — нельзя. Наиболее используемый пример — путь к файлу.
S>Когда разрабатывался OLE, интерфейс приложения не мыслился иначе как комбинация меню и тулбаров. Самые смелые педеровики производства рисковали высказывать мысль, что меню — это тоже такой тулбар, только без картинок.
Дык в экслорерах вообще никакой интеграции между приложениями нет.
S>Может быть, есть претензии к UI google.com? Нет, это общепризнанно передовой пользовательский интерфейс.
Ты знаешь — есть. Только не к google.com — а gmail. Из сегодняшнего. Нужно было посмотреть все сообщения от одного пользователя. В Outlook я могу отсортировать. Могу сгруппировать. Здесь же приходится шариками работать. Только через поиск (с возможностью ошибки в имени) поскольку после поиска в адресной книге оказалось такого пользователя нет. Они потратили мое время.
S>У меня все ходы записаны. S>Или ты про разжатый js? Ну, я не виноват, что win32 PE так плохо поддерживает сжатие.
Ты посмотри timeline-api.js. здесь. Он состоит из одной процедуры — выкачка скриптов. Притом поддержка локализированных скриптов. Ребята молодцы. Правда пока еще сам не понял, насколько это правильно и устойчиво.
GZ>>Ах да. На Web приложениях их делать не принято. S>Вообще говоря да. В веб приложениях принято обходиться одним кликом. Хотя контекстное меню могло бы и быть.
Вот что 100% должно быть. Даже не должно а обязано быть. Это множественный выбор файлов.
Здравствуйте, GlebZ, Вы писали:
GZ>Ты посмотри timeline-api.js. здесь.
Мне не надо ничего смотреть. Я захожу реальным браузером на реальный сайт с контролом, и смотрю реальный трафик.
Это, хочу отметить, только startup cost. В том смысле, что все последующие обращения к UI обходятся бесплатно. Загружаются только данные — в лучшем виде, то что Дворкин прописал. S>>Вообще говоря да. В веб приложениях принято обходиться одним кликом. Хотя контекстное меню могло бы и быть. GZ>Вот что 100% должно быть. Даже не должно а обязано быть. Это множественный выбор файлов.
Это, вообще говоря, указано в спецификации HTML 3.2.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Sinclair, Вы писали:
S>>Судя по твоим другим комментариям, ты так и не понял, чем отличается ссылка на приложение от ссылки внутрь приложения. GZ>Говорить о том что в толстяках внутренних ссылок нет — нельзя. Наиболее используемый пример — путь к файлу.
И? Это ссылка в FS. file://...
Вот Дворкин считает, что в destop apps ссылка — это command line.
Может, вы подеретесь? Это я к тому, что согласья нет. А вот в веб приложениях никакого misunderstanding не предусмотрено — понятие ссылки является базовым, и ссылки формируют единое пространство. GZ>Дык в экслорерах вообще никакой интеграции между приложениями нет.
Ну, насчет вообще никакой — это ты преувеличиваешь. Хотя таки да, сlipboard в винде оставляет существующие веб-приложения далеко позади.
S>>Может быть, есть претензии к UI google.com? Нет, это общепризнанно передовой пользовательский интерфейс. GZ>Ты знаешь — есть. Только не к google.com — а gmail. Из сегодняшнего. Нужно было посмотреть все сообщения от одного пользователя. В Outlook я могу отсортировать. Могу сгруппировать. Здесь же приходится шариками работать. Только через поиск (с возможностью ошибки в имени) поскольку после поиска в адресной книге оказалось такого пользователя нет. Они потратили мое время. я пока мало пользовался гмэйлом. Ситуации, чтобы я не нашел письма, еще не было.
ты как искал? через "from:(фрагментимени)"?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
A>>Таблицу с пэйджером ты как будешь делать? Сервисный метод, выдающий данные и запрос из javascript с последующим заполнением таблицы? По моему — самое удачное решение. S>100%.
Не всегда. Иногда пользователю нужна адресуемость именно второй страницы. Собственно, то о чем ты говорил до этого. Простейший способ реализации — все таки get.
Здравствуйте, Sinclair, Вы писали:
S>И? Это ссылка в FS. file://... S>Вот Дворкин считает, что в destop apps ссылка — это command line. S>Может, вы подеретесь? Это я к тому, что согласья нет. А вот в веб приложениях никакого misunderstanding не предусмотрено — понятие ссылки является базовым, и ссылки формируют единое пространство.
Поэтому и написал — наиболее используемое. Что касается ваабще ссылок, то тут возражений нет и не может быть. Я, например, буду делать ссылки с интеграцией в проводник для толстого приложения как только с более приоритетными задачами разберусь. Но даже в этом случае эксплорер впереди.
S> я пока мало пользовался гмэйлом. Ситуации, чтобы я не нашел письма, еще не было. S>ты как искал? через "from:(фрагментимени)"?
Нет. Просто копированием имени из письма. Такие сложные решения как префиксы — есть признак неуважения к пользователю.
Здравствуйте, Sinclair, Вы писали:
GZ>>Ты посмотри timeline-api.js. здесь. S>Мне не надо ничего смотреть. Я захожу реальным браузером на реальный сайт с контролом, и смотрю реальный трафик. S>Это, хочу отметить, только startup cost. В том смысле, что все последующие обращения к UI обходятся бесплатно. Загружаются только данные — в лучшем виде, то что Дворкин прописал.
Тут есть несколько Ы. Что ты подразумеваешь под Startup cost? Время когда показался текст или время когда контрол стал работоспособным? И что есть там картинки. Их можно квалифицировать как логику а не данные.
S>Это, вообще говоря, указано в спецификации HTML 3.2.
Была бы еще поддержка производителей. А то Microsoft, несмотря на всю пропаганду и утверждение что нынче все DHTML и ActiveX в топку, в Sharepoint все равно юзает ActiveX для поддержки редактирования файлов и множественного выбора. Двуличные, блин.
Здравствуйте, GlebZ, Вы писали: GZ>Нет. Просто копированием имени из письма. Такие сложные решения как префиксы — есть признак неуважения к пользователю. Работает, конечно же, и так. просто from: более restrictive.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Sinclair, Вы писали:
GZ>>>Ты посмотри timeline-api.js. здесь. S>>Мне не надо ничего смотреть. Я захожу реальным браузером на реальный сайт с контролом, и смотрю реальный трафик. S>>Это, хочу отметить, только startup cost. В том смысле, что все последующие обращения к UI обходятся бесплатно. Загружаются только данные — в лучшем виде, то что Дворкин прописал. GZ>Тут есть несколько Ы. Что ты подразумеваешь под Startup cost? Время когда показался текст или время когда контрол стал работоспособным?
Стоимость инициализации приложения в первый раз. Практически полностью определяется размером загружаемых данных (время в грубом приближении можно получить поделив этот размер на толщину клиентского канала)
Return cost — стоимость повторного показа приложения. GZ>И что есть там картинки. Их можно квалифицировать как логику а не данные.
Ок, давай квалифицировать как логику. В очередной раз чистим кэш и ставим смелый эксперимент: чистим кэш, запускаем фиддлер. Поехали:
На этот раз, приложение стоило мне меньше восьми килобайт и чуть больше четырех секунд.
Это не вполне честно, т.к. живые данные не были перезапрошены (обычно как раз они и будут обновляться), но по убийству Кеннеди никаких новостей пока не поступило. S>>Это, вообще говоря, указано в спецификации HTML 3.2. GZ>Была бы еще поддержка производителей. А то Microsoft, несмотря на всю пропаганду и утверждение что нынче все DHTML и ActiveX в топку, в Sharepoint все равно юзает ActiveX для поддержки редактирования файлов и множественного выбора.
Правильно, использовать нужно Flash Или сильверлайт GZ>Двуличные, блин. Они просто очень длинные. Голова уже в двадцать первом веке, а хвост — в восьмидесятых годах. Ты вспомни, в каком году в трей разрешили иконки с более чем 16 цветами размещать
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
GZ>>И что есть там картинки. Их можно квалифицировать как логику а не данные. S>Ок, давай квалифицировать как логику. В очередной раз чистим кэш и ставим смелый эксперимент: чистим кэш, запускаем фиддлер. Поехали: S>
skipped...
S>
S>Это не вполне честно, т.к. живые данные не были перезапрошены (обычно как раз они и будут обновляться), но по убийству Кеннеди никаких новостей пока не поступило.
Таки да. Все вполне верно. Неверно прочитал исходники.
И еще, там посылается bundle.js который гзипованный весит 22 кил. А вот расгзипованный — Content-Length: 111643. К вопросу об исходном сообщении о сложности. Сколько стоит написать и отладить 110 кил кода на JavaScript, и сколько будет весить то же самое но написанное на С# или C++ с использованием GUI? Было бы время, показал бы что меньше по размеру.
GZ>>Двуличные, блин. S> Они просто очень длинные. Голова уже в двадцать первом веке, а хвост — в восьмидесятых годах. Ты вспомни, в каком году в трей разрешили иконки с более чем 16 цветами размещать
ЗЫ. Там у них есть очень показательный комментарий:
/*
HACK: We need these 2 things here because we cannot simply append
a <script> element containing code that accesses Timeline.Platform
to initialize it because IE executes that <script> code first
before it loads timeline.js and util/platform.js.
*/
Здравствуйте, Sinclair, Вы писали:
S>Нижний уровень в ASP.NET продуман просто великолепно. Изменения в 2.0 были достаточно незначительными. S>Средний и верхний слой были просто отвратительны в 1.0 и 1.1. S>В 2.0 добавили несколько полезных вещей, в частности механику Providers и Themes. Но решение осталось половинчатым, т.к. часть контролов по прежнему требовала Postback для своей работы. То есть средний уровень был улучшен, а вот верхний остался в целом малопригодным.
S>Низким уровнем я считаю механику IHttpHandler/IHttpModule, HttpRequest, HttpResponse, HttpContext, System.Web.Cache и прочие штуки, которые мало меняются из версии в версию и позволяют строить совершенно произвольные веб-приложения.
Т.е. на сегодня разработка нормальных веб-приложений с использованием asp.net подразумевает использование в основном только этого нижнего уровня, так?
Для практики интерес представляет клиентская составляющая этого уровня — т.е. javascript функции и объекты, которые используются в странице для обеспечения всей этой функциональности. Вопрос: этот клиентский javascript официально задокументирован или же является деталью реализации и его использование можно считать хаком? Если задокументирован, то накидай, плиз, сылок — дико интересно
Здравствуйте, Sinclair, Вы писали:
S>Нижний уровень в ASP.NET продуман просто великолепно.
Если быть честным, то большая часть просто содрана с Servlets/JSP с некоторыми изменениями, далеко не все из которых удачны. Например, ИМХО, неудачный IHttpModule.
... << RSDN@Home 1.2.0 alpha 4 rev. 1036 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
PD>>, способ ее рисования — тоже AVK>Это вряд ли. В конце концов рисование примитивов полностью переедет в GPU.
Кое-где уже начало. Новый FireFox использует в качестве бэкэнда Cairo, который постепенно учится напрямую ускоряться адаптером.
Здравствуйте, Cyberax, Вы писали:
AVK>>Это вряд ли. В конце концов рисование примитивов полностью переедет в GPU. C>Кое-где уже начало.
Я в курсе.
C> Новый FireFox
Тут WPF уже упоминали. И там (точнее в Windows SDK) есть прикольная утилитка, которая подкрашивает розовым ту графику, которая вычисляется софтово. Но это все не совсем то, о чем Дворкин говорил, геометрию пока шейдерами вроде как нигде не рисуют.
C> использует в качестве бэкэнда Cairo, который постепенно учится напрямую ускоряться адаптером.
GTK+ тоже использует Cairo, но вобще то никакого ускорения адаптером он не содержит, просто он сам по себе работает не напрямую, а через собственный бекэнд. И один из них, который называется glitz, как раз таки да, умеет работать через OGL.
У WPF архитектура аналогичная — у него своя библиотека графики, аналогичная Cairo, которая при рождении называлась Aero (позже название перешло на красивости Висты, но, в отличие от PDC 2003, теперь эти красивости реализуются совсем другим кодом), а сейчас вроде бы отдельного названия не имеет, просто System.Windows.Drawing. И у нее точно так же есть собственный бекенд. Беты работали через GDI бекенд. Нынешний бекенд, MIL, работает через DirectX.
... << RSDN@Home 1.2.0 alpha 4 rev. 1036 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
C>>Кое-где уже начало. AVK>Я в курсе.
Да, я просто дополняю.
C>> Новый FireFox AVK>Тут WPF уже упоминали. И там (точнее в Windows SDK) есть прикольная утилитка, которая подкрашивает розовым ту графику, которая вычисляется софтово. Но это все не совсем то, о чем Дворкин говорил, геометрию пока шейдерами вроде как нигде не рисуют.
Кое-кто уже пытается. В QT4 добавляют поддержку тесселяции на GPU с помощью шейдеров и других вкусные вещи: http://zrusin.blogspot.com/2006/10/benchmarks.html http://www.mdk.org.pl/2007/8/6/vector-drawing-opengl-shaders-and-cairo
C>> использует в качестве бэкэнда Cairo, который постепенно учится напрямую ускоряться адаптером. AVK>GTK+ тоже использует Cairo, но вобще то никакого ускорения адаптером он не содержит, просто он сам по себе работает не напрямую, а через собственный бекэнд. И один из них, который называется glitz, как раз таки да, умеет работать через OGL.
Угу.
AVK>У WPF архитектура аналогичная — у него своя библиотека графики, аналогичная Cairo, которая при рождении называлась Aero (позже название перешло на красивости Висты, но, в отличие от PDC 2003, теперь эти красивости реализуются совсем другим кодом), а сейчас вроде бы отдельного названия не имеет, просто System.Windows.Drawing. И у нее точно так же есть собственный бекенд. Беты работали через GDI бекенд. Нынешний бекенд, MIL, работает через DirectX.
Мне интересно, а какие фичи видеокарты они уже используют кроме банального блиттера?
Здравствуйте, Cyberax, Вы писали:
C>Мне интересно, а какие фичи видеокарты они уже используют кроме банального блиттера?
Не особо они распространяются на эту тему. К лету обещали shadows и blur акселерировать. Сейчас вроде используется масштабирование для плавности. Т.е. в процессе масштабирования масштабируется средствами карты, как бросаешь кнопку, все уже перерисовывается по честному. Ну и конечно отсечение, градиент, альфа-блендинг, кое какая несложная анимация. Ну и 3D конечно, если оно используется. Можно еще покурить над требованиями к tier 2.
... << RSDN@Home 1.2.0 alpha 4 rev. 1036 on Windows Vista 6.0.6001.65536>>
Здравствуйте, artelk, Вы писали:
A>Т.е. на сегодня разработка нормальных веб-приложений с использованием asp.net подразумевает использование в основном только этого нижнего уровня, так?
Ну почему же. Есть альтернативные фреймворки, построенные поверх этого уровня. MVC Framework из ASP.NET 3.5 прямо-таки по-взрослому крут.
A>Для практики интерес представляет клиентская составляющая этого уровня — т.е. javascript функции и объекты, которые используются в странице для обеспечения всей этой функциональности.
У нижнего уровня никакой клиентской составляющей нет.
Вопрос: этот клиентский javascript официально задокументирован или же является деталью реализации и его использование можно считать хаком? Если задокументирован, то накидай, плиз, сылок — дико интересно
Если речь о джаваскрипте, который поддерживает Postback/Callback, то AFAIK он недокументирован.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, artelk, Вы писали:
A>>Т.е. на сегодня разработка нормальных веб-приложений с использованием asp.net подразумевает использование в основном только этого нижнего уровня, так? S>Ну почему же. Есть альтернативные фреймворки, построенные поверх этого уровня. MVC Framework из ASP.NET 3.5 прямо-таки по-взрослому крут.
Только ему катастрофически не хватает валидаторов как в WebForms и поддержки MS AJAX (сразу на это напоролся при поытке использовать в проекте). Хотя может быть к релизу и то и другое прикрутят.
S>Вопрос: этот клиентский javascript официально задокументирован или же является деталью реализации и его использование можно считать хаком? Если задокументирован, то накидай, плиз, сылок — дико интересно S>Если речь о джаваскрипте, который поддерживает Postback/Callback, то AFAIK он недокументирован.
Очеь даже задокументирован, см справку по ClientScriptManager. Во внутренности Postback/Callback лезть не стоит.
Клиентская библиотка MS AJAX и Ajax Control Toolkit отлично задокументирована.
GlebZ wrote:
> Нет. Просто копированием имени из письма. Такие сложные решения как > префиксы — есть признак неуважения к пользователю.
Зато удобно при частом использовании. Кстати, там есть ещё ссылочка "Show search options".
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, Sinclair, Вы писали:
PD>>>А впрочем, бог с ним, с комбобоксом. Поставлю вопрос иначе — должен ли сервер знать вообще что-нибудь на предмет того, как выглядит интерфейс пользователя ? Вообще в серверном коде должно быть хоть какое-нибудь упоминание об элементах пользовательского интерфейса ? S>>Смотря в какой модели. В модели веб приложений — да. Сервер таки должен знать, как выглядит интерфейс пользователя.
A>Нет. Задача сервера: принять данные от клиента, проверить и обработать их согласно неким правилам, отдать новые данные клиенту. Задача клиента: запросить данные у сервера, принять и отобразить их, принять данные от пользователя и отправить их серверу. Всё, что они знают друг о друге — это протокол обмена данными, и ещё клиент знает URL точки доступа на сервере. Но тут есть важный момент: клиентское приложение, как целиком, так и по частям, предоставляет пользователю сам сервер, причём не обязательно тот же самый, что и обрабатывает данные.
К сожалению, в большинстве случаев web-приложений сервер как раз имеет представление об интефрейсе пользователя.
Даже если опустить случай, когда сервер напрямую пишет ui в responce, примеров много. Рассмотрим распространенный случай — AJAX-приложение, клиент, использующий веб-фреймворк. Клиентская библиотека поддерживает данные в формате json, т е существуют элементы управления, которые загружают свое содержимое из определенного url. Т. е. как ни крути, сервер будет как минимум знать, что ЭТОТ набор данных предназначен для такой-то таблицы. Кстати, мне нравится, что в EXT, например, есть data store, содержимое которого можно отображать в разных контролах, основываясь на различных XTemplate. Это — как раз шаг к тому, чтобы прервать эту порочную практику. Другой такой шаг — написать собственную десериализацию из json на jscript из некоторого представления.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Здравствуйте, Sinclair, Вы писали:
S>>>>Это заблуждение. К примеру, в таком совершенно не веб приложении, как MS Money, back button работает просто на ура. PD>>>Всегда можно найти пример, который не подходит под общий случай. Иногда, может быть, да, он нужен и полезен. S>>Всё как раз наоборот — навигационная модель прекрасно подходит для очень широкого класса случаев. Не уверен насчет 100% покрытия, но навскидку я не могу придумать приложения, которое бы не попало в навигационную модель (кроме тех игр, в которых usability принудительно запрещена).
CS>Есть Inductive UI и есть Productive UI. CS>Некоторые применения Inductive UI допускают наличие линейного стека back/fore. Некоторые — нет. CS>Productive UI весь как правило не укладывается в линейную схему back-fore. CS>Inductive UI как правило характеризуется отказом от использования меню — flow линейный. CS>В Productive UI каждое состояние имеет как правило множество точек входа (меню например) и выхода. CS>Productive UI возможно несколько параллельных flows — например редактирование двух документов в двух child окнах.
Inductive UI — это когда, к примеру, приложение строится на основе мастеров? Т. е. ведущим отличием inductive от productive — это наличие состояния у productive ui? К примеру, нужно примонтировать образ диска и что-то с ним сделать. Тогда в inductive это будет сделано: нажали на одну кнопку, появился диалог, ввели путь к диску, нажали далее, диск примонтировался, выбрали действие над дисков, совершили. А в productive: нажали на кнопку, примонтировали диск. Потом нажали на другую и выбрали действие. При этом при нажатии на вторую кнопку нужно проверить, примонтирован ли диск. Я правильно понял суть?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
PD>1. Выделение области курсором мыши (об этом я уже говорил)
А какие десктоп-приложения это позволяют делать?
PD>2. Best fit in window. Выделяем курсором мыши, нажимаем кнопку, и выделенная область оккупирует все текущее окно наилучшим образом, т.е с автоматическим выбором зума
Какие десктоп-приложения это умеют делать? maps.google.com это умеет
PD>3. Сохранение locations. Вот, к примеру, собираешься ты в Омск. И я хочу тебе сообщить о ряде мест, которые стоит посетить. Пощелкал я в разных местах, сделал подписи (которые никого, кроме нас с тобой, не касаются), сохранил все это в файл, и этот файл тебе переслал. Ты его открыл , и в окне крестиками помечены разные места, с подписями.
Похожая функциональность давно в google docs, например, есть
PD>4. Координатную сетку нанесите! И так, чтобы убрать можно было.
Зачем? Учитывая, что это просто картинки, это не сложно
PD>5. Расстояния. Ткнул мышкой в одно место, ткнул в другое и показали, сколько между ними метров или километров.
maps.google.com
S>>>>Меню на JS реализуются гораздо более продвинутые, чем на Windows API. Я custom draw в свое время очень близко изучал, так что знаю что к чему. PD>>>Ай-яй-яй! Ты про owner draw меню когда-нибудь слышал ? S>>Конечно слышал. Это предыдущая технология, на смену которой и пришло custom draw для toolbar controls. Павел, просто поверь на слово — я все эти штуки на брюхе прополз от и до.
PD>
S>>Ну вот ява и есть это решение. "недавно студент показывал"... Этой технологии больше 10 лет. Увы, не сыграла. S>>Даже джава приложения, загружаемые из браузера, не сыграли. Потому, что не отвечает эта "прямая архитектура" реальным потребностям. А вот веб-приложения, сделанные на смешном джаваскрипте и без тулбаров в браузере, прямо-таки жгут напалмом.
PD>
S>>Кстати, Print Screen — наиболее нормальный вариант. И наиболее близкий к аналогу от десктопного приложения.
PD>Ну и ну! Посоветуй это авторам Photoshop, AutoCad и т.д.
PD>>>Конечно, если приложение этого не позволяет, ты этого не сделаешь. И если в нем нет никаких картинок, а есть только форма с кнопками и т.д, то, конечно, этого там нет. S>>Ну так о чем речь? Нет таких приложений в природе.
PD>Чего нет в природе ? Приложений, которые позволяют картинки просматривать, мышкой куски выделять и Ctrl-Ins делать ?
PD>Держи
PD>http://www.irfanview.com/
PD>>>Но если в программе есть картинки, и есть смысл выделять и сохранять куски изображения, то выделение резиновым контуром и сохранение в клипбоард делается за полчаса. Я это упражнение даю студентам на 2 месяце курса по Win32. Приезжай в Омск, я тебя к ним отведу, они тебе расскажут , как это делается и покажут все. S>>Гы-гы. Ну ладно, я пожалуй подожду от тебя релиза Earth.exe с этой функциональностью. За полчаса для резинового контура, плюс, сталобыть, три недели на "показ картинок". Ок. Жду. Вернемся к вопросу в конце мая.
PD>Да бога ради. Открой финансирование, обсудим, сделаю Ну и , конечно, с тебя документация по протоколу получения этих картинок. Я их из пальца не высосу, своего спутника у меня нет.
S>>Выделение резиновым контуром и сохранение картинки в веб приложении делается не намного сложнее, чем в win32.
PD>Вот и сделайте.
PD>>>При том, что весь этот www.wikimapia.org есть попросту viewer битовых карт с зумом и скроллингом. S>>На таком уровне любое десктопное приложение суть всего лишь стейтмашина для обработки потока Windows сообщений.
PD>Я тебя более страшную вещь скажу. Любое приложение (хоть web, хоть не web) — есть просто набор команд, выполняемых CPU.
>>И что? Вопрос-то в том, каких карт.
PD>Именно. Все хорошее в этой wikimapia — это предметная область. Потому что таких карт ни у кого больше нет. В этом и состоит действительная ценность. А в остальном — карты как карты, картинки то есть, и вьюер как вьюер, примитивный довольно-таки.
>>Кстати, там не только зум и скроллинг. А еще и показ user-defined объектов.
PD>Ай-яй-яй! Нарисовать некоторое количество прямоугольников белым цветом с прозрачным фоном и текстом поверх картинок — это, конечно, выдающееся достижение для web-приложения, но, скажу тебе по секрету, WHITE_BRUSH, NULL_PEN и TextOut были еще в Windows 3.0, а может, и в Windows 1.0.
PD>>>OK. Тогда у меня просьбочка небольшая. Нельзя ли на базе веб-приложений приличный на уровне пусть не Word, но хоть WordPad текстовый редактор сюда встроить вместо того, в котором я это пишу. Когда тут нормальный WYSIWYG будет, с цветами и шрифтами? S>>Когда у нас появится время его прикрутить. Никакой принципиальной проблемы в этом нету. См. напр. Outlook Web Access.
PD>Ну что же, раз нет принципиальной проблемы — будем ждать от web-программистов, когда они нам продемонстрируют web-продукты, сравнимые по возможностям с соответсвующими десктопными приложениями. С Photoshop и AutoCad, Media Player и WinAmp, Word и Excel, Power Point и Corel Draw. Так, чтобы можно было из файлов в эти приложения сохраненные объекты загружать, править, сохранять, из одного в другое приложение передавать через Clipboard или Drag & Drop. Чтобы мог я в web-Excel табличку соорудить, там же ее просчитать, лкгким движением руки в web-Word вставить, и чтобы она там в WYSIWIG была. Чтобы мог я в этом самом броузерном окне всякие разные ppt, wmv, mpg, avi, xls, doc просматривать без того, чтобы презренное десктопное приложение запускать.
PD>И чтобы в этих продуктах ActiveX не использовались! Потому что используя ActiveX, вы теряете свое единственное преимущество — платформонезависимость. Более того, с ActiveX у вас даже хуже получится — десктопные приложения хоть под любой версией Windows работают, а ActiveX — только в IE. Так что будьте добры все это на своем JavaScript и делать. Потому что ничего другого на стороне клиента у вас и нет...
PD>Вот когда сделаете — тогда я публично признаю свою неправоту. А до тех пор мне беспокоиться не о чем.
PD>А в заключение — пара вопросов.
PD>Не подскажешь ли, как мне определить версию web-приложения ? Для десктопных — все ясно, само сообщит. Вот сделал я продукт, версия 1.0, выпустил его в мир. Если хоть один байт я в нем поменяю, я его выпущу под номером 1.1 или 1.01. И если пользоователю мое изменение в 1.01 не понравится, он может вернуться обратно к 1.0 . PD>А как быть с web-приложением ? Оно, пока я спал, никак не изменилось ? А если да — почему мне не сообщили ? Мне, может, совсем не все равно. А если мне не понравилось — как к прежней версии вернуться ?
PD>И последний вопрос. Настольное приложение, после того, как я его скачал — навсегда у меня. Даже если автор его давно им не занимается или вообще помер. А что мне делать, если мое любимое web-приложение вдруг исчезнет из сети ? Кому жаловаться ?
Здравствуйте, Left2, Вы писали:
L>Ты опять недостатки конкретной реализации выдаёшь за недостатки архитектуры в целом. Посмотри на gmail — там максимум сможешь потерять изменения за последние пару минут. Или на другие google docs — приложение автоматически сохраняет изменения (не на жёсткий диск, а на сервер — но обычному-то юзеру какая разница?) каждые N минут или M секунд.
Ничего себе какая разница! А если у меня связь с сервером потеряется — мне сидеть и ждать, когда она восстановится ? Вот как раз когда я писал прошлое письмо — на RSDN что-то и случилось.
И кстати, о gmail. Спасибо, но я все же предпочитаю письма писать из своей Mozilla. По крайней мере я уверен, что оно останется в Draft, пока я его не пошлю, и никуда не пропадет, если я его вообще не пошлю — пока не скажу Discard. И не уйдет оно, только если проблемы с локальным SMTP сервером, что на этаж ниже у нас стоит. А тут — черт знает.
И все же — почему нельзя на локальный диск сохранить ? Или хоть вставить из файла ? Можно сделать это ? Пусть разрешение этой возможности под опциями стоит, но чтобы все же была она.
Здравствуйте, Left2, Вы писали:
L>Ты опять недостатки конкретной реализации выдаёшь за недостатки архитектуры в целом. Посмотри на gmail — там максимум сможешь потерять изменения за последние пару минут. Или на другие google docs — приложение автоматически сохраняет изменения (не на жёсткий диск, а на сервер — но обычному-то юзеру какая разница?) каждые N минут или M секунд.
Кстати, в таком сохранении на сервере промежуточного варианта есть одна маленькая неэтичность. Совсем маленькая, но все же есть. Я готов доверить gmail мое готовое письмо, иначе зачем бы я их услугами пользовался ? Но из этого не следует, что я готов доверить ему свой черновик в процессе работы над ним.
PD>Ничего себе какая разница! А если у меня связь с сервером потеряется — мне сидеть и ждать, когда она восстановится ? Вот как раз когда я писал прошлое письмо — на RSDN что-то и случилось.
А если связь с сервером потеряется — нормальный клиент (GMail) по крайней мере сразу об этом сообщит + текст всё равно никуда не денется.
PD>И кстати, о gmail. Спасибо, но я все же предпочитаю письма писать из своей Mozilla. По крайней мере я уверен, что оно останется в Draft, пока я его не пошлю, и никуда не пропадет, если я его вообще не пошлю — пока не скажу Discard. И не уйдет оно, только если проблемы с локальным SMTP сервером, что на этаж ниже у нас стоит. А тут — черт знает.
А я всё же больше доверяю гугловскому серверу чем любому локальному. За 4 года пока работаю с Gmail меня попросили подождать пару минут (и это реально было пару минут) ровно один раз.
PD>И все же — почему нельзя на локальный диск сохранить ? Или хоть вставить из файла ? Можно сделать это ? Пусть разрешение этой возможности под опциями стоит, но чтобы все же была она.
Ещё раз — Google Gears решает эти проблемы, добавляя локальную (client-side) БД, доступную из javascript.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
PD>>>1. Выделение области курсором мыши (об этом я уже говорил)
M>>А какие десктоп-приложения это позволяют делать?
PD>1. Irfan View, о котором я уже писал PD>2. Практически все графические редакторы PD>3. В отношении других приложений — могу лишь Ильфа и Петрова процитировать
PD>-- Я сам в желтых ботинках. В Москве еще двести тысяч PD>человек в желтых ботинках ходят. Может быть, вам PD>нужно узнать их адреса? Тогда пожалуйста. Я брошу всякую PD>работу и займусь этим делом. Через полгода вы будете PD>знать все адреса. Я занят, гражданка.
PD>4. Упражнения, которые выполняют мои третьекурсники.
Почему возможности одного-двух десктоп-приложений выдаются как непременный атрибут веб-приложений вообще?
PD>>>3. Сохранение locations. Вот, к примеру, собираешься ты в Омск. И я хочу тебе сообщить о ряде мест, которые стоит посетить. Пощелкал я в разных местах, сделал подписи (которые никого, кроме нас с тобой, не касаются), сохранил все это в файл, и этот файл тебе переслал. Ты его открыл , и в окне крестиками помечены разные места, с подписями.
M>>Похожая функциональность давно в google docs, например, есть
PD>А на wikipedia нет. Но обрати внимание, ты это преподносишь как достижение, в то время как для десктопных приложений это мелочь, так, мимоходом сделать
Мелочь? Мимоходом? Не помню ни одного такого приложения
PD>>>4. Координатную сетку нанесите! И так, чтобы убрать можно было. M>>Зачем? Учитывая, что это просто картинки, это не сложно
PD>Несложно, но сделайте. А то я не всегда понимаю, где я нахожусь.
Это вопрос к wikimapia
PD>>>5. Расстояния. Ткнул мышкой в одно место, ткнул в другое и показали, сколько между ними метров или километров.
M>>maps.google.com
PD>Тоже хорошо.
PD>Кстати, объясни мне один вопрос. Почему нельзя из web-приложения читать/записывать файлы на локальный компьютер ?
Зачем?
PD>Или можно все же ? Вот это сообщение я набираю второй раз. Уже набрал, послал — ошибка сервера. Back — не сработал. И потерял я свой текст, теперь опять набираю. Я понимаю, что запись из JavaScript — это опасно, но, в конце концов, запускать .EXE из Интернета тоже опасно, но ведь запускаю же я скачанные с www.microsoft.com EXE, да еще такие, которые мне часть ОС изменяют. Почему же это можно, а вот из скрипта с того же www.microsoft.com — нельзя ? Или из редактора, в котором я сейчас пишу — почему нельзя текст перед посылкой в файл сохранить ?
Вопрос к команде РСДН, чтобы она сделала автосохранение черновиков, как, например, в ГМыле
PD>Кстати, в таком сохранении на сервере промежуточного варианта есть одна маленькая неэтичность. Совсем маленькая, но все же есть. Я готов доверить gmail мое готовое письмо, иначе зачем бы я их услугами пользовался ? Но из этого не следует, что я готов доверить ему свой черновик в процессе работы над ним.
Хорошо — найди другой сервис, которому ты доверяешь (вариант — напиши сам) и набирай письмо в нём, а потом делай copy/paste в гугл. Хотя в целом больше на паранойю похоже — так недалеко и до недоверия производителям клавиатур (а ну как они там понавтыкали чего), мышей и соединительных кабелей для всей перифирии.
Здравствуйте, Left2, Вы писали:
L>Хорошо — найди другой сервис, которому ты доверяешь (вариант — напиши сам) и набирай письмо в нём, а потом делай copy/paste в гугл.
Опять Copy/Paste ?
>Хотя в целом больше на паранойю похоже — так недалеко и до недоверия производителям клавиатур (а ну как они там понавтыкали чего), мышей и соединительных кабелей для всей перифирии.
Да, конечно. Я и не настаиваю, но все же — всякое бывает.
Здравствуйте, Mamut, Вы писали:
M>Почему возможности одного-двух десктоп-приложений выдаются как непременный атрибут веб-приложений вообще?
Что-то я не понял. При чем тут web-приложения вообще. И в чем тут проблема, если эта задача по сложности сравнима с упражнениями третьекурсников ?
PD>>А на wikipedia нет. Но обрати внимание, ты это преподносишь как достижение, в то время как для десктопных приложений это мелочь, так, мимоходом сделать
M>Мелочь? Мимоходом? Не помню ни одного такого приложения
Я сам такое писал
PD>>Кстати, объясни мне один вопрос. Почему нельзя из web-приложения читать/записывать файлы на локальный компьютер ?
M>Зачем?
Ну знаешь ли... Затем же, зачем это есть в десктопных приложениях. Вот если web-приложения будут на сервере и выполняться (Web Terminal Server — тогда не надо. А пока они все же работают на клиенте, я хочу иметь возможность на только сохранить картинку средствами броузера или всю страницу его же средствами, но и вставить из файла в редвктор, сохранить и т.д. Что тут ненормального ?
PD>Опять Copy/Paste ?
Погоди, а в desktop-приложениях ты copy-paste не используешь? Или у тебя есть мегаприложение которое умеет настолько всё, что обмениваться информацией с другими приложениями ему не нужно?
PD>Да, конечно. Я и не настаиваю, но все же — всякое бывает.
Ну, для паранойиков — можно всё сделать самому, с нуля. Правда, начинать прийдётся с добычи кремниевого песка и железной руды, затем — изготовление примитивных инструментов — а потом потихоньку и до транзисторов, собственных микросхем, собственной ОС, собственного пакета прикладного ПО. Да, не забыть хорошо питаться и следить за здоровьем, а то можно и не уложиться в срок человеческой жизни
Здравствуйте, Left2, Вы писали:
PD>>Опять Copy/Paste ? L>Погоди, а в desktop-приложениях ты copy-paste не используешь? Или у тебя есть мегаприложение которое умеет настолько всё, что обмениваться информацией с другими приложениями ему не нужно?
Слушай, не надо тень на плетень наводить. Иногда использую, иногда нет, но там практически всегда можно в файл сохранить и оттуда взять.
Здравствуйте, AndrewVK, Вы писали:
AVK>А если ты находишься в Мухосратостане в интернет кафе под зазванием UltraSicure Intirnet, ты кому больше будешь доверять — локальному почтовому клиенту или gmail?
Я вообще-то в такие места не хожу, и это не аргумент. Не буду я оттуда письма слать ни в каком случае. Потому что не уврен, что броузер не сохранит мне копию в кэше — как, к примеру с предпросмтром на RSDN.
А что касается этого кафе -не доверяют сотрудники этого кафе пользователям — пусть поставят в опциях настройку "не сохранять файлы на лок. диск". Аналогично настройке ActiveX.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>1. Irfan View, о котором я уже писал
AVK>Irfan View, кстати, обладает на редкость неудачным UI.
Слушайте, господа web-программисты, что у вас за манера уходить в сторону ? Я привел Irfan View как пример программы , где можно выделить — контраргумент : у него, видите ли , неудачный UI. Я хоть слово в пользу его UI вообще приводил или выставлял его в качестве образца вьюеров ? У меня просили пример — я привел.
Я спрашиваю, почему нельзя было позволить из файла читать/писать, меня спрашивают (не ты) — зачем ? Лекцию я, что ли устроить должен с объяснениями, зачем в файлы пишут ?
AVK>В обратную сторону это тоже работает. Например, способность Web UI очень хорошо приспосабливаться под разные шрифты и размеры текста — для большинства десктопных приложений до сих пор недоступное достижение.
Да, эта проблема есть. Тут согласен. Но это лишь потому, что за вас эту работу выполнил броузер, а за нас — некому, сами должны. Я могу написать программу, которая будет хорошо приспосабливаться под разные шрифты и размеры текста — но чего мне это будет стоить ?
>Или например такая тривиальнейшая вещь, как скопировать текст сообщения в буфер. У каждого вида приложений своя специфика ти недостатки, которые зачастую являются продолжением их достоинств.
Чего-то я не понял. В десктопных приложениях либо есть такое выделение и Copy/Paste, либо нет. Не для всех оно имеет смысл. Но если есть — способ один — Ctrl-A, Ctrl-Ins. Или через меню.
>Например, способность веб-приложений работать везде оборачивается недоступностью специфичных локальных ресурсов. Надо просто уметь выбирать ту технологию, которая максимально подходит потребностям заказчика здесь и сейчас, а не вычислять которая из них сакс, а которая рулез.
Первая здравая мысль, которую я слышу. Я же не против web-приложений вообще. Я же не предлагаю сайты в MFC приложении вместо броузера просматривать (хоть и можно это). Просто когда это web-приложение начинают (не ты) представлять, как последнее слово техники, да еще на 100 лет опередившее десктопные (пусть и на Delphi) — слушать смешно и уши вянут. А вот если спокойно к этому подойти и отдать кесарю кесарево, а богу богово — тогда можно и пообсуждать предметно.
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Irfan View, кстати, обладает на редкость неудачным UI.
PD>Слушайте, господа web-программисты
Я не веб-программист. А попытка классифицировать собеседника, и на основании этого сделать выводы есть ни что иное, как демагогия.
PD>Я привел Irfan View как пример программы , где можно выделить
Фиговый пример.
PD> — контраргумент : у него, видите ли , неудачный UI. Я хоть слово в пользу его UI вообще приводил
А о чем ты тогда?
PD> или выставлял его в качестве образца вьюеров ? У меня просили пример — я привел.
Изначально ты привел его как пример недостижимого для веб приложений. Так вот — оно и в Irfan View — бесполезная фича. Если уж я буду редактировать изображение — я воспользуюсь чем то поприличнее этого убожества. А если редактировать не надо, так и толку 0.
PD>Я спрашиваю, почему нельзя было позволить из файла читать/писать
Потому что безопасность и универсальность + исторические причины. Рано или поздно будет выработан стандартный механизм вроде тех же куков. Пощупать разные варианты можно уже сейчас в упомянутом Google Gears или SL 2.0.
В любом случае — это не фатальный недостаток архитектуры, а особенность текущей реализации.
PD>Да, эта проблема есть. Тут согласен. Но это лишь потому, что за вас эту работу выполнил броузер, а за нас — некому, сами должны. Я могу написать программу, которая будет хорошо приспосабливаться под разные шрифты и размеры текста
Не все так просто. Во-первых в рамках User32 нормально это сделать не выйдет, нужна полная замена вроде Swing или WPF (или хотя бы того же GTK+). А во-вторых — я посмотрю как ты обеспечишь полноценную работу этого всего кажем на всем зоопарке современных смартфонов.
PD>Чего-то я не понял. В десктопных приложениях либо есть такое выделение и Copy/Paste, либо нет.
Понимаешь, вот сделали окошко с сообщением, в котором сообщение лежит не в EDIT, а в STATIC. И все, абзац, без тулзов вроде спая фик ты текст оттуда куда нибудь вытащишь. А в веб-приложениях, только если специально не извращаться, любой текст можно выделить и скопировать в буфер, причем с форматированием, хоть из сообщения, хоть из пункта меню, хоть из тулбара.
PD>Первая здравая мысль, которую я слышу. Я же не против web-приложений вообще.
Хм.
Пока в основе будет лежать HTML и броузер, все останется как есть. Попытка с негодными средствами.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1054 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Пример нумбер 1. Вот я ползу по интернету и натыкаюсь на чего-то интересное (скажем небольшие логические игрушки люблю, сокобаны там, судоку...). Хочу. Что делаю? Тыкаю на ссылку. А потом? Если ссылка имеет вид "бла-бла-бла/get?file=earth.exe" (а если ещё рядом фигурирует слово shareware, уж простят меня шароварщики) я сразу напрягаюсь, чешу репу и рассуждаю на тему: "Качать или не качать? А ну её в баню, ломает меня нафиг. Это ведь надо ещё инсталлировать, хз троян ещё какой подцеплю... ", давлю интерес и закрываю таб. Вуаля: пользователь остался без программы, программа осталась без пользовательского внимания.
Означает ли это, что вообще никакие программы .exe нельзя скачивать ? Как же в таком случае быть с теми программами, которые есть ? Вот я сейчас новую версию Open Office скачал и установил. А вдруг туда Sun троян подсунула ?
Не загружайте программы с подозрительных сайтов. И вообще не ходите туда. Там и без EXE троян подцепить можно.
LCR>Пример нумбер 2. Вот меня просят заплатить за шаровару. Да блииин, это ж опять переться в банк, стоять очередях, заполнять эти идиотские бумажки... Нет уж, спасибо, я скачаю кряк, а моя совесть пусть отдувается. Мне не денег жалко, мне просто лень! А вот когда появилась оплата через СМС, стало намного (намного!) комфортнее — не отрывая задницу от стуля чик — и готово.
И что ? Что мешает эту оплату в приложение встроить ? Открываем из приложения линк, поскольку он внешний, приложение открывает его не в своем окне, а в новом окне броузер — и вперед. А разве некоторые десктопные вполне приложения не имеют линка в окне About, ведущего на сайт, где можно в том исле заплатить ?
LCR>Пример нумбер 3. Публичные шары. Когда попадаю на ссылку на rapidshare — меня напрягает конечно, но можно пережить. А когда ссылку на letitbit — ну уж нет, пусть они идут со своей закачкой на один общеизвестный адрес. Причина: с рапиды можно скачать хоть и с гемороем но без мусора, а для letitbit — заходить из-под IE (он меня бесит по идейным соображениям), качать спецкачалку (которая оказывается с трояном!), ставить этот мусор себе и только потом скачать файлик.
С letitbit не знаком, но что из всего сказанного следует — не понял. Я и не предлагаю любую закачку делать из приложения. Приложение, вообще говоря, закачкой файлов заниматься может, но не это у него основное.
LCR>так что earth.exe — это не наш путь. А с джава-апплетами идея провалилась похоже потому, что ГУЙ там выглядел по-уродски.
Здравствуйте, Kisloid, Вы писали:
K>Мне начинает казаться, что ваши примеры ограничиваются одними лишь maps.google.com, google docs, wikimapia, etc. Ну покажите мне редактор видео файлов с функционалом как у Adobe Premiere Pro, 3D Max, Photoshop и прочих.
Pavel Dvorkin,
LCR>>Пример нумбер 1. LCR>>Вуаля: пользователь остался без программы, программа осталась без пользовательского внимания.
PD>Означает ли это, что вообще никакие программы .exe нельзя скачивать ? Как же в таком случае быть с теми программами, которые есть ? Вот я сейчас новую версию Open Office скачал и установил. А вдруг туда Sun троян подсунула ?
Не означает, конечно, но я о другом говорил. Я говорил о том, что программа должна привлекать пользователя. И если программа будет .exe, то она будет гораздо менее привлекательна.
PD>Не загружайте программы с подозрительных сайтов. И вообще не ходите туда. Там и без EXE троян подцепить можно.
Хорошо, для контраста.
Маленькая, симпатичная судоку http://sudoku.mobilekp.ru/?id=1 неизвестного автора не вызывает никаких подозрений.
А вот sudoku.exe с лейблом (c) Microsoft я даже ставить не буду — однозначно подозрительный продукт.
тоже имеет силу.
LCR>>Пример нумбер 2.
PD>И что ? Что мешает эту оплату в приложение встроить ? Открываем из приложения линк, поскольку он внешний, приложение открывает его не в своем окне, а в новом окне броузер — и вперед. А разве некоторые десктопные вполне приложения не имеют линка в окне About, ведущего на сайт, где можно в том исле заплатить ?
Несекьюрно. Откуда мне знать, может это десктопное приложение заодно мои пароли отошлёт автору? Вообще сетевая активность десктопного приложения — это очень и очень подозрительно (разумеется, браузеров, джабберов и прочих это не касается).
LCR>>Пример нумбер 3.
PD>С letitbit не знаком, но что из всего сказанного следует — не понял. Я и не предлагаю любую закачку делать из приложения. Приложение, вообще говоря, закачкой файлов заниматься может, но не это у него основное.
Между rapidshare и letitbit принципиальная разница в том, что в первом случае можно скачать из браузера, а во втором этим занимается специальный letitbit-овский десктопный качальщик.
Возможно я был не совсем точен, я повторюсь ещё раз. Программы — самки, пользователи — самцы. Программам надо привлекать пользователей. Быть красивше, удобнее, бесплатнее. Если программа будет .exe, то это уже плохо, и целая армия пользователей даже не обратят на неё внимание. Даже если на неё будут прекрасные линки. Даже если у неё будет чудесный интерфейс со всякими манипуляциями мышкой. Даже если она будет максимально бесплатной. Всё равно она будет неудобной. Это такое проклятие при рождении "быть .exe".
K>>Я к тому, что веб и десктоп приложения не взаимоисключают друг друга, а лишь дополняют. S>Да, есть быстро сужающаяся ниша приложений, которые не получается перевести в веб.
Я бы даже сказал "пока не получается". Вон, ещё 5 лет назад все бы посмеялись если бы им рассказали об Excel-таблице в веб-браузере. А сейчас думаю MS уже становится не смешно при виде Google Docs 2D графика вон тоже потихоньку перелазит, думаю в ближайшем будещем стОит ждать и 3D.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И что ? Что мешает эту оплату в приложение встроить ? Открываем из приложения линк, поскольку он внешний, приложение открывает его не в своем окне, а в новом окне броузер — и вперед. А разве некоторые десктопные вполне приложения не имеют линка в окне About, ведущего на сайт, где можно в том исле заплатить ?
Кстати в Skype так и сделано, в меню выбираешь оплатить, он открывает не браузер, а свое окно, в котором можно и произвести оплату.
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
PD>>И что ? Что мешает эту оплату в приложение встроить ? Открываем из приложения линк, поскольку он внешний, приложение открывает его не в своем окне, а в новом окне броузер — и вперед. А разве некоторые десктопные вполне приложения не имеют линка в окне About, ведущего на сайт, где можно в том исле заплатить ?
K>Кстати в Skype так и сделано, в меню выбираешь оплатить, он открывает не браузер, а свое окно, в котором можно и произвести оплату.
Но там нельзя использовать третьи сервисы вроде moneybookers, по-моему, такое только через сайт.
Вдобавок, в скайпе для не-windows платформ такого окошка нет
K>Привлекательна, не привлекательна, самое главное, чтобы она была удобна для пользователя. Веб или десктоп это уже вопрос вторичный. Веб приложения неудобны как минимум тем, что невозможно поработать офф-лайн.
Google gears. Вот как раз на днях новость была о нём.
K>Я это к тому, что, что-то удобнее в виде веб приложений, а что-то в виде десктоп приложений и вряд ли это кардинально изменится в ближайшем будущем.
Ну а мы как раз говорим о том что в ближайшем будущем всё большая и большая часть приложений будет переползать в веб. Потому что (из того что ты назвал) разве что редактирование фотографий не слишком хорошо вписывается в веб-модель. Всё остальное (опять же — из того что ты назвал) либо имеет очень хорошие шансы уползти в веб, либо уже уползло.
K>Можно помечтать. Я бы был очень рад, если будет доступен почти в любом месте высокоскоростной интернет с 99.9% надежностью. Абсолютно все хранится на каких-либо супер серверах, в том числе и сама OS, а компы играют роль лишь тонких клиентов.
Опять же, тенденция развития идёт к тому что веб-приложения смогут работать в режиме "Occasionally Connected".
Здравствуйте, Mamut, Вы писали:
M>Никто и не говорит, что прямо таки все надо запихать в веб. Но есть приложения, которые ложатся в веб идеально, отлично и/или очень хорошо
+1
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, fmiracle, Вы писали:
F>Ты не понял, похоже, хитрую подтасовку от Павла. Irfan View — графический редактор. Ясен пень, в нем будет работа с изображением и разрезкой его на части.
немножко неверно я сказал Irfan View — это не редактор, а в первую очередь смотрелка. Но с все же интергированными возможностями для небольшого редактирования (как раз обрезать, повернуть, гамма, эффекты и т.д.) просматриваемого изображения.
Неважно — это специализированное приложение по работе именно с изображениями.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Mamut, Вы писали:
M>>ветки реесра я так же стираю через легальный общедоступный интерфейс GZ>Не совсем общедоступный. На реестр должны быть права. А главное документация.
Для стирания чего-нибудь в нем можно обойтись и без документации...
Нам же надо убедиться, что стираниями в реестре можно поломать работу приложения
. И за каким чертом серверу знать, что где-то на клиенте за 1000 км от него есть комбобокс
). Вся эта страничка воссоздается на сервере, вызывается наконец-то обрабочик этого события, формируется новая страница и отправляется клиенту... Не могу понять, почему это кем-то считаеться правильным?!
Или я ошибаюсь?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
