Автор упустил из виду, что помимо веб-сайтов бывают еще веб-приложения.
Для последних — ajax находка. Потому что передергивание страницы целиком
иногда обходится недопустимо дорого.
С>>здесь
dmz>Автор упустил из виду, что помимо веб-сайтов бывают еще веб-приложения. dmz>Для последних — ajax находка. Потому что передергивание страницы целиком dmz>иногда обходится недопустимо дорого.
Здравствуйте, Mamut, Вы писали:
С>>>здесь
dmz>>Автор упустил из виду, что помимо веб-сайтов бывают еще веб-приложения. dmz>>Для последних — ajax находка. Потому что передергивание страницы целиком dmz>>иногда обходится недопустимо дорого.
M>Он это и имел в виду, когда упомянул Web2.0
Чтобы он не был "сакс" для него нужен клиент подобающий.
Здравствуйте, dmz, Вы писали:
dmz>Здравствуйте, Сэма, Вы писали:
С>>здесь
dmz>Автор упустил из виду, что помимо веб-сайтов бывают еще веб-приложения. dmz>Для последних — ajax находка. Потому что передергивание страницы целиком dmz>иногда обходится недопустимо дорого.
А вот для Веб-приложений — ajax не находка. XUL — находка, а ajax — так себе; без роду без племени, без стандартов, и вечная битва с граблями на разных браузерах.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Mamut, Вы писали:
С>>>>здесь
dmz>>>Автор упустил из виду, что помимо веб-сайтов бывают еще веб-приложения. dmz>>>Для последних — ajax находка. Потому что передергивание страницы целиком dmz>>>иногда обходится недопустимо дорого.
M>>Он это и имел в виду, когда упомянул Web2.0
CS>Чтобы он не был "сакс" для него нужен клиент подобающий.
Ой! Да хтобы говорил
Здравствуйте, sndralex, Вы писали:
S>Здравствуйте, dmz, Вы писали:
dmz>>Здравствуйте, Сэма, Вы писали:
С>>>здесь
dmz>>Автор упустил из виду, что помимо веб-сайтов бывают еще веб-приложения. dmz>>Для последних — ajax находка. Потому что передергивание страницы целиком dmz>>иногда обходится недопустимо дорого.
S>А вот для Веб-приложений — ajax не находка. XUL — находка, а ajax — так себе; без роду без племени, без стандартов, и вечная битва с граблями на разных браузерах.
Кто такой XUL? Приблуда используемая в мозилла-гетто?
А AJAX — он типа для всех. Плохонький, но для всех
Здравствуйте, Сэма, Вы писали:
S>>А вот для Веб-приложений — ajax не находка. XUL — находка, а ajax — так себе; без роду без племени, без стандартов, и вечная битва с граблями на разных браузерах.
С>Кто такой XUL? Приблуда используемая в мозилла-гетто? С>А AJAX — он типа для всех. Плохонький, но для всех
Так мы говорим о web-приложениях или web-сайтах для всех?
Если о wеб-сайтах — то все эти монстрообразные AJAX frameworks — не нужны. Проше пойти на dklab.ru и взять его jshttprequest .
Если о web-приложениях — то все эти AJAX frameworks не нужны потому что они значително медленнее чем XUL на Mozilla Framework, а так же зависят от версии браузера, а так же не поддерживаются болшим сообшеством, но разрабатываются маленкой фирмой.
S>Так мы говорим о web-приложениях или web-сайтах для всех? S>Если о wеб-сайтах — то все эти монстрообразные AJAX frameworks — не нужны. Проше пойти на dklab.ru и взять его jshttprequest . S>Если о web-приложениях — то все эти AJAX frameworks не нужны потому что они значително медленнее чем XUL на Mozilla Framework, а так же зависят от версии браузера, а так же не поддерживаются болшим сообшеством, но разрабатываются маленкой фирмой.
S>IMHO.
Ситуация заключается также в следующем:
Веб-приложения это модно, а корпоративный стандарт это IE, как ни крути.
AJAX не панацея и действительно, можно ограничиться гаджетом от DKLab, но тогда придется для достаточно серьезного приложения писать свой FrameWork, или же таки использовать уже готовый.
Можно использовать старые варианты — перезагрузка страницы по каждому чиху (уже не модно и продать тяжело) и фреймы (тоже не сахар). Но все равно, это должно, прежде всего работать в IE.
Если в требованиях к приложению будет написано, что оно работает в мазиле... То как оно будет продаваться? Так что XUL тут отдыхает по банальной причине "непопулярности" в глазах широкой общественности.
Вопрос в зрительный зал? А кто-нибудь знает успешное коммерческое приложение на XUL?
Хочется посмотреть.
Читать про то как тормозит?
А вот у меня на работе летает. Странное дело — с их сайта и летает. А вот ужены на работе даже не прогрузилось? Вот такая вот фигня блин.
Тем более не забывайте про RSDN DDoS Team
Так ведь не упали За что им особенный респект
С>>Вопрос в зрительный зал? А кто-нибудь знает успешное коммерческое приложение на XUL? С>>Хочется посмотреть.
S>Сложно судить о коммерческой успешности, но вот: S>Komodo от ActiveState
Придется уточнить вопрос. Успешные веб-приложения на XUL
Здравствуйте, Сэма, Вы писали:
С>>>Вопрос в зрительный зал? А кто-нибудь знает успешное коммерческое приложение на XUL? С>>>Хочется посмотреть.
S>>Сложно судить о коммерческой успешности, но вот: S>>Komodo от ActiveState
С>Придется уточнить вопрос. Успешные веб-приложения на XUL
Кроме вышеперечисленных — не могу. Under Construction
Здравствуйте, FreshMeat, Вы писали:
FM>Здравствуйте, Сэма, Вы писали:
С>>здесь
FM>В блоге автора http://www.usabilityviews.com, наткнулся на интересный пост. Читать статью как-то расхотелось
В каждой шутке, есть доля шутки.
Да, действительно, статья изначально написана как пародия, но вот мысли достаточно разумные и часто встречающиеся у других противников AJAX'а. Этакая компиляция причин ненависти.
Хорошо хоть не на "Космополитен" пародия. Представьте себе заголовок типа — "10 причин, по которым модно не любить AJAX".
Здравствуйте, sndralex, Вы писали:
S>Здравствуйте, Сэма, Вы писали:
S>>>А вот для Веб-приложений — ajax не находка. XUL — находка, а ajax — так себе; без роду без племени, без стандартов, и вечная битва с граблями на разных браузерах.
С>>А AJAX — он типа для всех. Плохонький, но для всех
Болези роста, думаю после того как на него обратили внимание гранды его серйозно доработают.
S>Так мы говорим о web-приложениях или web-сайтах для всех? S>Если о wеб-сайтах — то все эти монстрообразные AJAX frameworks — не нужны. Проше пойти на dklab.ru и взять его jshttprequest . S>Если о web-приложениях — то все эти AJAX frameworks не нужны потому что они значително медленнее чем XUL на Mozilla Framework, а так же зависят от версии браузера, а так же не поддерживаются болшим сообшеством, но разрабатываются маленкой фирмой.
Вы приложения на заказ делаете или для души. Если первое то о XUL можете в большинстве случаев забыть, так как 99% случаев заказчик хочет чтоб приложение было доступно из всех распространённых платформ. А XUL как был решением для одной платформы так и им останется, по крайней мере пока он не отгрызёт скажем 60% рынка, но этого в ближайшее время не предвидится. А AJAX это мейнстрим и на него сейчас очень многие делают ставку. CSS тоже не всюду одинаково отображается, но его используют. S>IMHO.
Здравствуйте, sndralex, Вы писали:
S>Здравствуйте, Сэма, Вы писали:
С>>Вопрос в зрительный зал? А кто-нибудь знает успешное коммерческое приложение на XUL? С>>Хочется посмотреть.
S>Сложно судить о коммерческой успешности, но вот: S>Komodo от ActiveState
А вот Комодо как раз пример тормознутости и судя по всему как раз изза Mozilla Framework, а также неоправданной ресурсоёмкости, мне например сложно представить кто его использует, PHP, Perl,Js есть более удобные среды, Питон тоже, к тому же относительно к Питону последней каплей для меня стал запуск дебагера секунд 15 на P4-2,6 ГГц. Вообще как по мне Mozilla и её наследник "Рыжый лис" — это примеры как раз не самого лучшего дизайна, который имеет очень большой производительный и ресурсный оверхэд.
Здравствуйте, 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. Но проблемы с деплойментом однозначно препятствуют внедрению сколь-нибудь толстых клиентов. Причем пока что не видно путей к улучшению ситуации.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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 меня его функциональность устраивает, а стоит он ничего.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[6]: Why Ajax Sucks (Most of the Time)
От:
Аноним
Дата:
21.12.05 08:57
Оценка:
Здравствуйте, Сэма, Вы писали:
С>Вопрос в зрительный зал? А кто-нибудь знает успешное коммерческое приложение на XUL? С>Хочется посмотреть.
Во внутренней автоматизации только. Но результат — фантастический.
Re[8]: Why Ajax Sucks (Most of the Time)
От:
Аноним
Дата:
21.12.05 08:59
Оценка:
Здравствуйте, 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.
Здравствуйте, 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 и сохраняют запись. Что мы делаем со списком?
Наверное обновляем его?
В общем случае я не знаю как они связаны. И никто не знает.
Делать автоматический думатель по этому поводу — путь порочный как показала практика.
Здравствуйте, 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>Вот примерно такое направление.
Хм. Вопрос в том, насколько это направление уживается с "обычным" браузером. Если такое поведение существенно противоречит идее навигации в вебе, то это действительно третий путь. А если не противоречит, то мы говорим собственно не об отказе от динамики, а вовсе наоборот — об улучшении поддержки динамики в браузере. Т.е. это нормальное движение вперед, вполне типичное для эпохи браузерных войн.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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 на поля формы не стоит тех усилий которые
были затрачены на разработку соответсующей инфраструкуры.
Повторюсь — такой мапинг (отображение) это простейший
Здравствуйте, 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 я думаю все понятно — здесь ничего мало не будет.
c-smile wrote: > Здравствуйте, 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 — независимая от формы представления коллекция значений. > То же самое и в скрипт версии.
ну хочется не этого, а нечто понятное
<customer-info>
<person>
<first-name>Jack</first-name>
<last-name>Smith</last-name>
</person>
<address>
<country>USA</country>
<city>New York</city>
<street>17 st.</streer>
...
</address>
<payment-method type="visa">
<credit-card-number>...<credit-card-number>
<expiration-date>...</expiration-date>
</payment-method>
...
</customer-info>
и в идеале сериализуемое в объект C++
> Операции над этой коллекцией и их последовательность бывает настолько > специфична для конкретных задач что никакой декларативно-формальный язык > xform / xpath не справится.
кроме XPath еще есть XQuery, который гораздо более процедурный
> А если и справится то это будет настолько > скажем коряво что уже будет близко к картине: > "Умерщвление Прекрасной Гипотезы Мерзким Фактом". > > Предполагается что написать: > > var myValues = getValues(form); > > myValidate(myvalues); > > send(url, myValues, timeout); > > myUpdate(myValues, myOtherForm); > > не составляет труда ни в скрипте ни С++. > И я не думаю что текст myValidate на C++ или скрипте будет > менее формальным/строгим чем на некоем суррогате типа xpath. > > И к тому же C++ или скрипт можно отладить хот как-то.
речь в том, проверку валидности даты, номера кредитки или e-mail писать
не хочется, а задать её декларативно в XML Schema не составляет труда
> GW>собственно http://www.w3.org/MarkUp/Forms/ это и есть то, чего всегда > GW>хотелось, но приходилось придумывать собственные средства > GW>даже есть хороший пример X-Smile, который реализует многие аспекты не > GW>только этой технологии, а еще XHTML, SVG и пр. ПРАВИЛЬНОЙ РАЗМЕТКИ > Что имеется ввиду под: "ПРАВИЛЬНОЙ РАЗМЕТКИ" ?
правильная имеется в виду однознано задаваемая и однозначно
интерпретируемая и решающая именно те задачи для которых предназначена
например векторную графику проще нарисовать в Corel или InkJet
а не заморачиваться с canvas или что там Mozilla предлагает
формы с проверкой валидности и отсылкой в XML легко задать в XForms и
XSD, а не морочится с HTML + JS + XMLHTTPRequest
ну и можно продолжать
> А можно узнать (я совершенно серьезно и без иронии) а что так > привлекательно в xforms c твоей точки зрения? > Data binding? validation?
1. Специализированые элементы c настраивамым дизайном и поведением (в CSS)
2. Автоматическая проверка валидности данных
3. Связь c XML структурами
> Понятно что это все не ново под луной. > Попытка имплементации механизма data binding/validation > была предпринята еще в VB4. Механизм есть но им мало кто пользуется.
ну не согласен, примеры активного использованя data bound grid в VB и
Delphi, и NET буквально везде
> Задача "отмапить" запись в db на поля формы не стоит тех усилий которые > были затрачены на разработку соответсующей инфраструкуры. > Повторюсь — такой мапинг (отображение) это простейший > > foreach( k; namedValues ) recordset[k] = namedValues[k]; > > в общем случае. > > И вызов этого foreach происходит не по воле некоего думателя а > в деитерминированный суть известный момент времени.
там все также происходит в детерминированный и известный момент времени
если проводить аналогию, то рассмотрим процесс производства дверей
1. Специализированныа студия делает двери из натурального дерева с
ручной резьбой, примерно 1-2 в месяц
2. Фабрика по производству ламинированных дверей выпускает 100 моделей
тивовых дверей по 1000 штук в месяц
суть в том, что в больниству людей не нужна дверь с личным вензелем за
$2000 через месяц, а нужна обычная дверь за $50-100 сегодня
аналогично и в работе с бизнес-приложениями — потребность в уникальной
форме возникает раз в пол-года, а то и год
но обычные формы штампуются с регулярностью в неделю
> GW>Возможно именно вам c-smile стоит обратить на это внимание, раз уж у вас > GW>получилось реализовать собственную обработку такого монстра, как HTML > > Я собственно и обращаю внимание: есть rendering и styles. Есть behaviors как > отдельная сущность. И есть взаимотношенеие клиент-сервер. > > В моем случае кстати сервером может быть и сам sciter > (это имя собсвенное того приложения что я делаю) — он может исполнять > серверные скрипты.
все это не более чем попытка эмулировать нужную функциональность
имеющимися средствами
для эффективной работы требуется понятная объектная модель элементов
управления и доступа к данным, а не предлагаемые трюки с HTML и скриптами
где MAP_NAMED_VALUE это макрос типа DDX/DDV
GW>кроме XPath еще есть XQuery, который гораздо более процедурный
Я не возражаю.
Единственное но: я как разработчик встраиваемого html engine
имплементировать ни XPath ни XQuery внутри оного считаю
нецелесообразным. Это 1) далеко не всем нужно и 2) не хочется
создавать монстра забитого под завязку "счастьем для всех и бесплатно"
до такой степени что о встраиваемости можно будет забыть.
GW>речь в том, проверку валидности даты, номера кредитки или e-mail писать GW>не хочется, а задать её декларативно в XML Schema не составляет труда
Согласен что не надо каждый раз это писать. А тем более в XML schema
где уже "поздно рить боржоми". behavior в момент редактирвания или потери
фокуса должен проверять значение. И если оно невалидно то делать что-то по месту
пока юзер не ушел далеко.
Например стандартный <input type=number> при выходе
значения за диапазон выставляет у input аттрибут invalid а в CSS
прописано:
input[type="number"][invalid]
{
color:red;
}
Надо писать один раз систему behaviors по себя и задачу.
Т.к. система допускает несколько behaviors у одного элемента
то можно например сделать просто набор валидаторов под себя.
Т.к. behaviors имееют доступ к DOM элементу то такие
валидаторы можно параметризовать по всякому используя атрибуты в html того элемента
к которому они крепятся.
>> А можно узнать (я совершенно серьезно и без иронии) а что так >> привлекательно в xforms c твоей точки зрения? >> Data binding? validation?
GW>1. Специализированые элементы c настраивамым дизайном и поведением (в CSS) GW>2. Автоматическая проверка валидности данных
в htmlayout это делается с помощью behaviors. assignment этих behaviors
делается с помощью CSS.
GW>3. Связь c XML структурами
в htmlayout это это делается с помощью конверторов named_values в
нужные формы представления данных. Включая XML или JSON (для передачи)
и поля в recordsets (для хранения).
>> Понятно что это все не ново под луной. >> Попытка имплементации механизма data binding/validation >> была предпринята еще в VB4. Механизм есть но им мало кто пользуется. GW>ну не согласен, примеры активного использованя data bound grid в VB и GW>Delphi, и NET буквально везде.
Наверное в каких-то простых случаях это действительно возможно.
Но в реальном дизайне форма хранения данных и форма представления
оных это разные вещи. Реально прямое отображение построить очень сложно
с помощью только деклараций.
>> Задача "отмапить" запись в db на поля формы не стоит тех усилий которые >> были затрачены на разработку соответсующей инфраструкуры. >> Повторюсь — такой мапинг (отображение) это простейший >> >> foreach( k; namedValues ) recordset[k] = namedValues[k]; >> >> в общем случае. >> >> И вызов этого foreach происходит не по воле некоего думателя а >> в деитерминированный суть известный момент времени. GW>там все также происходит в детерминированный и известный момент времени
GW>если проводить аналогию, то рассмотрим процесс производства дверей GW>1. Специализированныа студия делает двери из натурального дерева с GW>ручной резьбой, примерно 1-2 в месяц GW>2. Фабрика по производству ламинированных дверей выпускает 100 моделей GW>тивовых дверей по 1000 штук в месяц
GW>суть в том, что в больниству людей не нужна дверь с личным вензелем за GW>$2000 через месяц, а нужна обычная дверь за $50-100 сегодня
Неверная аналогия. Если некая фабрика хочет выпускать двери по 100$
то она выбирает соотвествующй материал и изготавливает оснастку
для этого (например набор behaviors).
Для быстрого изотовления дешевых дверей никто не использует полные конструкторы
Лего. Из них можно быстро строить двери. Только будут ли их покупать?
То же самое и здесь:
htmlayout как встриваемый engine — это фактически заготовка для построения UI
определнного типа — web alike dynamic UI.
И это не броузер. Посмотри на behavior_hyperlink.cpp в SDK — обработка
hyperlink_click это часть *твоего* application — твоему application решать
куда ходить а куда нет, что грузить а что нет и откдуа если да.
И по поводу твоей аналогии опять же:
И второй и первый случай это задачи для htmlayout.
Я например знаю что htmlayout используется одной фирмой как средство branded UI.
Т.е. у них есть одно приложение которое они поставляют разным конторам
с настройкой под brand name последних. Вот это и есть твои двери по 100$.
GW>аналогично и в работе с бизнес-приложениями — потребность в уникальной GW>форме возникает раз в пол-года, а то и год GW>но обычные формы штампуются с регулярностью в неделю
Ну да.
Минимально достаточный engine (скорость + компактность) и
соответсвующая эффективная оснастка — ключ к успеху.
>> GW>Возможно именно вам c-smile стоит обратить на это внимание, раз уж у вас >> GW>получилось реализовать собственную обработку такого монстра, как HTML >> >> Я собственно и обращаю внимание: есть rendering и styles. Есть behaviors как >> отдельная сущность. И есть взаимотношенеие клиент-сервер. >> >> В моем случае кстати сервером может быть и сам sciter >> (это имя собсвенное того приложения что я делаю) — он может исполнять >> серверные скрипты. GW>все это не более чем попытка эмулировать нужную функциональность GW>имеющимися средствами
Не понял.
GW>для эффективной работы требуется понятная объектная модель элементов GW>управления и доступа к данным, а не предлагаемые трюки с HTML и скриптами
Что имеется ввиду? Эффективная работа продукта? Или эффективная работа команды?
Если последнее то каоманды какой квалификации и состава?
"а не предлагаемые трюки с HTML и скриптами".
Какие трюки? Я лично как раз "трюков" в принципе пытаюсь избегать.
Вот попытка написать UI системы на базе броузера общего назначения это да — один большой трюк.
c-smile wrote: > Здравствуйте, GW, Вы писали: > GW>ну хочется не этого, а нечто понятное > GW><customer-info> > GW> <person> > GW> <first-name>Jack</first-name> > GW> <last-name>Smith</last-name> > GW> </person> > GW> <address> > GW> <country>USA</country> > GW> <city>New York</city> > GW> <street>17 st.</streer> > GW> ... > GW> </address> > GW> <payment-method type="visa"> > GW> <credit-card-number>...<credit-card-number> > GW> <expiration-date>...</expiration-date> > GW> </payment-method> > GW> ... > GW></customer-info> > GW>и в идеале сериализуемое в объект C++ > > Т.е. мы имеем задачу mapping. > Но я не понимаю зачем здесь XML если тебе нужна C++ структура на самом деле?
она мне на стороне сервера нужна, а не клиента — разница чувствуется?
> Еще раз повторю себя же: > "Идея named_values — независимая от формы представления коллекция значений. > То же самое и в скрипт версии." > > Имея named_values построить нечто типа: > > struct customer_info_t > { > person_t person; > address_t address; > payment_method_t payment; > > > void map( named_values& nv, bool direction ) > { > MAP_NAMED_VALUE( person.first_name, "person_first_name" ); > MAP_NAMED_VALUE( person.last_name, "person_last_name" ); > } > }; > > где MAP_NAMED_VALUE это макрос типа DDX/DDV
я думаю разница понятна без комментариев
> GW>кроме XPath еще есть XQuery, который гораздо более процедурный > Я не возражаю. > Единственное но: я как разработчик встраиваемого html engine > имплементировать ни XPath ни XQuery внутри оного считаю > нецелесообразным. Это 1) далеко не всем нужно и 2) не хочется > создавать монстра забитого под завязку "счастьем для всех и бесплатно" > до такой степени что о встраиваемости можно будет забыть.
критерий встраиваемости? размер dll файла? число dll файлов?
очевидно встраиваемость определяется на уровне API, а не критериями
много или мало функций к тому же все это может быть модульным
нужны сложные манипуляции — включи XQuery
нужна веселенькая графика — включи SVG
> GW>речь в том, проверку валидности даты, номера кредитки или e-mail писать > GW>не хочется, а задать её декларативно в XML Schema не составляет труда > Согласен что не надо каждый раз это писать. А тем более в XML schema > где уже "поздно рить боржоми". behavior в момент редактирвания или потери > фокуса должен проверять значение. И если оно невалидно то делать что-то > по месту пока юзер не ушел далеко.
абсолютно согласен! вот на месте и нужно проверять на соотвествие схеме
вобщем-то я предлагаю вам почитать стандарт XForms, чтобы не было
недопонимания
> Например стандартный <input type=number> при выходе > значения за диапазон выставляет у input аттрибут invalid а в CSS > прописано: > input[type="number"][invalid] > { > color:red; > } > > Надо писать один раз систему behaviors по себя и задачу. > Т.к. система допускает несколько behaviors у одного элемента > то можно например сделать просто набор валидаторов под себя. > > Т.к. behaviors имееют доступ к DOM элементу то такие > валидаторы можно параметризовать по всякому используя атрибуты в html > того элемента > к которому они крепятся.
см. примечание про двери
>> > А можно узнать (я совершенно серьезно и без иронии) а что так >> > привлекательно в xforms c твоей точки зрения? >> > Data binding? validation? > > GW>1. Специализированые элементы c настраивамым дизайном и поведением (в > CSS) > GW>2. Автоматическая проверка валидности данных > в htmlayout это делается с помощью behaviors. assignment этих behaviors > делается с помощью CSS.
это я понял, но см. двери
> GW>3. Связь c XML структурами > в htmlayout это это делается с помощью конверторов named_values в > нужные формы представления данных. Включая XML или JSON (для передачи) > и поля в recordsets (для хранения).
это я тоже понял, но см. двери
>> > Понятно что это все не ново под луной. >> > Попытка имплементации механизма data binding/validation >> > была предпринята еще в VB4. Механизм есть но им мало кто пользуется. > GW>ну не согласен, примеры активного использованя data bound grid в VB и > GW>Delphi, и NET буквально везде. > Наверное в каких-то простых случаях это действительно возможно. > Но в реальном дизайне форма хранения данных и форма представления > оных это разные вещи. Реально прямое отображение построить очень сложно > с помощью только деклараций.
это возможно в 90% случаев
>> > Задача "отмапить" запись в db на поля формы не стоит тех усилий которые >> > были затрачены на разработку соответсующей инфраструкуры. >> > Повторюсь — такой мапинг (отображение) это простейший >> > >> > foreach( k; namedValues ) recordset[k] = namedValues[k]; >> > >> > в общем случае. >> > >> > И вызов этого foreach происходит не по воле некоего думателя а >> > в деитерминированный суть известный момент времени. > GW>там все также происходит в детерминированный и известный момент времени > > GW>если проводить аналогию, то рассмотрим процесс производства дверей > GW>1. Специализированныа студия делает двери из натурального дерева с > GW>ручной резьбой, примерно 1-2 в месяц > GW>2. Фабрика по производству ламинированных дверей выпускает 100 моделей > GW>тивовых дверей по 1000 штук в месяц > > GW>суть в том, что в больниству людей не нужна дверь с личным вензелем за > GW>$2000 через месяц, а нужна обычная дверь за $50-100 сегодня > > Неверная аналогия. Если некая фабрика хочет выпускать двери по 100$ > то она выбирает соотвествующй материал и изготавливает оснастку > для этого (например набор behaviors).
да выбирается материал, но оснастка не изготавливается, а берется готовая
причем речь идет не о многопрофильном оборудовании с которым можно
сделать или окно, или дверь, а о специализированном для дверей
> Для быстрого изотовления дешевых дверей никто не использует полные > конструкторы Лего. Из них можно быстро строить двери. Только будут ли их покупать?
отчего же — если получится сделать такое лего, и это будет дешево и
надежно покупать будут
лего (сборные) дома ведь покупают во всем мире и ничего все довольны
> То же самое и здесь: > htmlayout как встриваемый engine — это фактически заготовка для > построения UI > определнного типа — web alike dynamic UI. > И это не броузер. Посмотри на behavior_hyperlink.cpp в SDK — обработка > hyperlink_click это часть *твоего* application — твоему application решать > куда ходить а куда нет, что грузить а что нет и откдуа если да. > > И по поводу твоей аналогии опять же: > > И второй и первый случай это задачи для htmlayout. > Я например знаю что htmlayout используется одной фирмой как средство > branded UI. > Т.е. у них есть одно приложение которое они поставляют разным конторам > с настройкой под brand name последних. Вот это и есть твои двери по 100$.
хотите я напишу описание продукта и вы пошлете его своим клиентам для
проверки насколько их устроил бы такой подход
только вот если вы его реализуете — придется поделится процентом прибыли
> GW>аналогично и в работе с бизнес-приложениями — потребность в уникальной > GW>форме возникает раз в пол-года, а то и год > GW>но обычные формы штампуются с регулярностью в неделю > > Ну да. > Минимально достаточный engine (скорость + компактность) и > соответсвующая эффективная оснастка — ключ к успеху.
ключевое слово ДОСТАТОЧНЫЙ
WINAPI достаточен, но для чего?
>> > GW>Возможно именно вам c-smile стоит обратить на это внимание, раз уж > у вас >> > GW>получилось реализовать собственную обработку такого монстра, как HTML >> > >> > Я собственно и обращаю внимание: есть rendering и styles. Есть > behaviors как >> > отдельная сущность. И есть взаимотношенеие клиент-сервер. >> > >> > В моем случае кстати сервером может быть и сам sciter >> > (это имя собсвенное того приложения что я делаю) — он может исполнять >> > серверные скрипты. > GW>все это не более чем попытка эмулировать нужную функциональность > GW>имеющимися средствами > > Не понял. > > GW>для эффективной работы требуется понятная объектная модель элементов > GW>управления и доступа к данным, а не предлагаемые трюки с HTML и скриптами > > Что имеется ввиду? Эффективная работа продукта? Или эффективная работа > команды? > Если последнее то каоманды какой квалификации и состава?
скорость работы интерфейса мало значима по сравнению со скоростью
разработки и возможностями использования работников с самой различной
квалификацией
почему я так думаю:
1. Вычислительные мошности растут и уже мало кого беспокоит скорость
работы Java и NET по сравнению с Native кодом
2. Время разработки — деньги затрачиваемые команией-разработчиком
3. Квалификация персонала — деньги затрачиваемые команией-разработчиком
> "а не предлагаемые трюки с HTML и скриптами". > Какие трюки? Я лично как раз "трюков" в принципе пытаюсь избегать. > Вот попытка написать UI системы на базе броузера общего назначения это > да — один большой трюк.
относительно монстроидальных прикладух с IE внутри я с вами абсолютно
согласен
-("знак минус") еще две проблемы, которые приписываю AJAX
Смотрим http://www.backbase.com/demos/explorer/#examples/browser_history.xml[4] (четверка в квадратных скобках тоже составляющая url. Так что, copy-past)
1) Теперь можно обмениваться закладкми.
2) Кнопки "вперед" "назад" также начинают работать.
Не спорю, и то и другое требует значительных приседаний. Но сам факт не может не радовать.
Здравствуйте, GW, Вы писали:
GW>c-smile wrote: >> Здравствуйте, GW, Вы писали: >> GW>ну хочется не этого, а нечто понятное >> GW><customer-info> >> GW></customer-info> >> GW>и в идеале сериализуемое в объект C++ >> >> Т.е. мы имеем задачу mapping. >> Но я не понимаю зачем здесь XML если тебе нужна C++ структура на самом деле? GW>она мне на стороне сервера нужна, а не клиента — разница чувствуется?
Нет, если честно. Клиент на сервер передает плоскую коллекцию параметров (POST/GET request parameters).
Ну и сделай этот mapping на стороне сервера. Зачем это все заворачивать в XML?
>> void map( named_values& nv, bool direction ) >> { >> MAP_NAMED_VALUE( person.first_name, "person_first_name" ); >> MAP_NAMED_VALUE( person.last_name, "person_last_name" ); >> } >> >> где MAP_NAMED_VALUE это макрос типа DDX/DDV GW>я думаю разница понятна без комментариев
Ничего мне не понятно если честно.
Как ты собираешься декларативно заполнять C++ структуры?
Неважно из чего: из XML или из какой другой коллекции...
Конструкций типа
не миновать.
>> Единственное но: я как разработчик встраиваемого html engine >> имплементировать ни XPath ни XQuery внутри оного считаю >> нецелесообразным. Это 1) далеко не всем нужно и 2) не хочется >> создавать монстра забитого под завязку "счастьем для всех и бесплатно" >> до такой степени что о встраиваемости можно будет забыть. GW>критерий встраиваемости? размер dll файла? число dll файлов? GW>очевидно встраиваемость определяется на уровне API, а не критериями GW>много или мало функций к тому же все это может быть модульным GW>нужны сложные манипуляции — включи XQuery GW>нужна веселенькая графика — включи SVG
Согласен. Только если говорить о модульности в software design то
будет не "включи" а "добавь в проект".
И это принципиальный подход. Это то что я называю встраиваемостью.
Если тебе нужен SVG — добавь behavior который реализует SVG рисование.
"нужны сложные манипуляции" — добавь в свой проект XQuery модуль.
Вопросами "как мне включить-выключить то или это в IWebBrowser?"
забито пол интернета. Ответ в большинстве случаев — а никак — вшито насмерть.
>> GW>речь в том, проверку валидности даты, номера кредитки или e-mail писать >> GW>не хочется, а задать её декларативно в XML Schema не составляет труда >> Согласен что не надо каждый раз это писать. А тем более в XML schema >> где уже "поздно рить боржоми". behavior в момент редактирвания или потери >> фокуса должен проверять значение. И если оно невалидно то делать что-то >> по месту пока юзер не ушел далеко. GW>абсолютно согласен! вот на месте и нужно проверять на соотвествие схеме GW>вобщем-то я предлагаю вам почитать стандарт XForms, чтобы не было GW>недопонимания.
Делал я попытку импелементировать xforms.
Там больше вопросов чем ответов. xforms в том виде что есть не делает
и половины того что может javascript. Возникает вопрос — а зачем оно тогда?
Вообще попытка загнать описание процедур в XML смотрится просто технически неграмотно.
Ну не для того XML сделан-то был.
На самом-то деле и даже для передачи данных JSON (как родной формат AJAX) более богатый что-ли и в то же время
более компактный (на 20%-50%). Во всяком случае в нем есть структуры данных: массивы и ассоциативные массивы
а также атомарные типы данных а не только string.
c-smile wrote: > Здравствуйте, GW, Вы писали: > GW>c-smile wrote: >> > Здравствуйте, GW, Вы писали: >> > GW>ну хочется не этого, а нечто понятное >> > GW><customer-info> >> > GW></customer-info> >> > GW>и в идеале сериализуемое в объект C++ >> > >> > Т.е. мы имеем задачу mapping. >> > Но я не понимаю зачем здесь XML если тебе нужна C++ структура на > самом деле? > GW>она мне на стороне сервера нужна, а не клиента — разница чувствуется? > > Нет, если честно. Клиент на сервер передает плоскую коллекцию параметров > (POST/GET request parameters). > Ну и сделай этот mapping на стороне сервера. Зачем это все заворачивать > в XML?
передача простой структуры
<persons>
<person>
<name>...</name>
</person>
...
<person>
<name>...</name>
</person>
</persons>
уже требует неоправданных усилий по введению правил именования
параметров, разбору их по приходу и т.п.
пример из жизни — в одной из форм имена полей на определенном уровне
былы по 80 символов из-за вложенности
можно конечно было поиздеваться над собой и обойтись без повторного
использования кода или какие-то еще действия по согласованию
предпринимать, но сами понимаете оно того не стоит
>> > void map( named_values& nv, bool direction ) >> > { >> > MAP_NAMED_VALUE( person.first_name, "person_first_name" ); >> > MAP_NAMED_VALUE( person.last_name, "person_last_name" ); >> > } >> > >> > где MAP_NAMED_VALUE это макрос типа DDX/DDV > GW>я думаю разница понятна без комментариев > > Ничего мне не понятно если честно. > > Как ты собираешься декларативно заполнять C++ структуры? > Неважно из чего: из XML или из какой другой коллекции... > Конструкций типа > > MAP_NAMED_VALUE( person.first_name, "person_first_name" ); > MAP_NAMED_VALUE( person.last_name, "person_last_name" ); > не миновать.
ну как-бы да, но не обязательно
сначала пишем схему, потом по этой схеме генерируем классы,
генератор пишет код за нас
идеально хотелось бы конечно делать наоборот — сначала пишем
классы, а некий движок сам выдупляет как сериализовать/десериализовать
их в XML
проблема с таким подходом — на С++ практически не реализуется, или с
массой ограничений
для этого должна быть развитая рефлексивность, как у Java или NET
можно конечно идти по пути маппинга в каждом классе — все же это лучше
чем на уровне обработки запроса парсить
>> > Единственное но: я как разработчик встраиваемого html engine >> > имплементировать ни XPath ни XQuery внутри оного считаю >> > нецелесообразным. Это 1) далеко не всем нужно и 2) не хочется >> > создавать монстра забитого под завязку "счастьем для всех и бесплатно" >> > до такой степени что о встраиваемости можно будет забыть. > GW>критерий встраиваемости? размер dll файла? число dll файлов? > GW>очевидно встраиваемость определяется на уровне API, а не критериями > GW>много или мало функций к тому же все это может быть модульным > GW>нужны сложные манипуляции — включи XQuery > GW>нужна веселенькая графика — включи SVG > Согласен. Только если говорить о модульности в software design то > будет не "включи" а "добавь в проект". > И это принципиальный подход. Это то что я называю встраиваемостью.
ну это не более чем философия, что называть встраиваемостью
например мне удобнее шаблоны для WTL использовать, чем ActiveX или dll
подключать
принимаете такую концепцию встраиваемости — думаю нет, поскольку
найдутся умники и выложат ваш продукт где-нибудь на варезном сайте
> Если тебе нужен SVG — добавь behavior который реализует SVG рисование. > "нужны сложные манипуляции" — *добавь в свой проект* XQuery модуль. > > Вопросами "как мне включить-выключить то или это в IWebBrowser?" > забито пол интернета. Ответ в большинстве случаев — а никак — вшито > насмерть.
я же не предлагаю вам все это в один dll файл засунуть — поставляйте
отдельные модули, более того даже за отдельные деньги (потому как не
всем SVG нужен)
суть в том, что продвигаемый вами подход отличается аскетизмом, но
поверьте веб-сервер написанный на постскрипте не воспринимается, как
нечто полезное, хотя это принципиально возможно и даже есть реализация
>> > GW>речь в том, проверку валидности даты, номера кредитки или e-mail > писать >> > GW>не хочется, а задать её декларативно в XML Schema не составляет труда >> > Согласен что не надо каждый раз это писать. А тем более в XML schema >> > где уже "поздно рить боржоми". behavior в момент редактирвания или потери >> > фокуса должен проверять значение. И если оно невалидно то делать что-то >> > по месту пока юзер не ушел далеко. > GW>абсолютно согласен! вот на месте и нужно проверять на соотвествие схеме > GW>вобщем-то я предлагаю вам почитать стандарт XForms, чтобы не было > GW>недопонимания. > Делал я попытку импелементировать xforms. > > Там больше вопросов чем ответов. xforms в том виде что есть не делает > и половины того что может javascript. Возникает вопрос — а зачем оно тогда?
либо у вас какие-то своеобразные запросы, либо вы не до конца изучили тему
> Вообще попытка загнать описание процедур в XML смотрится просто > технически неграмотно. > Ну не для того XML сделан-то был.
загнать описание бизнес-процессов в XML тоже не грамотно?
альтернативных варианта было бы два текстовое описание или скажем С++
> На самом-то деле и даже для передачи данных JSON (как родной формат > AJAX) более богатый что-ли и в то же время > более компактный (на 20%-50%). Во всяком случае в нем есть структуры > данных: массивы и ассоциативные массивы > а также атомарные типы данных а не только string.
что-то вы не дооцениваете XML, хотя вы правы массивов и списков нет, но
есть XML
насчет компактности, учитывая поддержку сжатия при передаче данных, мне
кажется это уже не вопрос
Здравствуйте, GW, Вы писали:
GW>уже требует неоправданных усилий по введению правил именования GW>параметров, разбору их по приходу и т.п. GW>пример из жизни — в одной из форм имена полей на определенном уровне GW>былы по 80 символов из-за вложенности
Неоправданных усилий?
А лепить в кучу XQuery, XForms c XPath это оправданные усилия?
Без отладчика, сред разработки и прочего?
GW>можно конечно было поиздеваться над собой и обойтись без повторного GW>использования кода или какие-то еще действия по согласованию GW>предпринимать, но сами понимаете оно того не стоит
Не понимаю: что чего не стоит?
>> >> Как ты собираешься декларативно заполнять C++ структуры? >> Неважно из чего: из XML или из какой другой коллекции... >> Конструкций типа >> >> MAP_NAMED_VALUE( person.first_name, "person_first_name" ); >> MAP_NAMED_VALUE( person.last_name, "person_last_name" ); >> не миновать. GW>ну как-бы да, но не обязательно GW>сначала пишем схему, потом по этой схеме генерируем классы, GW>генератор пишет код за нас GW>идеально хотелось бы конечно делать наоборот — сначала пишем GW>классы, а некий движок сам выдупляет как сериализовать/десериализовать GW>их в XML
Хорошо быть богатым и здоровым. Но приходится быть реалистом.
GW>проблема с таким подходом — на С++ практически не реализуется, или с GW>массой ограничений GW>для этого должна быть развитая рефлексивность, как у Java или NET GW>можно конечно идти по пути маппинга в каждом классе — все же это лучше GW>чем на уровне обработки запроса парсить
На практике рефлексия не сильно спасает ибо принцип
loosely coupled когда UI фактически ничего знает ни про naming
convention на сервере ни про структуры данных родился не от хорошей жизни.
>> Согласен. Только если говорить о модульности в software design то >> будет не "включи" а "добавь в проект". >> И это принципиальный подход. Это то что я называю встраиваемостью. GW>ну это не более чем философия, что называть встраиваемостью GW>например мне удобнее шаблоны для WTL использовать, чем ActiveX или dll GW>подключать GW>принимаете такую концепцию встраиваемости — думаю нет, поскольку GW>найдутся умники и выложат ваш продукт где-нибудь на варезном сайте
Ну и включай htmlayout в WTL. Там все для этого есть.
Если надо htmlayout как static lib то тут уже нужна соотв. лицензия/денюжка.
Про варезные сайты пассаж не понял ибо проблема(?) меня не волнует.
>> Если тебе нужен SVG — добавь behavior который реализует SVG рисование. >> "нужны сложные манипуляции" — *добавь в свой проект* XQuery модуль. >> >> Вопросами "как мне включить-выключить то или это в IWebBrowser?" >> забито пол интернета. Ответ в большинстве случаев — а никак — вшито >> насмерть. GW>я же не предлагаю вам все это в один dll файл засунуть — поставляйте GW>отдельные модули, более того даже за отдельные деньги (потому как не GW>всем SVG нужен)
Я и поставляю. htmlayout это одна dll с четко очерченной функцией —
rendering html/css. А SVG можно у Макса Шеманарева попросить
GW>суть в том, что продвигаемый вами подход отличается аскетизмом, но GW>поверьте веб-сервер написанный на постскрипте не воспринимается, как GW>нечто полезное, хотя это принципиально возможно и даже есть реализация
Опять не понял. 90% моих пользователй именно аскетизм и просят: дай нам
нечто для rendering html/css а все омстальное мы сами приделаем / у нас уже есть
/ нам не нужно.
Чего далеко ходить, вот только что письмо пришло:
2) Can your HTML print solutions be used in a window-less (console)
application? We are just intersted in printing the HTML and not viewing it.
>> Делал я попытку импелементировать xforms. >> >> Там больше вопросов чем ответов. xforms в том виде что есть не делает >> и половины того что может javascript. Возникает вопрос — а зачем оно тогда? GW>либо у вас какие-то своеобразные запросы, либо вы не до конца изучили тему
Хочешь я тебя обрадую? ты первый кто за три года проекта спросил про xforms.
Т.е. своеобразие запросов вещь сугубо относительная.
>> Вообще попытка загнать описание процедур в XML смотрится просто >> технически неграмотно. >> Ну не для того XML сделан-то был. GW>загнать описание бизнес-процессов в XML тоже не грамотно? GW>альтернативных варианта было бы два текстовое описание или скажем С++
"описание бизнес-процессов" этого я не понял. Что это за зверь такой?
И почему грамотно его нужно "загнать в XML"?
Это где у нас такую грамоту нынче исповедуют?
>> На самом-то деле и даже для передачи данных JSON (как родной формат >> AJAX) более богатый что-ли и в то же время >> более компактный (на 20%-50%). Во всяком случае в нем есть структуры >> данных: массивы и ассоциативные массивы >> а также атомарные типы данных а не только string. GW>что-то вы не дооцениваете XML, хотя вы правы массивов и списков нет, но GW>есть XML GW>насчет компактности, учитывая поддержку сжатия при передаче данных, мне GW>кажется это уже не вопрос
Ты будешь смеятся но это еще тот вопрос. Почему-то считается что это
передача bandwidth это основная проблема. Передача это одно, а использование
это уже совсем другое. В среднем DOM представление данных в два раза более
прожорливо по памяти чем представление тех же данных в JavaScript объектах или
в C++ структурах.
И вообще у меня есть предложение: если ты или кто-то еще считают
что xforms имеет смысл то можно просто сделать такой коммерческий проект
по типу http://www.formsplayer.com/content/index.html
(Please note that currently formsPlayer and the Sidewinder Web Application Viewer only work in Microsoft's Internet Explorer version 6 SP 1.)
Я помогу чем смогу.
Здравствуйте, Mamut, Вы писали:
M>Как говорится, зачем мучаться, если можно "go to the source"
M>В HTMLayout есть встроенные способы работы с формами или надо все ручками (предполагаю, что ручками, но "а вдруг" )
Если имеется ввиду функциональность броузера (submit/reset) то запланированно на первую половину января.
И в sciter тоже будет в полном объеме — он ближе к броузеру общего назаначения (да он и не компонент собственно — win32 executable)
Здравствуйте, Arioch2, Вы писали:
A>Здравствуйте, Сэма, Вы писали:
С>>2) Кнопки "вперед" "назад" также начинают работать.
A>...кнопки которые нужны раз в неделю, и чем дальше — тем реже. A>Даже Майкрософт наконец допёр до Tabbed Browsing.
Некоторые юзабилисты утверждают, что без кнопки "Взад" клавиша "BckSpace" Жить в браузере нельзя.
Несомненно, если речь идет о толстом приложении, то таких кнопок и ненаблюдается, за исключением всяческих "Мастеров" и "Визардов". Но тут мы имеем дело с уже готовой оболочкой в которой эти кнопки уже есть и убрать их без открытия новых окон посредством JavaScript затруднительно.
Да и пользователь настроен в первую очередь на работу с программой браузером, а не с тем приложением, которое в нем запускается.
Небольшой мой опыт тестирования показывает, что при переходе из одного пункта меню приложения возвращаются в предыдущи пункт чаще кнопкой "назад" или клавишей "bcksps" в более чем половине случаев.
Так что реакцию на эти переходы учитывать надо уже при проектировании.
CS>Что есть "встроенные способы работы с формами"?
CS>Снять/установить данные с/на поля ввода?
CS>dom::element form = root.find_first("#myformid"); CS>set_falues( form, values_collection ); CS>get_falues( form, values_collection );
Здравствуйте, Mamut, Вы писали:
CS>>Что есть "встроенные способы работы с формами"?
CS>>Снять/установить данные с/на поля ввода?
CS>>dom::element form = root.find_first("#myformid"); CS>>set_falues( form, values_collection ); CS>>get_falues( form, values_collection );
M>Ну, это я и имел в виду Пошел копаься дальше
c-smile wrote: > Здравствуйте, GW, Вы писали: > > GW>уже требует неоправданных усилий по введению правил именования > GW>параметров, разбору их по приходу и т.п. > GW>пример из жизни — в одной из форм имена полей на определенном уровне > GW>былы по 80 символов из-за вложенности > Неоправданных усилий?
конечно — разработка от этого быстрее не пойдет
> А лепить в кучу XQuery, XForms c XPath это оправданные усилия? > Без отладчика, сред разработки и прочего?
да с одним браузером — без отладчика, средств разработки и прочего
верстальщик с постановщиком делают макет приложения без того, чтобы
программистов долбать через каждые полчаса, а программисты в это время
пишут реализацию бизнес-логики ориентируясь на объекты и их
взаимодействие, а не на формы, представления, валидаторы и т.п.
> Это ж зоопарк какой-то: > > Например элементарный if > > xquery: > http://www.w3.org/TR/xquery/#id-conditionals
чего-то наверное не понимаю, но мое мнение нормальный синтаксис
if ($widget1/unit-cost < $widget2/unit-cost)
then $widget1
else $widget2
> xpath: > <xsl:if test="@value < 10">...</xsl:if>
положим это не xpath, а xsl
но в целом согласен — мрак
> xforms: > http://www.w3.org/TR/2003/REC-xforms-20031014/slice7.html#fn-if
вполне нормально if(boolean, string, string) в SQL вопросов не возникает
> Мрак какой-то... > GW>можно конечно было поиздеваться над собой и обойтись без повторного > GW>использования кода или какие-то еще действия по согласованию > GW>предпринимать, но сами понимаете оно того не стоит > Не понимаю: что чего не стоит?
уменьшение длины идентификаторов
>> > >> > Как ты собираешься декларативно заполнять C++ структуры? >> > Неважно из чего: из XML или из какой другой коллекции... >> > Конструкций типа >> > >> > MAP_NAMED_VALUE( person.first_name, "person_first_name" ); >> > MAP_NAMED_VALUE( person.last_name, "person_last_name" ); >> > не миновать. > GW>ну как-бы да, но не обязательно > GW>сначала пишем схему, потом по этой схеме генерируем классы, > GW>генератор пишет код за нас > GW>идеально хотелось бы конечно делать наоборот — сначала пишем > GW>классы, а некий движок сам выдупляет как сериализовать/десериализовать > GW>их в XML > Хорошо быть богатым и здоровым. Но приходится быть реалистом.
не без этого
> GW>проблема с таким подходом — на С++ практически не реализуется, или с > GW>массой ограничений > GW>для этого должна быть развитая рефлексивность, как у Java или NET > GW>можно конечно идти по пути маппинга в каждом классе — все же это лучше > GW>чем на уровне обработки запроса парсить > *На практике* рефлексия не сильно спасает ибо принцип > loosely coupled когда UI фактически ничего знает ни про naming > convention на сервере ни про структуры данных родился не от хорошей жизни.
этого не понял
>> > Согласен. Только если говорить о модульности в software design то >> > будет не "включи" а "добавь в проект". >> > И это принципиальный подход. Это то что я называю встраиваемостью. > GW>ну это не более чем философия, что называть встраиваемостью > GW>например мне удобнее шаблоны для WTL использовать, чем ActiveX или dll > GW>подключать > GW>принимаете такую концепцию встраиваемости — думаю нет, поскольку > GW>найдутся умники и выложат ваш продукт где-нибудь на варезном сайте > Ну и включай htmlayout в WTL. Там все для этого есть. > Если надо htmlayout как static lib то тут уже нужна соотв. лицензия/денюжка. > Про варезные сайты пассаж не понял ибо проблема(?) меня не волнует.
ну не суть важно, мое замечание касалось разнообрасности трактовки
встраиваемости
>> > Если тебе нужен SVG — добавь behavior который реализует SVG рисование. >> > "нужны сложные манипуляции" — *добавь в свой проект* XQuery модуль. >> > >> > Вопросами "как мне включить-выключить то или это в IWebBrowser?" >> > забито пол интернета. Ответ в большинстве случаев — а никак — вшито >> > насмерть. > GW>я же не предлагаю вам все это в один dll файл засунуть — поставляйте > GW>отдельные модули, более того даже за отдельные деньги (потому как не > GW>всем SVG нужен) > Я и поставляю. htmlayout это одна dll с четко очерченной функцией — > rendering html/css. А SVG можно у Макса Шеманарева попросить
классно, только вот ваш htmlayout будет не просто состыковать с SVG
> GW>суть в том, что продвигаемый вами подход отличается аскетизмом, но > GW>поверьте веб-сервер написанный на постскрипте не воспринимается, как > GW>нечто полезное, хотя это принципиально возможно и даже есть реализация > Опять не понял. 90% моих пользователй именно аскетизм и просят: дай нам > нечто для rendering html/css а все омстальное мы сами приделаем / у нас > уже есть> / нам не нужно.
вероятно у них есть потребность в рендеринге html/css, но когда речь
идет о технологии тонких клиентов, то есть другие стандарты и
возможности (мое личное мнение более адекватные)
но к сожалению я не видел достойных реализаций
> Чего далеко ходить, вот только что письмо пришло: > 2) Can your HTML print solutions be used in a window-less (console) > application? We are just intersted in printing the HTML and not viewing it.
ну понятно, что им нужно HTML печатать
>> > Делал я попытку импелементировать xforms. >> > Там больше вопросов чем ответов. xforms в том виде что есть не делает >> > и половины того что может javascript. Возникает вопрос — а зачем оно > тогда? > GW>либо у вас какие-то своеобразные запросы, либо вы не до конца изучили > тему > Хочешь я тебя обрадую? ты первый кто за три года проекта спросил про xforms. > Т.е. своеобразие запросов вещь сугубо относительная.
не удивили — пока нет возможности, нет и спроса
допускаю, что не многие и знают о такой технологии
>> > Вообще попытка загнать описание процедур в XML смотрится просто >> > технически неграмотно. >> > Ну не для того XML сделан-то был. > GW>загнать описание бизнес-процессов в XML тоже не грамотно? > GW>альтернативных варианта было бы два текстовое описание или скажем С++ > "описание бизнес-процессов" этого я не понял. Что это за зверь такой? > И почему грамотно его нужно "загнать в XML"?
потому, что единообразные средства обработки
> Это где у нас такую грамоту нынче исповедуют? www.google.com business process definition language
>> > На самом-то деле и даже для передачи данных JSON (как родной формат >> > AJAX) более богатый что-ли и в то же время >> > более компактный (на 20%-50%). Во всяком случае в нем есть структуры >> > данных: массивы и ассоциативные массивы >> > а также атомарные типы данных а не только string. > GW>что-то вы не дооцениваете XML, хотя вы правы массивов и списков нет, но > GW>есть XML > GW>насчет компактности, учитывая поддержку сжатия при передаче данных, мне > GW>кажется это уже не вопрос > > Ты будешь смеятся но это еще тот вопрос. Почему-то считается что это > передача bandwidth это основная проблема. Передача это одно, а > использование это уже совсем другое. В среднем DOM представление данных > в два раза более > прожорливо по памяти чем представление тех же данных в JavaScript > объектах или > в C++ структурах.
буду смеяться, потому как DOM мне как раз и не нужен
в большинстве случаев я пользую SAX для разбора XML и одновременного
формирования структур на С++ или Java
и поэтому мне глубоко плевать на компактность JSON
> И вообще у меня есть предложение: если ты или кто-то еще считают > что xforms имеет смысл то можно просто сделать такой коммерческий проект > по типу http://www.formsplayer.com/content/index.html > (Please note that currently formsPlayer and the Sidewinder Web > Application Viewer only work in Microsoft's Internet Explorer version 6 > SP 1.)
вот их проект мне не нравится, потому как они пытались к Explorer
подвязаться со всеми вытекающими граблями
> Я помогу чем смогу.
хорошо буду иметь в виду
только вот в чем будет ваша помощь выражаться?
Здравствуйте, GW, Вы писали:
>> Это ж зоопарк какой-то: >> >> Например элементарный if >> >> xquery: >> http://www.w3.org/TR/xquery/#id-conditionals GW>чего-то наверное не понимаю, но мое мнение нормальный синтаксис GW>if ($widget1/unit-cost < $widget2/unit-cost) GW> then $widget1 GW> else $widget2
Риторический вопрос: А в выражении
if ($widget1/unit-cost < $widget2/unit-cost)
знак '/' что означает?
Я об этом.
>> xpath: >> <xsl:if test="@value < 10">...</xsl:if> GW>положим это не xpath, а xsl GW>но в целом согласен — мрак
Пример взят из оффициальной спецификации xpath:
NOTE: When an XPath expression occurs in an XML document, any < and <= operators must be quoted according to XML 1.0 rules by using, for example, < and <=. In the following example the value of the test attribute is an XPath expression:
Только это не SQL а VBA который в MS Access можно использовать as-is в SQL.
>> GW>проблема с таким подходом — на С++ практически не реализуется, или с >> GW>массой ограничений >> GW>для этого должна быть развитая рефлексивность, как у Java или NET >> GW>можно конечно идти по пути маппинга в каждом классе — все же это лучше >> GW>чем на уровне обработки запроса парсить >> *На практике* рефлексия не сильно спасает ибо принцип >> loosely coupled когда UI фактически ничего знает ни про naming >> convention на сервере ни про структуры данных родился не от хорошей жизни. GW>этого не понял
>>> > Если тебе нужен SVG — добавь behavior который реализует SVG рисование. >>> > "нужны сложные манипуляции" — *добавь в свой проект* XQuery модуль. >>> > >>> > Вопросами "как мне включить-выключить то или это в IWebBrowser?" >>> > забито пол интернета. Ответ в большинстве случаев — а никак — вшито >>> > насмерть. >> GW>я же не предлагаю вам все это в один dll файл засунуть — поставляйте >> GW>отдельные модули, более того даже за отдельные деньги (потому как не >> GW>всем SVG нужен) >> Я и поставляю. htmlayout это одна dll с четко очерченной функцией — >> rendering html/css. А SVG можно у Макса Шеманарева попросить GW>классно, только вот ваш htmlayout будет не просто состыковать с SVG
Если SVG engine имеет методы load(string) и draw(DC) то не просто
а очень просто (C++):
>> Опять не понял. 90% моих пользователй именно аскетизм и просят: дай нам >> нечто для rendering html/css а все омстальное мы сами приделаем / у нас >> уже есть> / нам не нужно. GW>вероятно у них есть потребность в рендеринге html/css, но когда речь GW>идет о технологии тонких клиентов, то есть другие стандарты и GW>возможности (мое личное мнение более адекватные) GW>но к сожалению я не видел достойных реализаций
По определению тонкий клиент является тонким — т.е. содержит только
те компоненты которые нужны для выполняемой функции.
Например Мозилла не является тонким клиентом. И это также мнение самих разработчиков.
>>> > Делал я попытку импелементировать xforms. >>> > Там больше вопросов чем ответов. xforms в том виде что есть не делает >>> > и половины того что может javascript. Возникает вопрос — а зачем оно >> тогда? >> GW>либо у вас какие-то своеобразные запросы, либо вы не до конца изучили >> тему >> Хочешь я тебя обрадую? ты первый кто за три года проекта спросил про xforms. >> Т.е. своеобразие запросов вещь сугубо относительная. GW>не удивили — пока нет возможности, нет и спроса GW>допускаю, что не многие и знают о такой технологии
Это не технология. Это протокол о намерениях
возникший во времена повальной XML эйфории (первый драфт в 2001 году).
Но как-бы уже народ поостыл к "все в XML".
>>> > Вообще попытка загнать описание процедур в XML смотрится просто >>> > технически неграмотно. >>> > Ну не для того XML сделан-то был. >> GW>загнать описание бизнес-процессов в XML тоже не грамотно? >> GW>альтернативных варианта было бы два текстовое описание или скажем С++ >> "описание бизнес-процессов" этого я не понял. Что это за зверь такой? >> И почему грамотно его нужно "загнать в XML"? GW>потому, что единообразные средства обработки
Это про XPath(с XSL), XQuery и XForms?
Я видел большую единообразность...
>> Это где у нас такую грамоту нынче исповедуют? GW>www.google.com business process definition language
Какой из семи указанных: http://www.ebpml.org/status.htm
имеется ввиду?
>> GW>что-то вы не дооцениваете XML, хотя вы правы массивов и списков нет, но >> GW>есть XML >> GW>насчет компактности, учитывая поддержку сжатия при передаче данных, мне >> GW>кажется это уже не вопрос >> >> Ты будешь смеятся но это еще тот вопрос. Почему-то считается что это >> передача bandwidth это основная проблема. Передача это одно, а >> использование это уже совсем другое. В среднем DOM представление данных >> в два раза более >> прожорливо по памяти чем представление тех же данных в JavaScript >> объектах или >> в C++ структурах. GW>буду смеяться, потому как DOM мне как раз и не нужен GW>в большинстве случаев я пользую SAX для разбора XML и одновременного GW>формирования структур на С++ или Java GW>и поэтому мне глубоко плевать на компактность JSON
ОТ:
Самая эффективная форма разбора XML это так называемые push parsers (или сканеры)
SAX кстати к ним не относится.
Я был публиковал в "Исходниках" такой парсер.
Мне говорили что его тестирование показало скорость сканирования около 30mb в секунду.
Для сравнения парсер tiscript обрабатывает (компилирует и исполняет — инстанциирует объекты — фактически
создает DOM) со скоростью примерно 20 mb в секунду. Только в этом случае мы имеем уже DOM.
>> Я помогу чем смогу. GW>хорошо буду иметь в виду GW>только вот в чем будет ваша помощь выражаться?
А что должно получится в итоге, что есть финальный продукт?
Зная ответ я могу сказать чем конретно я смогу помочь.
c-smile wrote: > Здравствуйте, GW, Вы писали: > >> > Это ж зоопарк какой-то: >> > >> > Например элементарный if >> > >> > xquery: >> > http://www.w3.org/TR/xquery/#id-conditionals > GW>чего-то наверное не понимаю, но мое мнение нормальный синтаксис > GW>if ($widget1/unit-cost < $widget2/unit-cost) > GW> then $widget1 > GW> else $widget2 > > Риторический вопрос: А в выражении > > if ($widget1/unit-cost < $widget2/unit-cost) > знак '/' что означает? > > Я об этом.
разделитель пути, а что плохого
можно наверное было написать $widget1.unit-cost,
как это сделано в предполагаемом стандарте ECMAScript для XML,
но в целом не вижу проблемы и с XPath совместимо
>> > xpath: >> > <xsl:if test="@value < 10">...</xsl:if> > GW>положим это не xpath, а xsl > GW>но в целом согласен — мрак > Пример взят из оффициальной спецификации xpath: > > NOTE: When *an XPath expression *occurs in an XML document, any < and <= > operators must be quoted according to XML 1.0 rules by using, for > example, < and <=. In the following example *the value of the test > attribute is an XPath expression*: > > <xsl:if test="@value < 10">...</xsl:if> > > src: http://www.w3.org/TR/xpath#booleans > > Иммем терминологическую кашу на уровне цпецификации. > Использование таких штук — это уже ближе к гаданию на кофейной гущще....
все это вобщем-то не сложно — не сложно же lt; писать вместо < в html
>> > xforms: >> > http://www.w3.org/TR/2003/REC-xforms-20031014/slice7.html#fn-if > GW>вполне нормально if(boolean, string, string) в SQL вопросов не возникает > Про SQL ты ошибаешься, IF в PL/SQL IF *statement* имеет следующую > /нормальную/ форму: > > IF condition THEN > sequence-of-statements > END IF; > > Ты скорее всего перепутал с функцией > > IIF( logical-expression, expression-true, expression-false ) > Только это не SQL а VBA который в MS Access можно использовать as-is в SQL.
ну вобщем-то о ней, но вроде не только в Access есть такая функция
>> > GW>проблема с таким подходом — на С++ практически не реализуется, или с >> > GW>массой ограничений >> > GW>для этого должна быть развитая рефлексивность, как у Java или NET >> > GW>можно конечно идти по пути маппинга в каждом классе — все же это лучше >> > GW>чем на уровне обработки запроса парсить >> > *На практике* рефлексия не сильно спасает ибо принцип >> > loosely coupled когда UI фактически ничего знает ни про naming >> > convention на сервере ни про структуры данных родился не от хорошей > жизни. > GW>этого не понял > > >> >> > Если тебе нужен SVG — добавь behavior который реализует SVG рисование. >> >> > "нужны сложные манипуляции" — *добавь в свой проект* XQuery модуль. >> >> > >> >> > Вопросами "как мне включить-выключить то или это в IWebBrowser?" >> >> > забито пол интернета. Ответ в большинстве случаев — а никак — вшито >> >> > насмерть. >> > GW>я же не предлагаю вам все это в один dll файл засунуть — поставляйте >> > GW>отдельные модули, более того даже за отдельные деньги (потому как не >> > GW>всем SVG нужен) >> > Я и поставляю. htmlayout это одна dll с четко очерченной функцией — >> > rendering html/css. А SVG можно у Макса Шеманарева попросить > GW>классно, только вот ваш htmlayout будет не просто состыковать с SVG > > Если SVG engine имеет методы load(string) и draw(DC) то не просто > а очень просто (C++): > > class svg: public behavior > { > svg_engine eng; > > void on_attach(element) > { > eng.load( element.get_attribute("src") ); > } > void on_paint(DC, rect, ...) > { > eng.draw(DC, rect); > } > }
SVG не только рендерится, а еще и на события отвечать должен и по ходу
должен перерисовываться, скажем при изменении поля ввода
>> > Опять не понял. 90% моих пользователй именно аскетизм и просят: дай нам >> > нечто для rendering html/css а все омстальное мы сами приделаем / у нас >> > уже есть> / нам не нужно. > GW>вероятно у них есть потребность в рендеринге html/css, но когда речь > GW>идет о технологии тонких клиентов, то есть другие стандарты и > GW>возможности (мое личное мнение более адекватные) > GW>но к сожалению я не видел достойных реализаций > По определению тонкий клиент является тонким — т.е. содержит только > те компоненты которые нужны для выполняемой функции.
мы просто функции видим по разному
> Например Мозилла не является тонким клиентом. И это также мнение самих > разработчиков.
спорить с этим сложно
>> >> > Делал я попытку импелементировать xforms. >> >> > Там больше вопросов чем ответов. xforms в том виде что есть не делает >> >> > и половины того что может javascript. Возникает вопрос — а зачем оно >> > тогда? >> > GW>либо у вас какие-то своеобразные запросы, либо вы не до конца изучили >> > тему >> > Хочешь я тебя обрадую? ты первый кто за три года проекта спросил про > xforms. >> > Т.е. своеобразие запросов вещь сугубо относительная. > GW>не удивили — пока нет возможности, нет и спроса > GW>допускаю, что не многие и знают о такой технологии > Это не технология. Это протокол о намерениях
спецификация
> возникший во времена повальной XML эйфории (первый драфт в 2001 году). > Но как-бы уже народ поостыл к "все в XML".
да как бы не совсем
Mozilla работает над этим, OpenOffice уже выпустил поддержку редактирования
а насчет спецификации, так работают уже над следующим драфтом
>> >> > Вообще попытка загнать описание процедур в XML смотрится просто >> >> > технически неграмотно. >> >> > Ну не для того XML сделан-то был. >> > GW>загнать описание бизнес-процессов в XML тоже не грамотно? >> > GW>альтернативных варианта было бы два текстовое описание или скажем С++ >> > "описание бизнес-процессов" этого я не понял. Что это за зверь такой? >> > И почему грамотно его нужно "загнать в XML"? > GW>потому, что единообразные средства обработки > Это про XPath(с XSL), XQuery и XForms? > Я видел большую единообразность...
нет SAX и DOM
>> > Это где у нас такую грамоту нынче исповедуют? > GW>www.google.com <http://www.google.com> business process definition > language > > Какой из семи указанных: > http://www.ebpml.org/status.htm > имеется ввиду?
любой — суть в том, что большая часть из них XML диалекты
основная причина думаю, в том что работать с ним просто и нет
необходимости создавать инструментарий по парсингу и т.п.
>> > GW>что-то вы не дооцениваете XML, хотя вы правы массивов и списков > нет, но >> > GW>есть XML >> > GW>насчет компактности, учитывая поддержку сжатия при передаче > данных, мне >> > GW>кажется это уже не вопрос >> > >> > Ты будешь смеятся но это еще тот вопрос. Почему-то считается что это >> > передача bandwidth это основная проблема. Передача это одно, а >> > использование это уже совсем другое. В среднем DOM представление данных >> > в два раза более >> > прожорливо по памяти чем представление тех же данных в JavaScript >> > объектах или >> > в C++ структурах. > GW>буду смеяться, потому как DOM мне как раз и не нужен > GW>в большинстве случаев я пользую SAX для разбора XML и одновременного > GW>формирования структур на С++ или Java > GW>и поэтому мне глубоко плевать на компактность JSON > > ОТ: > Самая эффективная форма разбора XML это так называемые push parsers (или > сканеры) > SAX кстати к ним не относится. > Я был публиковал в "Исходниках" такой парсер.
я немного не понимаю терминологию — ссылку дайте
есть bottom-top парсер, который из частей собирает целое вначале лексемы
и т.д. (к ним относится SAX) — предполагаю это push
есть top-bottom парсер, который пытается начинать разбор с целого, а
потом доходит до лексем — предполагаю это pull
> Мне говорили что его тестирование показало скорость сканирования около > 30mb в секунду. > > Для сравнения парсер tiscript обрабатывает (компилирует и исполняет — > инстанциирует объекты — фактически > создает DOM) со скоростью примерно 20 mb в секунду. Только в этом случае > мы имеем уже DOM.
это какие-то абсолютные показатели, которые непонятно с чем сравнить
>> > Я помогу чем смогу. > GW>хорошо буду иметь в виду > GW>только вот в чем будет ваша помощь выражаться? > А что должно получится в итоге, что есть финальный продукт?
модульный браузер семейства XHTML (XHTML, XForms, XML Events, далее
возможно SVG) в том смысле как он изложен в стандарте XHTML, т.е. когда
требуется определенная функциональность подключается (скажем просто
помещается в нужный каталог dll соотвествующего модуля) и результате
получаем новые теги и/или новые атрибуты тегов
аналогично решается с поддержкой протоколов file, HTTP, HTTPS
> Зная ответ я могу сказать чем конретно я смогу помочь.
Здравствуйте, Сэма, Вы писали:
С>Некоторые юзабилисты утверждают, что без кнопки "Взад" клавиша "BckSpace" Жить в браузере нельзя.
И я с ними согласен. Девяностые годы оказались очень неожиданными для специалистов по юзабилити — пока маститые старцы занимались изобретением и внедрением объектно-ориентированных интрерфейсов, пользователи со страшным писком пошли навигироваться.
Надо просто отвлечься от самих кнопок, а думать об идее. В "толстом приложении" подразумевается некоторая модель, с которой мы оперируем. При этом у нас есть два принципиально разных набора операций: один управляет точкой зрения на модель, не изменяя состояние самой модели, а второй управляет моделью.
В веб-приложении первична именно навигация. Мы все время находимся в какой-то точке, и доступны всего две операции — пойти "вперед" по какой-то гиперссылке, либо вернуться назад.
Возможность возврата — принципиальная штука, т.к. она спасает от риска "заблудиться" в вебе.
Смешивание двух идей — штука нетривиальная. В освоении несравненно проще навигационная модель. Но она не очень хорошо подходит для управления чем-либо. Впрочем, начиная со второй половины девяностых (то есть уже десять лет) прогрессивное человечество как раз и занимается исследованиями на тему расширения применения навигационной модели ко всему подряд. В частности, есть Индуктивный Интерфейс (IUI), который противопоставляется слишком сложному и запутанному OOUI, заменяя, где возможно, прямое манипулирование навигацией.
Я не уверен, что он во всех обстоятельствах превосходит остальные концепции. Более того — он совершенно неприменим для многих областей. В частности, этот текст я набираю нажатием кнопок на клавиатуре, а не выполнением многошаговой задачи "Выберите структуру предложения — выберите сказуемое — выберите подлежащее — теперь вы можете ввести дополнения (если не хотите, то всегда сможете вернуться к этому шагу позднее)". И слава байту. Но многие постинги на данном сайте заставляют меня думать о том, что недостаточно опытные пользователи существенно бы выиграли от замены текстбокса таким визардом
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> В частности, этот текст я набираю нажатием кнопок на клавиатуре, а не выполнением многошаговой задачи "Выберите структуру предложения — выберите сказуемое — выберите S> подлежащее — теперь вы можете ввести дополнения (если не хотите, то всегда сможете вернуться к этому шагу позднее)". И слава байту. Но многие постинги на данном сайте S> заставляют меня думать о том, что недостаточно опытные пользователи существенно бы выиграли от замены текстбокса таким визардом
Здравая мысль. Но я думаю это не всегда поможет. Очень часто попадаются вордовские документы, в которых неправильно написаны слова. Видимо MS плохо продумал идеалогию подчеркивания неправильным слов. Надо еще выдавать на максммальной громкости БЛЯМС в колонки
Здравствуйте, sfsoft, Вы писали:
S>Здравая мысль. Но я думаю это не всегда поможет. Очень часто попадаются вордовские документы, в которых неправильно написаны слова. Видимо MS плохо продумал идеалогию подчеркивания неправильным слов. Надо еще выдавать на максммальной громкости БЛЯМС в колонки
Просто модуль проверки грамматики и орфографии не вшит намертво.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
С>>Некоторые юзабилисты утверждают, что без кнопки "Взад" клавиша "BckSpace" Жить в браузере нельзя. S>И я с ними согласен. Девяностые годы оказались очень неожиданными для специалистов по юзабилити — пока маститые старцы занимались изобретением и внедрением объектно-ориентированных интрерфейсов, пользователи со страшным писком пошли навигироваться.
А я не согласен. Кнопкой назад пользуюсь очень редко. Гораздо проще и удобнее открыть несколько интересных окон, а потом закрыть исчерпавшее себя старое. Или свернуть, если пока не уверен. Почему из нескольких возможных продолжений я должен выбрать только одно, а если не угадаю — возвращаться назад ?
Здравствуйте, Arioch2, Вы писали:
A>Здравствуйте, Sinclair, Вы писали:
С>>>Некоторые юзабилисты утверждают, что без кнопки "Взад" клавиша "BckSpace" Жить в браузере нельзя. S>>И я с ними согласен. Девяностые годы оказались очень неожиданными для специалистов по юзабилити — пока маститые старцы занимались изобретением и внедрением объектно-ориентированных интрерфейсов, пользователи со страшным писком пошли навигироваться.
A>А я не согласен. Кнопкой назад пользуюсь очень редко. Гораздо проще и удобнее открыть несколько интересных окон, а потом закрыть исчерпавшее себя старое. Или свернуть, если пока не уверен.
Значит, ты пользуешься альтернативной навигацией. Потому что количество адресов растет экспоненциально с увеличением глубины отслеживания. Навигироваться в паре сотен окон одновременно способны только супермозги с IQ выше 200. A>Почему из нескольких возможных продолжений я должен выбрать только одно, а если не угадаю — возвращаться назад ?
Ты ничего никому не должен. Просто так — удобно.
Вот, кстати, в виндовом эксплорере можно войти в подпапку дабл-кликом. Вернуться назад в родителя можно при помощи кнопки Вверх и кнопки Назад. Большинство пользователей используют все-таки Вверх. Потому, что им так привычнее.
Кстати, режим открытия каждой папки в отдельном окне себя не оправдал — лично я всегда его выключал сразу же, и судя по тому, что в XP он уже выключен по умолчанию, со мной таки согласны большинство пользователей.
В общем, про это можно долго спорить, т.к. вопросы удобства во многом субъективны. Но лишать пользователей кнопки Back под тем предлогом, что "а не надо было закрывать окно, и вообще — всегда навигируйтесь в новое окно/таб" — неэффективно.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
С>>>Некоторые юзабилисты утверждают, что без кнопки "Взад" клавиша "BckSpace" Жить в браузере нельзя. S>>И я с ними согласен. Девяностые годы оказались очень неожиданными для специалистов по юзабилити — пока маститые старцы занимались изобретением и внедрением объектно-ориентированных интрерфейсов, пользователи со страшным писком пошли навигироваться.
A>А я не согласен. Кнопкой назад пользуюсь очень редко. Гораздо проще и удобнее открыть несколько интересных окон, а потом закрыть исчерпавшее себя старое. Или свернуть, если пока не уверен. Почему из нескольких возможных продолжений я должен выбрать только одно, а если не угадаю — возвращаться назад ?
Благодаря Оперным mouse gestures очень активно пользуюсь функцией "назад" (right click+hold — left click). Очень удобно при поиске информации в документации типа такой или такой
1.1.4 stable rev. 510
А вообще я пользуюсь Opera.
