Здравствуйте, 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 как _очень_ тонкий клиент.
Он фактически и есть очень тонкий клиент. Я о том и говорю что не все типы приложенияй эту тонкость оценивают.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, c-smile, Вы писали:
AVK>>>Гы, черточка, гы. Под это определение можно подогнать абсолютно любой плагин для расширения возможностей UI. Например тот же XUL runner. В таком раскладе я конечно согласен — и аплеты, и SL, и Flash/Flex/Как_там_он_сейчас_называется, и XUL, и дотнетный System.Windows.Forms.UserControl и даже ActiveX — одна фигня.
CS>>Абсолютно верно. Концептуально это одно и то же
AVK>Все понятно. Дальше продолжать разговор смысла нет.
А чего начинал-то тогда ? Сказать чего хотел в тему топика или так просто?
Здравствуйте, 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-терминал в диких условиях? Я вот тоже не видел.
Здравствуйте, 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. Все.
Здравствуйте, 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?
Здравствуйте, 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 операций не добраться вообще.
Здравствуйте, c-smile, Вы писали:
CS>Частичным решением могло бы быть client side storage. Но этого нет ни в silverlight ни в Java Applet ни в Flex. CS>Есть попытка решить сие в Google Gears но опять же до стека undo/redo операций не добраться вообще.
Для Silverlight есть Isolated Storage
По умолчанию доступно 100Кб, можно увеличить по согласию пользователя.
Здравствуйте, 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:
— описанная суррогатная поддержка листания,
— отказ от мультибраузера, т.е. заключение движка браузера в собственном лёгком клиенте с подвластным нам интерфейсом.
Здравствуйте, VGn, Вы писали:
VGn>Т.е. если мы отказываемся от листания, истории и закладок, мы должны отказаться о мультибраузера как такового
Именно. Инструмент, изначально предназначенный совсем для других целей (свободное блуждание между статическими тогда страницами) стал использоваться для разработки интерактивных приложений со своей логикой, в общем, не имеющей никакого отношения к свободному блужданию.
>либо он должен сам отключать доступность этих действий в отношении нашего приложения по нашему же желанию.
Или так, хотя это паллиатив. Не это — так другое. Back и history просто очень уж на виду. А как насчет других опций Интернета, которые могут повлиять на поведение приложения ? Например, запрет/разрешение кэширования страниц на локальном диске...
VGn>При существующих реалиях выхода только 2: VGn>- описанная суррогатная поддержка листания,
Вот этот суррогат и живет пока что.
VGn>- отказ от мультибраузера, т.е. заключение движка браузера в собственном лёгком клиенте с подвластным нам интерфейсом.
Нет. В идеале — отказ от браузера как такового, потому что он не нужен. Не нужен же тебе браузер в десктопных приложениях ? И тут не нужен. Не для того он.
PD>Нет. В идеале — отказ от браузера как такового, потому что он не нужен. Не нужен же тебе браузер в десктопных приложениях ? И тут не нужен. Не для того он.
Нужен. Браузер — это способ отображения графического интерфеса, на основе некой декларативной логики, заключённой в данных, получаемых от сервиса.
Это нынешний тренд развития тонких клиентов.
Здравствуйте, VGn, Вы писали:
VGn>Это нынешний тренд развития тонких клиентов.
Нынешний тренд это смартклиенты — т.е. приложения с богатым интерфейсом, наличием кастомной логики на клиенте, наличие персистентного кеша для данных в клиенте и, по возможности, occasionally connected режим. Ну, к примеру, Google Earth.
... << RSDN@Home 1.2.0 alpha 3 rev. 883 on Windows Vista 6.0.6001.65536>>
AVK>Нынешний тренд это смартклиенты — т.е. приложения с богатым интерфейсом, наличием кастомной логики на клиенте, наличие персистентного кеша для данных в клиенте и, по возможности, occasionally connected режим. Ну, к примеру, Google Earth.
Смартклиенты при явно большей функциональности менее гибки в отношении деплоймента. Всему своё место.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нынешний тренд это смартклиенты — т.е. приложения с богатым интерфейсом, наличием кастомной логики на клиенте, наличие персистентного кеша для данных в клиенте и, по возможности, occasionally connected режим. Ну, к примеру, Google Earth.
Я бы так сказал — это тренд для серьезных компаний — та же Google. Но не для большинства компаний, увы...
Здравствуйте, VGn, Вы писали:
VGn>Нужен. Браузер — это способ отображения графического интерфеса, на основе некой декларативной логики, заключённой в данных, получаемых от сервиса. VGn>Это нынешний тренд развития тонких клиентов.
Тогда объясни, почему он не нужен для десктопных приложений. Там тоже вполне умеют "отображать графический интерфейс, на основе некой декларативной логики, заключённой в данных, получаемых от "... впрочем, неважно, откуда получаемых. Но без броузера великолепно обходятся.
