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

S>Здравствуйте, Сэма, Вы писали:

С>>>>Вопрос в зрительный зал? А кто-нибудь знает успешное коммерческое приложение на XUL?
С>>>>Хочется посмотреть.

S>>>Сложно судить о коммерческой успешности, но вот:
S>>>Komodo от ActiveState

С>>Придется уточнить вопрос. Успешные веб-приложения на XUL

S>Кроме вышеперечисленных — не могу. Under forever Construction

XUL-у уже несколько лет и то что до сих пор не появились такие приложения свидетельствует о технологии очень многое.

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

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

S>>Здравствуйте, Сэма, Вы писали:

С>>>Вопрос в зрительный зал? А кто-нибудь знает успешное коммерческое приложение на XUL?
С>>>Хочется посмотреть.

S>>Сложно судить о коммерческой успешности, но вот:
S>>Komodo от ActiveState

S>А вот Комодо как раз пример тормознутости и судя по всему как раз изза Mozilla Framework, а также неоправданной ресурсоёмкости, мне например сложно представить кто его использует, PHP, Perl,Js есть более удобные среды, Питон тоже, к тому же относительно к Питону последней каплей для меня стал запуск дебагера секунд 15 на P4-2,6 ГГц. Вообще как по мне Mozilla и её наследник "Рыжый лис" — это примеры как раз не самого лучшего дизайна, который имеет очень большой производительный и ресурсный оверхэд.

Насчет тормознутости — да есть немного, по сравнению с VS 6.0, а вот по сравнению с VS 7.x то вполне ничего.
А какие вы используете среды для Perl,JS (с дебугером) ?

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

S>... А XUL как был решением для одной платформы так и им останется, по крайней мере пока он не отгрызёт скажем 60% рынка, но этого в ближайшее время не предвидится.

Mozilla Framework работает на многих платформах .

Лично мое мнение — AJAX в том виде как он представлен сегодня — лишен смысла. Я просмотрел несколько библиотек AJAX указанных Выше, и увидел, что они состоят из 2-х частей — XMLHTTPRequest, и набор контролов аналогичных desktop-приложениям (плюс к ним свой язык описания интерфейса — xxxML) . Может я что-то пропустил, но помоему больше там ничего нет. А теперь по пунктам.
1. XMLHttpRequest — штука нужная и полезная.
2. Допустим мы делаем интранет приложение. На мой взгляд вполне логично получить от платформы набор контролов, свойства которых можно легко изменять, которые можно комбинировать между собой, получая более сложные контролы, разделять данные и способ их представления, при этом описывать это все простым языком. Мне известны только 2 платформы на сегодня — Mozilla Framework / XUL и Microsoft Avalon / XAML, и только одна из них реально используется сегодня — Mozilla. Простите, но помоему AJAX тут — никаким боком. Кроме контролов с рюшечками (100% cpu) он ничего не дает. Кроме того язык описания этих самых контролов сугубо специфичен, и велик риск что вся эта библиотега накроется медным тазом с выходом нового сервиспака на IE. А внутри этих библиотек — страшный оверхед по поддержанию единого вида на разных браузерах.
3. Строим Веб-сайт с продвинутым интерфейсом пользователя. Отлично, берем XMLHttpRequest, берем/придумываем пару красивых контролов и радуемся жизни. Но Это не библиотека AJAX. А как только на нашем сайте возникает потребность в БОГАТОМ интерфейсе пользователя — то добро пожаловать в п.2

Например, работа с банковским счетом через Веб-сайт — лично я предпочел бы десктоп-приложение а не веб-сайт. Тоже — книжный магазин. Мне больше нравится использовать Mozilla Amazon Browser, а не веб-сайт, и.т.д.

S>Лично мое мнение — AJAX в том виде как он представлен сегодня — лишен смысла. Я просмотрел несколько библиотек AJAX указанных Выше, и увидел, что они состоят из 2-х частей — XMLHTTPRequest, и набор контролов аналогичных desktop-приложениям (плюс к ним свой язык описания интерфейса — xxxML) . Может я что-то пропустил, но помоему больше там ничего нет.

Пропустил самое главное. Теперь это называется не просто AJAX, а Web 2.0 и это очень круто

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

S>>Лично мое мнение — AJAX в том виде как он представлен сегодня — лишен смысла. Я просмотрел несколько библиотек AJAX указанных Выше, и увидел, что они состоят из 2-х частей — XMLHTTPRequest, и набор контролов аналогичных desktop-приложениям (плюс к ним свой язык описания интерфейса — xxxML) . Может я что-то пропустил, но помоему больше там ничего нет.

M>Пропустил самое главное. Теперь это называется не просто AJAX, а Web 2.0 и это очень круто

Web 2.0.
Предоставление тех или иных сервисов через интернет — не ново.
Но мне кажется я понял что беспокоит лично меня. Мне не нравятся тонкие клиенты. Они не предоставляют максимального удобства, и при этом затраты на их реализацию Выше по сравнению с толстыми клиентами. То что сейчас называют AJAX — это тонкий клиент, а по моему скромному мнению — удел тонких клиентов — HTML и не более того.

Здравствуйте, sndralex, Вы писали:
M>>Пропустил самое главное. Теперь это называется не просто AJAX, а Web 2.0 и это очень круто

S>Web 2.0.
S>Предоставление тех или иных сервисов через интернет — не ново.
S>Но мне кажется я понял что беспокоит лично меня. Мне не нравятся тонкие клиенты. Они не предоставляют максимального удобства, и при этом затраты на их реализацию Выше по сравнению с толстыми клиентами. То что сейчас называют AJAX — это тонкий клиент, а по моему скромному мнению — удел тонких клиентов — HTML и не более того.
Тут возникает вопрос — а что называть HTML? Их ведь много. Если вообще отказаться от динамики в HTML — то веб, боюсь, станет очень-очень скучным. Юзабилити страшным образом упадет, т.к. даже для проверки MaxLength в Textarea придется сбегать на сервер, причем всей странице. Альтернатива какая? Пока что нет никакой стабильной платформы для написания веб приложений. Java апплеты не спасли. Толстого клиента во-первых никто не станет ставить, а во вторых его надо делать под все целевые платформы. Неясно, конечно, что дороже — поддерживать толстого клиента для Mac/Win/Lin или тонкого для IE/Mozilla/Safari. Но проблемы с деплойментом однозначно препятствуют внедрению сколь-нибудь толстых клиентов. Причем пока что не видно путей к улучшению ситуации.

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

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

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

S>>>Здравствуйте, Сэма, Вы писали:

С>>>>Вопрос в зрительный зал? А кто-нибудь знает успешное коммерческое приложение на XUL?
С>>>>Хочется посмотреть.

S>>>Сложно судить о коммерческой успешности, но вот:
S>>>Komodo от ActiveState

S>>А вот Комодо как раз пример тормознутости и судя по всему как раз изза Mozilla Framework, а также неоправданной ресурсоёмкости, мне например сложно представить кто его использует, PHP, Perl,Js есть более удобные среды, Питон тоже, к тому же относительно к Питону последней каплей для меня стал запуск дебагера секунд 15 на P4-2,6 ГГц. Вообще как по мне Mozilla и её наследник "Рыжый лис" — это примеры как раз не самого лучшего дизайна, который имеет очень большой производительный и ресурсный оверхэд.

S>Насчет тормознутости — да есть немного, по сравнению с VS 6.0, а вот по сравнению с VS 7.x то вполне ничего.
S>А какие вы используете среды для Perl,JS (с дебугером) ?
Ни Perl ни JS не использую, мне нужна IDE для Питона, пока единственная которую нашол приемлимого для меня качества это wing ide. А о тормозах у меня VS2003+VAssist на 600-м дюроне быстрее бегает и никаких тормозов, разве что на ACE, не замечаю. А Комодо на той же машыне не очень шустро бегает тормоза очень заметны(память и там и там 512 Мб), на новой машине П4-2,6Гц ситуация аналогичная и как я разговаривал з другими людьми которые пытались её использовать то там ситуация аналогичная. Единственное изза чего ещё держал комодо изза хорошего отладчика регекспов, но недавно увидел python kiki меня его функциональность устраивает, а стоит он ничего.

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

С>Вопрос в зрительный зал? А кто-нибудь знает успешное коммерческое приложение на XUL?
С>Хочется посмотреть.

Во внутренней автоматизации только. Но результат — фантастический.

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

S> последней каплей для меня стал запуск дебагера секунд 15 на P4-2,6 ГГц. Вообще как по мне Mozilla и её наследник "Рыжый лис" — это примеры как раз не самого лучшего дизайна, который имеет очень большой производительный и ресурсный оверхэд.

А мне дизайн архитектуры лиса нравится. К сожалению, не могу сравнить с кодом IE по очевидным причинам, но по моему — Лис даст огромную фору

Здравствуйте, <Аноним>, Вы писали:

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

S>> последней каплей для меня стал запуск дебагера секунд 15 на P4-2,6 ГГц. Вообще как по мне Mozilla и её наследник "Рыжый лис" — это примеры как раз не самого лучшего дизайна, который имеет очень большой производительный и ресурсный оверхэд.

А>А мне дизайн архитектуры лиса нравится. К сожалению, не могу сравнить с кодом IE по очевидным причинам, но по моему — Лис даст огромную фору
Проблема Лиса, что архитекторы при проэктировании в пользу совместимости с максимальным количеством платформ принесли в жертву эфэктивности. А вообще я пользуюсь Opera.

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

S>>Предоставление тех или иных сервисов через интернет — не ново.
S>>Неясно, конечно, что дороже — поддерживать толстого клиента для Mac/Win/Lin или тонкого для IE/Mozilla/Safari. Но проблемы с деплойментом однозначно препятствуют внедрению сколь-нибудь толстых клиентов. Причем пока что не видно путей к улучшению ситуации.

На самом деле есть еще третий путь, скажем это специализированный броузер рассчитанный на
"проигрывание" именно "applications pages" а не веб страниц.
Т.е. если для удобной работы client-server application типовой броузер не подходит значит
нужгно использовать подходящий броузер.

В принципе это то над чем я сейчас и работаю (проект Пандора).
Это в общем-то все тот же HTML/CSS/script как способ доставки/описания/активации.
Только CSS и script доработаны напильником.
Доработкам подверглись:
CSS: %%-units и вертикальное позиционирование/alignment, block flow (ака java layout managers), popups и dialogs.
script: встроенная поддержка ajax ( streams, sockets, printf("%v", val)/eval() )
behaviors и архитектура input: builtin & in script — это вообще отдельная и большая песня.
Например можно сказать <select><table><td><option>...</td></table></select> и/или склеить сложный behavior из набора более частных. <htmlarea> (WYSIWYG editor) здесь же.
persistence этих самых "applications pages": это тоже большая тема. Куки это конечно хорошо но идиому Occasionally Connected Application не держат.
canvas: прямое рисование как альтернатива векторным форматам и flash.

Вот примерно такое направление.

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

CS>Вот примерно такое направление.

Что насчет данных? Какови средства их хранения и связи с представлением?

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

S>Здравствуйте, c-smile, Вы писали:

CS>>Вот примерно такое направление.

S>Что насчет данных? Какови средства их хранения и связи с представлением?

Это про data binding?

Вот такая конструкция:

var named_values_in = get_values(form);
var named_values_out = ajax.post( "terrainformatica.com/app/rpc.php", named_values_in );
set_values(form,named_values_out);

работает замечательно.

Или надо что-то еще?

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

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

CS>работает замечательно.

CS>Или надо что-то еще?

У меня есть две формы. показывают одну и туже информацию. В одной форме информация изменилась. Что в другой?
У меня одна форма и один список, в котором есть запись отраженная в форме. В форме нажимают кнопку Apply и сохраняют запись. Что мы делаем со списком?

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

S>Здравствуйте, c-smile, Вы писали:

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

CS>>работает замечательно.

CS>>Или надо что-то еще?

S>У меня есть две формы. показывают одну и туже информацию. В одной форме информация изменилась. Что в другой?
S>У меня одна форма и один список, в котором есть запись отраженная в форме. В форме нажимают кнопку Apply и сохраняют запись. Что мы делаем со списком?

Наверное обновляем его?
В общем случае я не знаю как они связаны. И никто не знает.
Делать автоматический думатель по этому поводу — путь порочный как показала практика.

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

С>здесь

Кстати показалось интересным:
http://ajaxpatterns.org/

В глубь сильно не смотрел, сугубо поверхностный взгляд.

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

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

S>>>Предоставление тех или иных сервисов через интернет — не ново.
S>>>Неясно, конечно, что дороже — поддерживать толстого клиента для Mac/Win/Lin или тонкого для IE/Mozilla/Safari. Но проблемы с деплойментом однозначно препятствуют внедрению сколь-нибудь толстых клиентов. Причем пока что не видно путей к улучшению ситуации.

CS>На самом деле есть еще третий путь, скажем это специализированный броузер рассчитанный на
CS>"проигрывание" именно "applications pages" а не веб страниц.
CS>Т.е. если для удобной работы client-server application типовой броузер не подходит значит
CS>нужгно использовать подходящий броузер.

CS>В принципе это то над чем я сейчас и работаю (проект Пандора).
CS>Это в общем-то все тот же HTML/CSS/script как способ доставки/описания/активации.
CS>Только CSS и script доработаны напильником.
CS>Доработкам подверглись:
CS>CSS: %%-units и вертикальное позиционирование/alignment, block flow (ака java layout managers), popups и dialogs.
CS>script: встроенная поддержка ajax ( streams, sockets, printf("%v", val)/eval() )
CS>behaviors и архитектура input: builtin & in script — это вообще отдельная и большая песня.
CS>Например можно сказать <select><table><td><option>...</td></table></select> и/или склеить сложный behavior из набора более частных. <htmlarea> (WYSIWYG editor) здесь же.
CS>persistence этих самых "applications pages": это тоже большая тема. Куки это конечно хорошо но идиому Occasionally Connected Application не держат.
CS>canvas: прямое рисование как альтернатива векторным форматам и flash.

CS>Вот примерно такое направление.

Хм. Вопрос в том, насколько это направление уживается с "обычным" браузером. Если такое поведение существенно противоречит идее навигации в вебе, то это действительно третий путь. А если не противоречит, то мы говорим собственно не об отказе от динамики, а вовсе наоборот — об улучшении поддержки динамики в браузере. Т.е. это нормальное движение вперед, вполне типичное для эпохи браузерных войн.

c-smile wrote:
> Здравствуйте, sndralex, Вы писали:
> S>Здравствуйте, c-smile, Вы писали:
> CS>>Здравствуйте, sndralex, Вы писали:
> CS>>работает замечательно.
> CS>>Или надо что-то еще?
>
> S>У меня есть две формы. показывают одну и туже информацию. В одной
> форме информация изменилась. Что в другой?
> S>У меня одна форма и один список, в котором есть запись отраженная в
> форме. В форме нажимают кнопку Apply и сохраняют запись. Что мы делаем
> со списком?
>
> Наверное обновляем его?
> В общем случае я не знаю как они связаны. И никто не знает.
> Делать автоматический думатель по этому поводу — путь порочный как
> показала практика.
как не покажется странным любителям голого html, но вобщем-то уже многие
осознали необходимость в средствах databinding и структурированном
обмене информацией и даже стандарт придумали XForms

сугубо меня как программера никогда не веселила необходимость сначала
заталкивать из структурированных данных значения в поля html, а потом
их выковыривать при сабмите опять же в понятные с точки зрения
бизнес-логики структуры

собственно http://www.w3.org/MarkUp/Forms/ это и есть то, чего всегда
хотелось, но приходилось придумывать собственные средства
даже есть хороший пример X-Smile, который реализует многие аспекты не
только этой технологии, а еще XHTML, SVG и пр. ПРАВИЛЬНОЙ РАЗМЕТКИ

Возможно именно вам c-smile стоит обратить на это внимание, раз уж у вас
получилось реализовать собственную обработку такого монстра, как HTML

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

GW>c-smile wrote:
>> Здравствуйте, sndralex, Вы писали:
>> S>Здравствуйте, c-smile, Вы писали:
>> CS>>Здравствуйте, sndralex, Вы писали:
>> CS>>работает замечательно.
>> CS>>Или надо что-то еще?
>>
>> S>У меня есть две формы. показывают одну и туже информацию. В одной
>> форме информация изменилась. Что в другой?
>> S>У меня одна форма и один список, в котором есть запись отраженная в
>> форме. В форме нажимают кнопку Apply и сохраняют запись. Что мы делаем
>> со списком?
>>
>> Наверное обновляем его?
>> В общем случае я не знаю как они связаны. И никто не знает.
>> Делать автоматический думатель по этому поводу — путь порочный как
>> показала практика.
GW>как не покажется странным любителям голого html, но вобщем-то уже многие
GW>осознали необходимость в средствах databinding и структурированном
GW>обмене информацией и даже стандарт придумали XForms

GW>сугубо меня как программера никогда не веселила необходимость сначала
GW>заталкивать из структурированных данных значения в поля html, а потом
GW>их выковыривать при сабмите опять же в понятные с точки зрения
GW>бизнес-логики структуры

Это я понимаю.

htmlayout C++ интерфейс содержит следующее (sdk/include/htmlayout_controls.hpp):

  typedef std::map<std::wstring, value_t> named_values;

  inline bool get_values(dom::element& el, named_values& all ) { ... }
  inline bool set_values(dom::element& el, named_values& all ) { ... }

Функции позволяют собрать/установить значения в соответствующие элементы ввода
поддерева el. При этом например группа одноименных radio трактуется как один элемент
ввода и т.д.

Идея named_values — независимая от формы представления коллекция значений.
То же самое и в скрипт версии.

Операции над этой коллекцией и их последовательность бывает настолько
специфична для конкретных задач что никакой декларативно-формальный язык
xform / xpath не справится. А если и справится то это будет настолько
скажем коряво что уже будет близко к картине:
"Умерщвление Прекрасной Гипотезы Мерзким Фактом".

Предполагается что написать:

var myValues = getValues(form);

myValidate(myvalues);

send(url, myValues, timeout);

myUpdate(myValues, myOtherForm);

не составляет труда ни в скрипте ни С++.
И я не думаю что текст myValidate на C++ или скрипте будет
менее формальным/строгим чем на некоем суррогате типа xpath.

И к тому же C++ или скрипт можно отладить хот как-то.

GW>собственно http://www.w3.org/MarkUp/Forms/ это и есть то, чего всегда
GW>хотелось, но приходилось придумывать собственные средства
GW>даже есть хороший пример X-Smile, который реализует многие аспекты не
GW>только этой технологии, а еще XHTML, SVG и пр. ПРАВИЛЬНОЙ РАЗМЕТКИ

Что имеется ввиду под: "ПРАВИЛЬНОЙ РАЗМЕТКИ" ?

А можно узнать (я совершенно серьезно и без иронии) а что так
привлекательно в xforms c твоей точки зрения?
Data binding? validation?

Понятно что это все не ново под луной.
Попытка имплементации механизма data binding/validation
была предпринята еще в VB4. Механизм есть но им мало кто пользуется.
Задача "отмапить" запись в db на поля формы не стоит тех усилий которые
были затрачены на разработку соответсующей инфраструкуры.
Повторюсь — такой мапинг (отображение) это простейший

foreach( k; namedValues ) recordset[k] = namedValues[k];

в общем случае.

И вызов этого foreach происходит не по воле некоего думателя а
в деитерминированный суть известный момент времени.


GW>Возможно именно вам c-smile стоит обратить на это внимание, раз уж у вас
GW>получилось реализовать собственную обработку такого монстра, как HTML

Я собственно и обращаю внимание: есть rendering и styles. Есть behaviors как
отдельная сущность. И есть взаимотношенеие клиент-сервер.

В моем случае кстати сервером может быть и сам sciter
(это имя собсвенное того приложения что я делаю) — он может исполнять серверные
скрипты.

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

S>Здравствуйте, c-smile, Вы писали:

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

S>>>>Предоставление тех или иных сервисов через интернет — не ново.
S>>>>Неясно, конечно, что дороже — поддерживать толстого клиента для Mac/Win/Lin или тонкого для IE/Mozilla/Safari. Но проблемы с деплойментом однозначно препятствуют внедрению сколь-нибудь толстых клиентов. Причем пока что не видно путей к улучшению ситуации.

CS>>На самом деле есть еще третий путь, скажем это специализированный броузер рассчитанный на
CS>>"проигрывание" именно "applications pages" а не веб страниц.
CS>>Т.е. если для удобной работы client-server application типовой броузер не подходит значит
CS>>нужгно использовать подходящий броузер.

CS>>В принципе это то над чем я сейчас и работаю (проект Пандора).
CS>>Это в общем-то все тот же HTML/CSS/script как способ доставки/описания/активации.
CS>>Только CSS и script доработаны напильником.
CS>>Доработкам подверглись:
CS>>CSS: %%-units и вертикальное позиционирование/alignment, block flow (ака java layout managers), popups и dialogs.
CS>>script: встроенная поддержка ajax ( streams, sockets, printf("%v", val)/eval() )
CS>>behaviors и архитектура input: builtin & in script — это вообще отдельная и большая песня.
CS>>Например можно сказать <select><table><td><option>...</td></table></select> и/или склеить сложный behavior из набора более частных. <htmlarea> (WYSIWYG editor) здесь же.
CS>>persistence этих самых "applications pages": это тоже большая тема. Куки это конечно хорошо но идиому Occasionally Connected Application не держат.
CS>>canvas: прямое рисование как альтернатива векторным форматам и flash.

CS>>Вот примерно такое направление.

S>Хм. Вопрос в том, насколько это направление уживается с "обычным" браузером. Если такое поведение существенно противоречит идее навигации в вебе, то это действительно третий путь. А если не противоречит, то мы говорим собственно не об отказе от динамики, а вовсе наоборот — об улучшении поддержки динамики в браузере. Т.е. это нормальное движение вперед, вполне типичное для эпохи браузерных войн.

sciter (это имя нашего приложения) внешне выглядит как пустое окно с меню File c items "new window"/"open"/"print". Все.

"насколько это направление уживается с "обычным" браузером."

Представь себе что "обычный броузер" это есть файл browser.htm.
В этом файле "нарисованы" кнопки next/prev/home + address combobox + frame stack (html views).
К этому делу прикладывается скрипт и стили. А все вместе — файл с расширением sc.
Преполоагется что загрузив его ты будешь иметь функциональность броузера в том виде который тебе удобен/нужен.

"Третий путь" здесь состоит в том что именно ты грузишь в sciter.
Скажем редактор корпоративной wiki не требует кнопок next/prev — они наоборот только мешают.
Т.е. ты загрузишь http://intranet/ourwiki.sc в котором будут только корпоративные tools и все что действительно надо для
данной конкретной задачи/приложения.

С динамизмом html я думаю все понятно — здесь ничего мало не будет.