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

PD>Я бы так сказал — это тренд для серьезных компаний — та же Google. Но не для большинства компаний, увы...

Дело не в серьезности компании, а в серьезности человека, принимающего решения. А пока масса народа носится с горящими глазами и криками AJAX, AJAX и с PHP наперевес ...

PD>Тогда объясни, почему он не нужен для десктопных приложений. Там тоже вполне умеют "отображать графический интерфейс, на основе некой декларативной логики, заключённой в данных, получаемых от "... впрочем, неважно, откуда получаемых. Но без броузера великолепно обходятся.

Хм. WPF?

AVK>Дело не в серьезности компании, а в серьезности человека, принимающего решения. А пока масса народа носится с горящими глазами и криками AJAX, AJAX и с PHP наперевес ...

Потому что пока проще нарисовать какой-никакой гуи в ХТМЛ и связать их с логикой на сервере, чем в нынешних тулзах для десктоп-приложений

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

M>Потому что пока проще нарисовать какой-никакой гуи в ХТМЛ

Не проще. Я бы сказал так — тупее.

Здравствуйте, 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 — как раз позволит вернуть назад твою вставленную картинку.

Здравствуйте, 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.

M>>Потому что пока проще нарисовать какой-никакой гуи в ХТМЛ

AVK>Не проще. Я бы сказал так — тупее.

Проще-проше

PD>>Да разве только back button ? А возможность зайти на любую страницу, где уже был через history ? В том числе и на страницу, на которую вообще не положено заходить прямо, а только с некоей иной страницы ? Вот и ведут web-программисты отчаяную борьбу с тем, с чем вообще бороться и не надо бы, потому что этого не должно быть.
S>Вот это очень странно. Страница, на которую не положено заходить прямо — это плод травмированного головного мозга. Если на это не положено заходить прямо, то у этого не может быть URL.

Такая страница может быть промежуточной частью некой бизнес-транзакции. И да — у неё не должно быть прямой url, либо, что логичнее, страница по её url должна отслеживать состояние транзакции.

Здравствуйте, VGn, Вы писали:
VGn>Такая страница может быть промежуточной частью некой бизнес-транзакции. И да — у неё не должно быть прямой url, либо, что логичнее, страница по её url должна отслеживать состояние транзакции.

Совершенно верно. И HTTP позволяет нам писать приложения, которые такую реальность отражают. Только отсутствие опыта и систематического образования в данной области приводит к двум самым распространенным ошибкам:
— у ресурсов нет собственных URL (злоупотребление postback, AJAX, Flash, апплетами)
— у внутренних состояний бизнес-транзакций есть свои 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.

Future in The Past

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

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

S>>Это заблуждение. К примеру, в таком совершенно не веб приложении, как MS Money, back button работает просто на ура.
PD>Всегда можно найти пример, который не подходит под общий случай. Иногда, может быть, да, он нужен и полезен.
Всё как раз наоборот — навигационная модель прекрасно подходит для очень широкого класса случаев. Не уверен насчет 100% покрытия, но навскидку я не могу придумать приложения, которое бы не попало в навигационную модель (кроме тех игр, в которых usability принудительно запрещена).

S>>Вот это очень странно. Страница, на которую не положено заходить прямо — это плод травмированного головного мозга. Если на это не положено заходить прямо, то у этого не может быть URL.
PD>Может быть, и не может, но ведь есть, и нередко.
Я не понимаю, как можно критиковать подход, ссылаясь на нарушающие его приложения.

S>>Это просто непонимание разработчиками того, что такое веб-приложение.
PD>Нет, не согласен. Все же если в технологию закладывается то, что не очень-то осмысленно (а серверный комбобокс не очень осмысленная вещь), то виновата технология, а не разработчики.
С этого момента перестал понимать. Что такое "серверный комбобокс"? В какую тахнологию он вдруг оказался заложен? Бегу перечитывать (X)HTML Spec.

Здравствуйте, 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 в одном из не самыз популярных контролов одной не самой лучшей библиотеки оказался основанием для обвинения веб приложений вообще?

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

Здравствуйте, 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 по телнету наверное многие тут видали.