WPF vs HtmlLayout - Продукты TerraInformatica

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

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

A>>>Поизучал. Пришёл к выводу что 90% маркетологии. Грида и того нет. Сырой продукт.
D>>К сожалению Ваши высказывания относительно WPF заставляют усомниться в достаточной глубине изучения данного продукта.

A>ОК, вот раз ты такой умный и высокомерный, покажи мне в WPF полный аналог селекторов CSS (список поддерживаемых HTMLayout: http://www.terrainformatica.com/htmlayout/selectors.whtm) и заодно стандартный (входящий в фреймворк) грид (функциональный аналог DataGridView из WinForms).
1) ПОЛНОГО аналога селекторов CSS в чистом виде нет, оно и не нужно, те-же самые задачи можно решить и немного по другому.
2) Во первых можно использовать DataGridView из WinForms. Во вторых можно использовать ListView у которого задан GridView у которого в свою очередь указаны DataTemplate-ы.

Касательно WPF vs HtmlLayout — оба продукта предназначены для построения кастомизируемого настраивоемого интерфейса. И WPF imho делает это более полноценно и идеологически правильно.

Здравствуйте, adontz, Вы писали:
A>покажи мне в WPF полный аналог селекторов CSS (список поддерживаемых HTMLayout: http://www.terrainformatica.com/htmlayout/selectors.whtm)
Посмотри triggers у style

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

D>1) ПОЛНОГО аналога селекторов CSS в чистом виде нет, оно и не нужно, те-же самые задачи можно решить и немного по другому.

По-другому не хочу, хочу декларативно.

D>2) Во первых можно использовать DataGridView из WinForms. Во вторых можно использовать ListView у которого задан GridView у которого в свою очередь указаны DataTemplate-ы.

Это прышки в сторону, так в HTMLayout тоже можно чужие окна вставлять. Если мы говорим о WPF vs HTMlayout, то вот давай про WPF и говорить. В HTMLayout тоже нет грида, но он и позиционируется по-другому.

D>Касательно WPF vs HtmlLayout — оба продукта предназначены для построения кастомизируемого настраивоемого интерфейса. И WPF imho делает это более полноценно и идеологически правильно.

Не согласен. Мне например очень нравится разделение на HTML файлы в которых я, как программист, задаю просто набор необходимых элементов управления и CSS файлы в которых дизайнер задаёт внешний вид, а так же (оп ля!) другие CSS файлы в которых ещё кто-то задёт локализацию (замену строк и картинок). То есть с точки зрения технологического процесса HTML + CSS это чудесно, а в реализации HTMLayout достаточно неплохо.

К тому же WPF это что-то новое, а на HTMLayout я могу натравить кого-то из дешёвой армии студентов — веб дизайнеров.

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

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

D>>1) ПОЛНОГО аналога селекторов CSS в чистом виде нет, оно и не нужно, те-же самые задачи можно решить и немного по другому.
A>По-другому не хочу, хочу декларативно.
Декларативно — смотри тригеры у стиля, всё это есть только выглядит немного иначе.

D>>2) Во первых можно использовать DataGridView из WinForms. Во вторых можно использовать ListView у которого задан GridView у которого в свою очередь указаны DataTemplate-ы.
A>Это прышки в сторону, так в HTMLayout тоже можно чужие окна вставлять. Если мы говорим о WPF vs HTMlayout, то вот давай про WPF и говорить. В HTMLayout тоже нет грида, но он и позиционируется по-другому.
В конце концов есть внешние компоненты. И вообще DataGridView это неправильный интерфейсный элемент imho

D>>Касательно WPF vs HtmlLayout — оба продукта предназначены для построения кастомизируемого настраивоемого интерфейса. И WPF imho делает это более полноценно и идеологически правильно.
A>Не согласен. Мне например очень нравится разделение на HTML файлы в которых я, как программист, задаю просто набор необходимых элементов управления и CSS файлы в которых дизайнер задаёт внешний вид, а так же (оп ля!) другие CSS файлы в которых ещё кто-то задёт локализацию (замену строк и картинок). То есть с точки зрения технологического процесса HTML + CSS это чудесно, а в реализации HTMLayout достаточно неплохо.
Тебе ничего не мешает использовать такое-же разделение в WPF

Более того, там это сделано ещё более чудесно

A>К тому же WPF это что-то новое, а на HTMLayout я могу натравить кого-то из дешёвой армии студентов — веб дизайнеров.
Ну это сложный вопрос. Пусть сначала красиво отмакетируют

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

D>Собственно сабж в теме. Есть такая мысль что WPF практически похоронил данный проект. Интересно мнение автора.

Насчет похорон конечно рановато, но вопрос интересный.
HTMLayout есть и работает без .NET. Скорее всего (тьфу*3), HTMLayout будет портирована на другие платформы. О портировании Avalon на MacOS или Linux речь как я понимаю не идет и в ближайшее время идти не будет.
А что WPF предлагает на смену стилям? Там существует четкое разделение кода между кодом для стилизации и представлением? Насколько шустро работают приложения?

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

D>Собственно сабж в теме. Есть такая мысль что WPF практически похоронил данный проект. Интересно мнение автора.

Не люблю я сравнения солнца и луны — и то и то в небе, но собственно это и все что у них общего. Ну да ладно.
К слову сказать была такая мулечка что WPF это могильщик HTML и CSS. Но пока не видно. На динамику создания новых сайтов WPF не оказал никакого влияния. Я не заметил каких бы то ни было изменений в динамике продаж htmlayout с выходом WPF. Скорее наоборот — больше стало продаваться но это отдельная история.

WPF по своему масштабу это имплементация некоего глобального принципа.
htmlayout, он проще — просто встраиваемый html/css движок. Не больше и не меньше. Может использоваться за для показать фрагмент HTML где-то так и для полного skinned UI.

Т.е. все что имеет смысл сравнвать это XAML vs HTML/CSS.... и то мне почему-то кажется что "XAML это такой SVG но без CSS".

Начну с того что XAML это не HTML. HTML более это семантически более высокоуровневый язык. XAML как я уже говорил это по сути своей FRM фомат из VB переформулированный в XML (имхо)

Стили... у XAML'а своя собственная и просто другая, несравнимая с CSS система стилей.

Это вот:

<Style x:Key="ButtonStyle">
   <Setter Property="Button.Background" Value="BlueViolet" />
   <Setter Property="Button.FontSize" Value="20" />
   <Setter Property="Button.Width" Value="200" />
   <Setter Property="Button.Height" Value="30" />
</Style>

ну просто далеко не

.ButtonStyle
{
  background:BlueViolet;
  font-size:20px; 
  width:200px; 
  height:200px; 
}

Понятия какскадинга у <Style> нет в принципе. Есть наследование но это абсолютно не то. В XAML single inheritance, а в CSS очень гибкая система multiple, selector based inheritance. В htmlayout еще больше — там есть style sets которые делают inheritance груп стилей для поддеревьев DOM.

Ну короче WPF::Style и CSS::style это небо и земля. CSS::style это мощная и гибкая коцепция. WPF::Style это просто ассоциативная таблица именнованных свойств (которую еще больше губит XML формат).

<Style TargetType="{x:Type Control}>

Это далеко не CSS селектор. Причем очень далеко не. Triggers перекрывают только CSS pseudo classes. Но и только.

Скажем вот такую вот простую конструкцию

  select > option:current { background:threedface; color: windowtext; }
  select:focus > option:current { background:highlight; color: highlighttext; }

Я не знаю как воспроизвести в XAML. Буду признателен если мне знатоки покажут как.

Ну и напоследок.

WPF это managed code. Т.е. не везде, не для всего и не на всех Windows версиях работает. htmlayout это native code, может работать как в managed средах .NET и Java (кстати) так и в сугубо нативных приложениях.

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

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

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

D>>>1) ПОЛНОГО аналога селекторов CSS в чистом виде нет, оно и не нужно, те-же самые задачи можно решить и немного по другому.
A>>По-другому не хочу, хочу декларативно.
D>Декларативно — смотри тригеры у стиля, всё это есть только выглядит немного иначе.

Мне кажется ты не до конца понимаешь концепцию либо CSS::selector либо WPF::trigger. Скорее первое ибо WPF::trigger это сугубо CSS pseudo class

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

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

D>>Собственно сабж в теме. Есть такая мысль что WPF практически похоронил данный проект. Интересно мнение автора.

CS>Не люблю я сравнения солнца и луны — и то и то в небе, но собственно это и все что у них общего. Ну да ладно.
CS>К слову сказать была такая мулечка что WPF это могильщик HTML и CSS. Но пока не видно. На динамику создания новых сайтов WPF не оказал никакого влияния. Я не заметил каких бы то ни было изменений в динамике продаж htmlayout с выходом WPF. Скорее наоборот — больше стало продаваться но это отдельная история.
Ну WPF-сайты это отдельная история. я всё-таки говорю о WPF-приложениях.

CS>WPF по своему масштабу это имплементация некоего глобального принципа.
Да! Причём XAML это лишь часть WPF. WPF по своей сути это что-то вроде сверхнавороченного Swing-а а XAML это просто некоторый формат для сериализации/десериализации (причём ПРОИЗВОЛЬНЫХ объектов)
CS>htmlayout, он проще — просто встраиваемый html/css движок. Не больше и не меньше. Может использоваться за для показать фрагмент HTML где-то так и для полного skinned UI.

CS>Стили... у XAML'а своя собственная и просто другая, несравнимая с CSS система стилей.

CS>Это вот:
CS>

CS><Style x:Key="ButtonStyle">
CS>   <Setter Property="Button.Background" Value="BlueViolet" />
CS>   <Setter Property="Button.FontSize" Value="20" />
CS>   <Setter Property="Button.Width" Value="200" />
CS>   <Setter Property="Button.Height" Value="30" />
CS></Style>
CS>

CS>ну просто далеко не
CS>

CS>.ButtonStyle
CS>{
CS>  background:BlueViolet;
CS>  font-size:20px; 
CS>  width:200px; 
CS>  height:200px; 
CS>}
CS>

CS>Понятия какскадинга у <Style> нет в принципе. Есть наследование но это абсолютно не то. В XAML single inheritance, а в CSS очень гибкая система multiple, selector based inheritance. В htmlayout еще больше — там есть style sets которые делают inheritance груп стилей для поддеревьев DOM.

CS>Ну короче WPF::Style и CSS::style это небо и земля. CSS::style это мощная и гибкая коцепция. WPF::Style это просто ассоциативная таблица именнованных свойств (которую еще больше губит XML формат).

CS>

CS><Style TargetType="{x:Type Control}> 
CS>

CS>Это далеко не CSS селектор. Причем очень далеко не. Triggers перекрывают только CSS pseudo classes. Но и только.

CS>Скажем вот такую вот простую конструкцию

CS>

CS>  select > option:current { background:threedface; color: windowtext; }
CS>  select:focus > option:current { background:highlight; color: highlighttext; }
CS>

CS>Я не знаю как воспроизвести в XAML. Буду признателен если мне знатоки покажут как.
Ну конкретно для этого примера. Сочетанию SELECT + OPTION в WPF наверно соответствует какой-нить потомок ItemControl и набор его Item-ов.
У ItemControl есть 2 свойства — Style и ItemStyle — вот они эти стили. Причём свойство ItemStyle можно установить ИЗ свойства Style (через стиль можно установить практически ЛЮБОЕ свойство в отличии от HTML). А :focus и :current разруливаются триггерами. Я ответил на ваш вопрос?

CS>Ну и напоследок.

CS>WPF это managed code. Т.е. не везде, не для всего и не на всех Windows версиях работает. htmlayout это native code, может работать как в managed средах .NET и Java (кстати) так и в сугубо нативных приложениях.
ИМХО наступает время managed code!

Здравствуйте, ShaggyOwl, Вы писали:
SO>Насчет похорон конечно рановато, но вопрос интересный.
SO>HTMLayout есть и работает без .NET. Скорее всего (тьфу*3), HTMLayout будет портирована на другие платформы. О портировании Avalon на MacOS или Linux речь как я понимаю не идет и в ближайшее время идти не будет.
Идёт, вроде в Mono планируют. Silverlight (образок WPF для WWW) уже есть

Всё дело в архитектуре WPF, это НЕ надстройка над Win32 API, это очень близко к Swing, поэтому никаких проблем портация не вызовет.

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

Маркетологчсеки.

Очень хочется HTMLayout для .Net (2.0) — т.е. без Native C++. Если этого не будет, то WPF — победит (когда не будет W2k/win9x)

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

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

A>Маркетологчсеки.

A>Очень хочется HTMLayout для .Net (2.0) — т.е. без Native C++. Если этого не будет, то WPF — победит (когда не будет W2k/win9x)

Скорее всего не получится, в своё время c-smile подробно описывал почему (проблемы с производительностью). Хотя WPF работает (хотя и не "летает").

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

Маркетологчсеки. Продолжая.

HTMLayout для .Net (2.0) — гараздо важнее чем HTMLayout для Linux/MacOC/(и какие там ОС популярны у марсиан?)

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

>> проблемы с производительностью

Этии проблемы беспокоили в 90-х годах и пользователей Windows 3.1. Корпорация Intel к настоящему времени их их решила.

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

D>Скорее всего не получится../
у кого, у WPF?

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

A>Маркетологчсеки.
A>Очень хочется HTMLayout для .Net (2.0) — т.е. без Native C++. Если этого не будет, то WPF — победит (когда не будет W2k/win9x)

А вы не боитесь использовать класс FileStream, а то он к native filesystem driver обращается, который небось аж на Си написан?

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

D>Сочетанию SELECT + OPTION в WPF наверно соответствует какой-нить потомок ItemControl и набор его Item-ов.

Тут суть в том, что CSS поддерживает любые сочетания, а не только заранее предопределённые.

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

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

D>>Сочетанию SELECT + OPTION в WPF наверно соответствует какой-нить потомок ItemControl и набор его Item-ов.

A>Тут суть в том, что CSS поддерживает любые сочетания, а не только заранее предопределённые.

Суть в том что CSS тоже далеко не любые поддерживает. По существу с примером из жизни возразить можете?

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

D>Суть в том что CSS тоже далеко не любые поддерживает. По существу с примером из жизни возразить можете?

Да запросто: 'div > span[id~='45'] > h1:nth-child(5n+4) b' что означает

все <b> являющиеся прямыми или косвенными детьми h1 среди
всех <h1> являющихся прямыми детьми с индексом, дающим при делении на пять четыре, span, с атрибутом id содержащим разделённые пробелами значения одно из которых '45' среди
всех div

Покажи мне это в WPF.

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

CS>>WPF по своему масштабу это имплементация некоего глобального принципа.
D>Да! Причём XAML это лишь часть WPF. WPF по своей сути это что-то вроде сверхнавороченного Swing-а а XAML это просто некоторый формат для сериализации/десериализации (причём ПРОИЗВОЛЬНЫХ объектов)

Да ты наверное прав, WPF это такой Swing.
Тогда тем более почему он "могильщик" htmlayout?

CS>>Скажем вот такую вот простую конструкцию

CS>>

CS>>  select > option:current { background:threedface; color: windowtext; }
CS>>  select:focus > option:current { background:highlight; color: highlighttext; }
CS>>

CS>>Я не знаю как воспроизвести в XAML. Буду признателен если мне знатоки покажут как.
D>Ну конкретно для этого примера. Сочетанию SELECT + OPTION в WPF наверно соответствует какой-нить потомок ItemControl и набор его Item-ов.
D>У ItemControl есть 2 свойства — Style и ItemStyle — вот они эти стили. Причём свойство ItemStyle можно установить ИЗ свойства Style (через стиль можно установить практически ЛЮБОЕ свойство в отличии от HTML). А :focus и :current разруливаются триггерами. Я ответил на ваш вопрос?

Нет, ты не ответил на вопрос.

Как описать на XAML "если select в фокусе то его непосредственный child-option в состоянии current имеет стиль B".
Подозреваю что никак. В общем это риторический вопрос.

XAML он для редактирвания в WYSIWYG средах разработки сделан (Microsoft® Expression®).
Отсюда его специфика — только простые и плоские конструкции. Это фактически inline styles в html/css, во всяком случае изначально.

CS>>Ну и напоследок.

CS>>WPF это managed code. Т.е. не везде, не для всего и не на всех Windows версиях работает. htmlayout это native code, может работать как в managed средах .NET и Java (кстати) так и в сугубо нативных приложениях.

D>ИМХО наступает время managed code!
Тебя обманули. WPF core это native code. Про Vista говорили тоже что она вся managed будет.
И вообще про "наступает время managed code" — в "священные войны".

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

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

A>Маркетологчсеки.

A>Очень хочется HTMLayout для .Net (2.0) — т.е. без Native C++. Если этого не будет, то WPF — победит (когда не будет W2k/win9x)

Еще раз. WPF core (например XAML renderer) написан в native code.
htmlayout это в принципе renderer того же уровня — просто другой входной язык и структура DOM.

Говорить "хочу все managed" это безграмотно технически.
"Хочу все компоненты в технологиях оптимальных для их исполнения" — это уже ближе к теме.

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

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

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

A>>Маркетологчсеки.

A>>Очень хочется HTMLayout для .Net (2.0) — т.е. без Native C++. Если этого не будет, то WPF — победит (когда не будет W2k/win9x)

CS>Еще раз. WPF core (например XAML renderer) написан в native code.
CS>htmlayout это в принципе renderer того же уровня — просто другой входной язык и структура DOM.

Меня наверное не совсем поняли. Под "без Native C++" я имел в виду, "без использования Native C++ для прикручивания HTMLayout к приложению", т.е. сейчас загрузив SDK с сайта terrainformatica.com я не могу сразу использовать HTMLayout в приложении, написанном на C#/VB.Net. Я знаю, что есть обертки (NABU Library) от сторонних поставщиков. Но:


> Почему в компоненте HtmlView не работают некоторые behavior'ы, которые 
> есть в HTMLayout? Например, expandable-list, collapsible-list. Нельзя 
> ли делегировать эти behavior'ы самой htmlayout.dll ? 


Не работают, потому что их нет в HTMLayout. Они распространяются в 
виде Си++ кода (файлы расположены в папке \include\behaviors\), 
который должен быть подключён к проекту. К .Net проекту его, 
естественно, подключить нельзя. 

На данный момент в обёртке есть аналоги для 
behavior_accesskeys.cpp 
behavior_collapsible_by_icon.cpp 
behavior_hyperlink.cpp 
behavior_tabs.cpp

Это как раз о том "Native C++", о котором я говорил.

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

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

CS>>>WPF по своему масштабу это имплементация некоего глобального принципа.
D>>Да! Причём XAML это лишь часть WPF. WPF по своей сути это что-то вроде сверхнавороченного Swing-а а XAML это просто некоторый формат для сериализации/десериализации (причём ПРОИЗВОЛЬНЫХ объектов)

CS>Да ты наверное прав, WPF это такой Swing.
CS>Тогда тем более почему он "могильщик" htmlayout?
Потому что одной из его фич является возможность декларативного задания UI. Именно эта фича — причина использования HtmlLayout в 80% случаев. разве нет.

CS>>>Скажем вот такую вот простую конструкцию

CS>>>

CS>>>  select > option:current { background:threedface; color: windowtext; }
CS>>>  select:focus > option:current { background:highlight; color: highlighttext; }
CS>>>

CS>>>Я не знаю как воспроизвести в XAML. Буду признателен если мне знатоки покажут как.
D>>Ну конкретно для этого примера. Сочетанию SELECT + OPTION в WPF наверно соответствует какой-нить потомок ItemControl и набор его Item-ов.
D>>У ItemControl есть 2 свойства — Style и ItemStyle — вот они эти стили. Причём свойство ItemStyle можно установить ИЗ свойства Style (через стиль можно установить практически ЛЮБОЕ свойство в отличии от HTML). А :focus и :current разруливаются триггерами. Я ответил на ваш вопрос?

CS>Нет, ты не ответил на вопрос.

CS>Как описать на XAML "если select в фокусе то его непосредственный child-option в состоянии current имеет стиль B".
CS>Подозреваю что никак. В общем это риторический вопрос.
повторяю ещё раз — в WPF нету элемента SELECT поэтому никак

если говорить про ItemControl то надо объявить 2 стиля:
1) стиль для элемента (внутреннего элемента) когда ItemControl в фокусе. через тригера разрулить отмеченный/не отмеченный
2) стиль для самого ItemControl-а в котором с помощью триггера при установке свойства Focused устанавливать значение ItemStyle в стиль, определённый в 1)

Теперь понятно???

CS>XAML он для редактирвания в WYSIWYG средах разработки сделан (Microsoft® Expression®).
CS>Отсюда его специфика — только простые и плоские конструкции. Это фактически inline styles в html/css, во всяком случае изначально.
Не совсем. Повтрюсь — XAML это по большому счёту формат сериализации данных. Он десериализируется XAMLReader-ом и в результате имеем готовое дерево. Добавляем новый класс (непример потомок контрола) в код, используем тег в XAML и наш класс точно так-же поднимется в дереве равно как и стандартные.

CS>>>Ну и напоследок.
CS>>>WPF это managed code. Т.е. не везде, не для всего и не на всех Windows версиях работает. htmlayout это native code, может работать как в managed средах .NET и Java (кстати) так и в сугубо нативных приложениях.
D>>ИМХО наступает время managed code!
CS>Тебя обманули. WPF core это native code. Про Vista говорили тоже что она вся managed будет.
Не совсем. Там очень маленький фрагмент для оптимизации + при установке для оптимизации происходит обработка через ngen всех managed-сборок.

CS>И вообще про "наступает время managed code" — в "священные войны".
Насчёт войн — спорить не буду но рекомендую посмотреть статистику по СЕРЬЁЗНЫМ проектам уровня предприятия. Все сервера приложений — 90% либо J2EE либо .NET. Бизнес-код в основном пишут на Managed. Тот же самый 1С — там тоже Managed.

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

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

D>>Суть в том что CSS тоже далеко не любые поддерживает. По существу с примером из жизни возразить можете?

A>Да запросто: 'div > span[id~='45'] > h1:nth-child(5n+4) b' что означает

A>все <b> являющиеся прямыми или косвенными детьми h1 среди
A>всех <h1> являющихся прямыми детьми с индексом, дающим при делении на пять четыре, span, с атрибутом id содержащим разделённые пробелами значения одно из которых '45' среди
A>всех div

A>Покажи мне это в WPF.

Это не ЖИЗНЕННЫЙ и сугубо синтетический пример. Покажи мне его use-case в первую очередь.

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

A>Это как раз о том "Native C++", о котором я говорил.

Как автор NABU Library могу сказать следующее. Библиотека поддерживает написание behavior на чистом .Net. То есть при желании, владея C#/VB.Net можно прикрутить всё что угодно.
Полезные behaviors на C# написанные не мной включаются в библиотеку без особой волокиты, есть прецеденты. То есть я, конечно,н е отрицаю что часть функциональности из SDK отсутствует, но вот чтобы её восполнить Си++ не нужен совсем. Нужен С# и некоторое желание.

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

A>>Да запросто: 'div > span[id~='45'] > h1:nth-child(5n+4) b' что означает

A>>все <b> являющиеся прямыми или косвенными детьми h1 среди
A>>всех <h1> являющихся прямыми детьми с индексом, дающим при делении на пять четыре, span, с атрибутом id содержащим разделённые пробелами значения одно из которых '45' среди
A>>всех div

A>>Покажи мне это в WPF.

D>Это не ЖИЗНЕННЫЙ и сугубо синтетический пример. Покажи мне его use-case в первую очередь.

А это уже прыжок в сторону

use-case могу привести без проблем. Скажем у меня есть таблица (a.k.a. GridView) в которой пользователи. В HTML таблица одна, но считай стили построены так как будто таблиц много разных.

<html>
    <head>
        <style>
            table[id='users']
            {
                background-color: azure;
            }
            
            table[id='users'] > tr > td
            {
                padding: 0.5em;
                border: solid 2px blue;
            }
            
            table[id='users'] > tr > td:nth-child(1)
            {
                padding: 0px;
            }
            
            table[id='users'] > tr[access-rights~='write'] > td
            {
                border: solid 2px red;
            }
            
            table[id='users'] > tr[access-rights~='backup'] > td
            {
                border: solid 2px orange;
            }
            
            table[id='users'] > tr[access-rights~='write'] > td:nth-child(1) > div
            {
                foreground-image: url(http://www.rsdn.ru/images/tree/frs.gif);
                width: 32px;
                height: 16px;
            }
            
        </style>
    </head>
    <body>
        <table id='users'>
            <tr access-rights='read write'>
                <td><div></div></td><td>Admin</td><td>System Administrator</td>
            </tr>
            <tr access-rights='read'>
                <td><div></div></td><td>User</td><td>User</td>
            </tr>
            <tr access-rights='read backup'>
                <td><div></div></td><td>Backup Operator</td><td>Backup operator</td>
            </tr>
        </table>
    </body>
</html>

А если я ещё хочу её при печати по-другому раскрасить... то мне поможет такая фича CSS как @media. Пишу

@media print
{
}

и указываю внутри альтернативные стили. Могу создавать произвольные новые media и указывать их имена, скажем могу сделать @media hi-contrast и переключать рендеринг без перезагрузки HTML.
Вообще много чего могу...
Могу указывать @media russian и

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

CS>>Да ты наверное прав, WPF это такой Swing.
CS>>Тогда тем более почему он "могильщик" htmlayout?
D>Потому что одной из его фич является возможность декларативного задания UI. Именно эта фича — причина использования HtmlLayout в 80% случаев. разве нет.

"декларативный UI" это одна из фич. Для кого-то основная для кого-то нет.
Я знаю что одна уважаемая фирма например активно совмещает декларативность с динамической генерацией UI — нечто типа внутреннего CGI.

CS>>Как описать на XAML "если select в фокусе то его непосредственный child-option в состоянии current имеет стиль B".
CS>>Подозреваю что никак. В общем это риторический вопрос.
D>повторяю ещё раз — в WPF нету элемента SELECT поэтому никак

если говорить про ItemControl то надо объявить 2 стиля:
D>1) стиль для элемента (внутреннего элемента) когда ItemControl в фокусе. через тригера разрулить отмеченный/не отмеченный
D>2) стиль для самого ItemControl-а в котором с помощью триггера при установке свойства Focused устанавливать значение ItemStyle в стиль, определённый в 1)

D>Теперь понятно???

Нет не понятно.

Нет там select но есть listbox. Вот для него и его items можешь привести пример на XAML?
Если не получится для listbox то для любого другого элемента, т.е.

как в XAML стилях и тригерах выглядит следующее:
"если элемент X в фокусе то его непосредственный child типа Y в состоянии current имеет стиль S"

CS>>И вообще про "наступает время managed code" — в "священные войны".
D>Насчёт войн — спорить не буду но рекомендую посмотреть статистику по СЕРЬЁЗНЫМ проектам уровня предприятия. Все сервера приложений — 90% либо J2EE либо .NET. Бизнес-код в основном пишут на Managed. Тот же самый 1С — там тоже Managed.

Всегда готов! Давай ссылку на статистику.

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

D> Тот же самый 1С — там тоже Managed.

Это бред и дезинформация! Никакого .Net атм нет! Там Си++ и СОМ!!!!

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

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

A>>Это как раз о том "Native C++", о котором я говорил.

A>Как автор NABU Library могу сказать следующее. Библиотека поддерживает написание behavior на чистом .Net. То есть при желании, владея C#/VB.Net можно прикрутить всё что угодно.
A>Полезные behaviors на C# написанные не мной включаются в библиотеку без особой волокиты, есть прецеденты. То есть я, конечно,н е отрицаю что часть функциональности из SDK отсутствует, но вот чтобы её восполнить Си++ не нужен совсем. Нужен С# и некоторое желание.

Роман, может имеет смысл завернуть все behaviors в отдельную native dll c внешней функцией CreateBehavior() и звать ея из managed в HLN_ATTACH_BEHAVIOR?

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

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

D>> Тот же самый 1С — там тоже Managed.

A>Это бред и дезинформация! Никакого .Net атм нет! Там Си++ и СОМ!!!!

Уважаемый, вы не совсем правы. Я имел ввиду что прикладной код, разрабатываемый прикладными программистами компилируется в байт-код и исполняется виртуальной машиной. Да, это ну Java-байткод и не MSIL, но тем не менее это байткод и виртуальная машина. Для простоты я называю сочетание "байткод + VM" — managed, по сути то одно и то-же

Ну и вспоминаем всякие PHP, Perl и.т.п. Там вроде тоже идёт речь о переводе новых версий на VM

В таком ключе со мной согласны что managed наступает по всем фронтам?

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

CS>Нет там select но есть listbox. Вот для него и его items можешь привести пример на XAML?
CS>Если не получится для listbox то для любого другого элемента, т.е.

CS>как в XAML стилях и тригерах выглядит следующее:
CS>"если элемент X в фокусе то его непосредственный child типа Y в состоянии current имеет стиль S"

Ну например вот. Значение ItemContainerStyle при желании можно присваивать через Style ListBox-а

<Window 
    SizeToContent="WidthAndHeight" 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:sys="clr-namespace:System;assembly=mscorlib" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" >
  <StackPanel>
        <ListBox>
            <ListBox.ItemContainerStyle>
                <Style>
                    <Style.Triggers>
                        <MultiTrigger>
                            <MultiTrigger.Conditions>
                                <Condition Property="Selector.IsSelected">
                                    <Condition.Value>
                                        <sys:Boolean>True</sys:Boolean>
                                    </Condition.Value>
                                </Condition>
                                <Condition Property="Selector.IsSelectionActive">
                                    <Condition.Value>
                                        <sys:Boolean>True</sys:Boolean>
                                    </Condition.Value>
                                </Condition>
                            </MultiTrigger.Conditions>
                            <Setter Property="Control.FontSize" Value="50" />
                        </MultiTrigger>
                    </Style.Triggers>
                </Style>
            </ListBox.ItemContainerStyle>
            <ListBoxItem>foo1</ListBoxItem>
            <ListBoxItem>bar1</ListBoxItem>
            <ListBoxItem>foo2</ListBoxItem>
            <ListBoxItem>bar2</ListBoxItem>
        </ListBox>
        <Button>Some Button</Button>
    </StackPanel>
</Window>

X:focus > Y:current 
{ 
    Style 
}

D><Window 
D>    SizeToContent="WidthAndHeight" 
D>    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
D>    xmlns:sys="clr-namespace:System;assembly=mscorlib" 
D>    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" >
D>  <StackPanel>
D>        <ListBox>
D>            <ListBox.ItemContainerStyle>
D>                <Style>
D>                    <Style.Triggers>
D>                        <MultiTrigger>
D>                            <MultiTrigger.Conditions>
D>                                <Condition Property="Selector.IsSelected">
D>                                    <Condition.Value>
D>                                        <sys:Boolean>True</sys:Boolean>
D>                                    </Condition.Value>
D>                                </Condition>
D>                                <Condition Property="Selector.IsSelectionActive">
D>                                    <Condition.Value>
D>                                        <sys:Boolean>True</sys:Boolean>
D>                                    </Condition.Value>
D>                                </Condition>
D>                            </MultiTrigger.Conditions>
D>                            <Setter Property="Control.FontSize" Value="50" />
D>                        </MultiTrigger>
D>                    </Style.Triggers>
D>                </Style>
D>            </ListBox.ItemContainerStyle>
D>            <ListBoxItem>foo1</ListBoxItem>
D>            <ListBoxItem>bar1</ListBoxItem>
D>            <ListBoxItem>foo2</ListBoxItem>
D>            <ListBoxItem>bar2</ListBoxItem>
D>        </ListBox>
D>        <Button>Some Button</Button>
D>    </StackPanel>
D></Window>
D>

Мама, роди меня обратно...
Если стили задаются такими чудовищными костылями, WPF совсем не могильщик HTMLayout. А вот наоборот, вполне может быть

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

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

A>А это уже прыжок в сторону

A><html>
A>    <head>
A>        <style>
A>            table[id='users']
A>            {
A>                background-color: azure;
A>            }
            
A>            table[id='users'] > tr > td
A>            {
A>                padding: 0.5em;
A>                border: solid 2px blue;
A>            }
            
A>            table[id='users'] > tr > td:nth-child(1)
A>            {
A>                padding: 0px;
A>            }
            
A>            table[id='users'] > tr[access-rights~='write'] > td
A>            {
A>                border: solid 2px red;
A>            }
            
A>            table[id='users'] > tr[access-rights~='backup'] > td
A>            {
A>                border: solid 2px orange;
A>            }
            
A>            table[id='users'] > tr[access-rights~='write'] > td:nth-child(1) > div
A>            {
A>                foreground-image: url(http://www.rsdn.ru/images/tree/frs.gif);
A>                width: 32px;
A>                height: 16px;
A>            }
            
A>        </style>
A>    </head>
A>    <body>
A>        <table id='users'>
A>            <tr access-rights='read write'>
A>                <td><div></div></td><td>Admin</td><td>System Administrator</td>
A>            </tr>
A>            <tr access-rights='read'>
A>                <td><div></div></td><td>User</td><td>User</td>
A>            </tr>
A>            <tr access-rights='read backup'>
A>                <td><div></div></td><td>Backup Operator</td><td>Backup operator</td>
A>            </tr>
A>        </table>
A>    </body>
A></html>
A>

Ок, понял, всё решается через стили и темплейты с тригерами. Единственное что необходимо это для обработки конструкции ~= придётся написать свою реализацию IConverter.

A>А если я ещё хочу её при печати по-другому раскрасить... то мне поможет такая фича CSS как @media. Пишу
A>

A>@media print
A>{
A>}
A>

A>и указываю внутри альтернативные стили. Могу создавать произвольные новые media и указывать их имена, скажем могу сделать @media hi-contrast и переключать рендеринг без перезагрузки HTML.
A>Вообще много чего могу...
Всё это решается через динамические ресурсы и/или Binding

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

[]

D>Ок, понял, всё решается через стили и темплейты с тригерами. Единственное что необходимо это для обработки конструкции ~= придётся написать свою реализацию IConverter.

Ага, а для еще каких-нибудь конструкций "придется написать свою реализацию IXXX"

Мсье, как вижу, знает и понимает толк в извращениях

A>>А если я ещё хочу её при печати по-другому раскрасить... то мне поможет такая фича CSS как @media. Пишу
A>>

A>>@media print
A>>{
A>>}
A>>

A>>и указываю внутри альтернативные стили. Могу создавать произвольные новые media и указывать их имена, скажем могу сделать @media hi-contrast и переключать рендеринг без перезагрузки HTML.
A>>Вообще много чего могу...

D>Всё это решается через динамические ресурсы и/или Binding

Угу, на свете вообще все решается. Только кое-что решается через пляски с бубнами

Вместо того, чтобы юзать нормальный HTMLayout, вы упорно указываете на какую-то полусырую каку, уж извините. А когда вам приводят примеры того, с чем кака справиться не может — быстренько отваливаете в сторону

З.Ы. Вот только не надо кричать, что "кака с этим не справляется, потому что это концептуально неправильно" и пр. Deal?

<< Рабство не отменено — оно сменилось 8-часовым рабочим днем. >>

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

CS>>как в XAML стилях и тригерах выглядит следующее:
CS>>"если элемент X в фокусе то его непосредственный child типа Y в состоянии current имеет стиль S"

D>Ну например вот. Значение ItemContainerStyle при желании можно присваивать через Style ListBox-а

[код поскипан]

Вах, мля! Нет, не так. ВАХ, МЛЯЯЯЯ! Это что вообще было? Страшное у@$ище лесное сами_знаете_что — вот что это было. Вполне в духе одной уважаемой фирмы — решать простые задачи через жопу.

Налицо торжество индусского подхода

<< Если гора идет к тебе, спасайся: это обвал. >>

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

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

CS>>>как в XAML стилях и тригерах выглядит следующее:
CS>>>"если элемент X в фокусе то его непосредственный child типа Y в состоянии current имеет стиль S"

SO>HTMLayout
SO>

SO>X:focus > Y:current 
SO>{ 
SO>    Style 
SO>}
SO>

SO>Мама, роди меня обратно...
SO>Если стили задаются такими чудовищными костылями, WPF совсем не могильщик HTMLayout. А вот наоборот, вполне может быть

Ну во первых не надо так драматично. Во первых вы взяли полный пример на WPF (там не только стиль но и всё остальное) и сравниваете его с абстрактным фрагментом CSS. Во вторых у меня складывается устойчивое впечатление что вы всё-таки до конца не осознаёте основную разницу между XAML и HTML+CSS.
HTML+CSS это язык разметки документов а XAML это язык сериализации объектов. Сам по себе XAMLReader очень прост, по сути конструкция вида

<Window 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" >
    <Button>foo</Button>
</Window>

это ничто иное как альтернативная запись кода

Window w = new Window();
Button b = new Button();
b.Content="foo";
w.Content=b;
return w;

т.е. XAML это средство хранения графа объектов. Если к примеру мы напишем свой класс

namespace My.Namespace
{
    public class MyClass
    {
        public string SomeStringProperty{get;set;}
    }
}

то мы можем в XAML написать

<a:MyClass
    xmlns:a="clr-namespace:My.Namespace"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" >
    <a:MyClass.SomeStringProperty>foo</a:MyClass.SomeStringProperty>
</a:MyClass>

Т.е. в XAML можно использовать не только классы из WPF. Кроме того, как показано выше, никто не заставляет использовать XAML для WPF. При желании никто не мешает написать свой псевдо-HTML + псевдо-CSS-парсер, который будет при парсинге создавать и настраивать соответствующие WPF-классы.

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

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

F>[]

D>>Ок, понял, всё решается через стили и темплейты с тригерами. Единственное что необходимо это для обработки конструкции ~= придётся написать свою реализацию IConverter.

F>Ага, а для еще каких-нибудь конструкций "придется написать свою реализацию IXXX"

Мсье, как вижу, знает и понимает толк в извращениях

Батенька, а вы неправы! Все равно всех возможных комбинаций декларативно предусмотреть невозможно. Мне вот например надо чтобы стиль применялся к элементам у которых гиперболический тангенс значения аттрибута some-double был равен PI. Как это сделать в HtmlLayout?

A>>>А если я ещё хочу её при печати по-другому раскрасить... то мне поможет такая фича CSS как @media. Пишу
A>>>

A>>>@media print
A>>>{
A>>>}
A>>>

A>>>и указываю внутри альтернативные стили. Могу создавать произвольные новые media и указывать их имена, скажем могу сделать @media hi-contrast и переключать рендеринг без перезагрузки HTML.
A>>>Вообще много чего могу...
D>>Всё это решается через динамические ресурсы и/или Binding

F>Угу, на свете вообще все решается. Только кое-что решается через пляски с бубнами

Хм, это действительно просто решается.

Вместо того, чтобы юзать нормальный HTMLayout, вы упорно указываете на какую-то полусырую каку, уж извините. А когда вам приводят примеры того, с чем кака справиться не может — быстренько отваливаете в сторону

В сторону я не отваливаю, просто я сам ещё в WPF-е учусь поэтому некоторые примеры для меня тоже непросты а времени мало

F>З.Ы. Вот только не надо кричать, что "кака с этим не справляется, потому что это концептуально неправильно" и пр. Deal?
Да без проблем

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

SO>>Если стили задаются такими чудовищными костылями, WPF совсем не могильщик HTMLayout. А вот наоборот, вполне может быть

D>Ну во первых не надо так драматично.
Никакой драмы, просто жуткий код. Я когда-то давно увлекался написанием подобного

Если говорить про конкретные претензии — он (код) сильно избыточен. Сравни с лаконизмом CSS. (Предлагаю на ты

)

D>Во первых вы взяли полный пример на WPF (там не только стиль но и всё остальное) и сравниваете его с абстрактным фрагментом CSS.
Это не абстракция — ровно то, что попросил Андрей два поста назад.

D>Во вторых у меня складывается устойчивое впечатление что вы всё-таки до конца не осознаёте основную разницу между XAML и HTML+CSS.
Возможно.
D>HTML+CSS это язык разметки документов а XAML это язык сериализации объектов.
Теперь осталось доказать, что второе лучше первого.
Кстати, HTMLayout это не только легковесный HTML+CSS, но и простой способ подключать custom behaviors через CSS.

D>[...]
D>т.е. XAML это средство хранения графа объектов. Если к примеру мы напишем свой класс
D>[..]
D>Т.е. в XAML можно использовать не только классы из WPF.
В HTMLayout тоже можно, но если честно, это не важно:
1. Внешний вид элемента полностью определяется стилями.
2. Поведение элемента тоже определяется в стилях.
Если возникнет потребность в своем элементе его можно легко реализовать, в SDK есть примеры.

D>Кроме того, как показано выше, никто не заставляет использовать XAML для WPF. При желании никто не мешает написать свой псевдо-HTML + псевдо-CSS-парсер, который будет при парсинге создавать и настраивать соответствующие WPF-классы.
Это сколько же желания надо

Дописал, перечитал. По-моему все было сказано здесь http://www.rsdn.ru/forum/message/2771842.1.aspx, а мы перемываем те же косточки по второму разу.

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

CS>Роман, может имеет смысл завернуть все behaviors в отдельную native dll c внешней функцией CreateBehavior() и звать ея из managed в HLN_ATTACH_BEHAVIOR?

Ау, это тоже не на 5 минут задача. У меня на работе сейчас завал: могу только работать, кушать, спать и сраться в форуме, на другое времени нет. Будет время, перепишу на C#. Это имеет смысл так как это будут ещё и дополнительные примеры behavior на C# и некоторый материал для совместных с пользователями размышлений. Скажем есть какие-то вещи, которые я могу делать лучше за счёт специфичного для .Net функционала (например, прямо в HTML коде указать полное имя метода — обработчика события) и точно копировать Си++ реализацию было бы идеологически неправильно. Душа не лежит делать абы как

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

D>>>Ок, понял, всё решается через стили и темплейты с тригерами. Единственное что необходимо это для обработки конструкции ~= придётся написать свою реализацию IConverter.

F>>Ага, а для еще каких-нибудь конструкций "придется написать свою реализацию IXXX"

Мсье, как вижу, знает и понимает толк в извращениях

D>Батенька, а вы неправы! Все равно всех возможных комбинаций декларативно предусмотреть невозможно. Мне вот например надо чтобы стиль применялся к элементам у которых гиперболический тангенс значения аттрибута some-double был равен PI. Как это сделать в HtmlLayout?

Нет, я как батенька именно прав. Потому как вам указали на простейший пример, для которого, оказывается, нужно писать реализацию IConverter, чтобы все это заработало под WPF. Что говорить о том, если пример будет посложнее? А вы именно убегаете от ответа, приводя абсурдные примеры, цитирую "гиперболический тангенс значения аттрибута".

Поймите одно: селекторы CSS не на пустом месте возникли, много умных дяденек сидели и думали. Думали как раз для того, чтобы не пришлось писать IConverter'ы по каждому чиху.

Вот скажите мне, плз, как на WPF решить такую вполне себе жизненную задачу для селекторов CSS (можно, я словами): "для каждой ссылки, находящейся в третьем столбце таблицы с определенным id, в нечетной строке, установить определенный css-класс". Ы? Сколько IConverter'ов придется писать? Пяток?

На CSS-селекторах это делается одной строкой буквально

<< Самое главное — это деньги, а здоровье приходит и уходит. >>

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

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

D>>>>Ок, понял, всё решается через стили и темплейты с тригерами. Единственное что необходимо это для обработки конструкции ~= придётся написать свою реализацию IConverter.

F>>>Ага, а для еще каких-нибудь конструкций "придется написать свою реализацию IXXX"

Мсье, как вижу, знает и понимает толк в извращениях

D>>Батенька, а вы неправы! Все равно всех возможных комбинаций декларативно предусмотреть невозможно. Мне вот например надо чтобы стиль применялся к элементам у которых гиперболический тангенс значения аттрибута some-double был равен PI. Как это сделать в HtmlLayout?

F>Нет, я как батенька именно прав. Потому как вам указали на простейший пример, для которого, оказывается, нужно писать реализацию IConverter, чтобы все это заработало под WPF. Что говорить о том, если пример будет посложнее? А вы именно убегаете от ответа, приводя абсурдные примеры, цитирую "гиперболический тангенс значения аттрибута".

Не согласен, поиск строки в списке значений разделённых пробелами не является столь уж распространённым понятием поэтому стандартной реализации в WPF для этого нет. Тем не менее WPF в отличии от CSS позволяет расширять подобный набор выражений.

F>Поймите одно: селекторы CSS не на пустом месте возникли, много умных дяденек сидели и думали. Думали как раз для того, чтобы не пришлось писать IConverter'ы по каждому чиху.
И всё равно всех возможностей не предусмотришь. А в WPF в случае чего можно подставить свою реализацию — один раз написал — многократно используй.

F>Вот скажите мне, плз, как на WPF решить такую вполне себе жизненную задачу для селекторов CSS (можно, я словами): "для каждой ссылки, находящейся в третьем столбце таблицы с определенным id, в нечетной строке, установить определенный css-класс". Ы? Сколько IConverter'ов придется писать? Пяток?

Ыыыы... По поводу "в нечетной строке" не уверен, для остального IConverter-ов писать не надо.

F>На CSS-селекторах это делается одной строкой буквально

Вот опять вы не понимаете особенностей WPF. WPF это не синтаксис описания документа, это синтаксис описания объекта. А в CSS одна строка может порождать множество объектов. Если очень хочется никто вам не мешает написать свой объект понимающий CSS-подобный синтаксис и конструирующий по нему всю нужную гирлянду тригеров и стилей (этакий паттерн-фасад + паттерн-адаптер + паттерн-фабрика получится)

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

F>>На CSS-селекторах это делается одной строкой буквально

D>Вот опять вы не понимаете особенностей WPF. WPF это не синтаксис описания документа, это синтаксис описания объекта. А в CSS одна строка может порождать множество объектов. Если очень хочется никто вам не мешает написать свой объект понимающий CSS-подобный синтаксис и конструирующий по нему всю нужную гирлянду тригеров и стилей (этакий паттерн-фасад + паттерн-адаптер + паттерн-фабрика получится)

Про какое множество объектов идет речь?

По ходу дела:

CSS selectors это такой SQL для DOM элементов.

Можно наверное приспособить LINQ какой для XAML но это перекроет только функционал element::find_first/find_all.
Но и то, для того чтобы это работало в XAML должен быть DOM с unified элментами. Т.е. все тот же ComboBox например и все его сотавляющие (items скажем) должны быть dom элементами.

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

F>>Поймите одно: селекторы CSS не на пустом месте возникли, много умных дяденек сидели и думали. Думали как раз для того, чтобы не пришлось писать IConverter'ы по каждому чиху.
D>И всё равно всех возможностей не предусмотришь. А в WPF в случае чего можно подставить свою реализацию — один раз написал — многократно используй.

Веб-девелопмент активно развивается последние лет 10 и в селекторах CSS — объединен опыт очень многих людей: и теоретиков и практиков.
На моей памяти, существующий механизм расширялся в HTMLayout только единожды http://www.rsdn.ru/forum/message/2675427.1.aspx, после того как я привел подходящий юз-кейс (:has-child / :has-children появились буквально через несколько дней, причем сами селекторы меня не интересовали — была вполне практическая проблема)
Иногда (очень, очень редко), действительно бывает желание сделать свой селектор, но пойнт в том, что практически всегда можно обойтись (без ущерба) существующими селекторами.
Да, теоретически приятно иметь возможность их расширять, но на практике это не требуется.
Серьезные аргументы "за расширяемые селекторы" мне пока не встречались.

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

D>Вот опять вы не понимаете особенностей WPF. WPF это не синтаксис описания документа, это синтаксис описания объекта. А в CSS одна строка может порождать множество объектов. Если очень хочется никто вам не мешает написать свой объект понимающий CSS-подобный синтаксис и конструирующий по нему всю нужную гирлянду тригеров и стилей (этакий паттерн-фасад + паттерн-адаптер + паттерн-фабрика получится)

паттерн-фасад + паттерн-адаптер + паттерн-фабрика? Чтобы обобщённо раскрасить нечётные строки в другой цвет? Это не м... overkill?
Я не придираюсь, просто интересуюсь. Беда-то WPF не в том что это всё надо, а в том что это всё надо и этого всего в WPF нет. Я, конечно, не вполне объективен, но даже просто сравнение объёма листингов не в пользу WPF. У WPF есть визуальный редактор (и очень хороший!), но как показывает практика качественный интерфейс мышкой нарисовать довольно сложно. Особенно, если он должен менять размеры.

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

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

F>>>На CSS-селекторах это делается одной строкой буквально

D>>Вот опять вы не понимаете особенностей WPF. WPF это не синтаксис описания документа, это синтаксис описания объекта. А в CSS одна строка может порождать множество объектов. Если очень хочется никто вам не мешает написать свой объект понимающий CSS-подобный синтаксис и конструирующий по нему всю нужную гирлянду тригеров и стилей (этакий паттерн-фасад + паттерн-адаптер + паттерн-фабрика получится)

CS>Про какое множество объектов идет речь?
Ну ведь поднимаются структуры/классы выполняющие тот самый запрос. А в XAML эти структуры описываются явно.

CS>По ходу дела:

CS>CSS selectors это такой SQL для DOM элементов.

CS>Можно наверное приспособить LINQ какой для XAML но это перекроет только функционал element::find_first/find_all.
CS>Но и то, для того чтобы это работало в XAML должен быть DOM с unified элментами. Т.е. все тот же ComboBox например и все его сотавляющие (items скажем) должны быть dom элементами.
Можно. Вообще все основные WPF-объекты потомки DependencyObject (можно провести аналогию с IDomNode) так что по деревьям ходить можно. Их кстати 2 — логическое и визуальное

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

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

F>>>Поймите одно: селекторы CSS не на пустом месте возникли, много умных дяденек сидели и думали. Думали как раз для того, чтобы не пришлось писать IConverter'ы по каждому чиху.
D>>И всё равно всех возможностей не предусмотришь. А в WPF в случае чего можно подставить свою реализацию — один раз написал — многократно используй.

SO>Веб-девелопмент активно развивается последние лет 10 и в селекторах CSS — объединен опыт очень многих людей: и теоретиков и практиков.
SO>На моей памяти, существующий механизм расширялся в HTMLayout только единожды http://www.rsdn.ru/forum/message/2675427.1.aspx, после того как я привел подходящий юз-кейс (:has-child / :has-children появились буквально через несколько дней, причем сами селекторы меня не интересовали — была вполне практическая проблема)
SO>Иногда (очень, очень редко), действительно бывает желание сделать свой селектор, но пойнт в том, что практически всегда можно обойтись (без ущерба) существующими селекторами.
SO>Да, теоретически приятно иметь возможность их расширять, но на практике это не требуется.
SO>Серьезные аргументы "за расширяемые селекторы" мне пока не встречались.
Даже в таком ключе — сделать небольшую библиотечку для WPF, догоняющую по функциональности HTMLayout не есть долго. Согласны?

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

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

D>>Вот опять вы не понимаете особенностей WPF. WPF это не синтаксис описания документа, это синтаксис описания объекта. А в CSS одна строка может порождать множество объектов. Если очень хочется никто вам не мешает написать свой объект понимающий CSS-подобный синтаксис и конструирующий по нему всю нужную гирлянду тригеров и стилей (этакий паттерн-фасад + паттерн-адаптер + паттерн-фабрика получится)

A>паттерн-фасад + паттерн-адаптер + паттерн-фабрика? Чтобы обобщённо раскрасить нечётные строки в другой цвет? Это не м... overkill?
нет, не оверкилл. вместо сложной цепочки тригеров будете писать что -то вроде:

<a:MyDynamicStyle SelectorExpression="select:focus &gt; option:current">
   <Setter Property="Button.Background" Value="BlueViolet" />
   <Setter Property="Button.FontSize" Value="20" />
   <Setter Property="Button.Width" Value="200" />
   <Setter Property="Button.Height" Value="30" />
</a:MyDynamicStyle>

или, если хотите то вообще
<a:MyDynamicStyle
SelectorExpression="select:focus > option:current">
background:BlueViolet;
font-size:20px;
width:200px;
height:200px;
</a:MyDynamicStyle>

A>Я не придираюсь, просто интересуюсь. Беда-то WPF не в том что это всё надо, а в том что это всё надо и этого всего в WPF нет.
На самом всё что надо добавляется достаточно просто. Главное — понять философию WPF, она несколько отличается от HTML+CSS.
A>Я, конечно, не вполне объективен, но даже просто сравнение объёма листингов не в пользу WPF.
Опять таки тут спорный вопрос. Некоторые вещи делаются сложнее, некоторые проще. XAML поддерживает помимо кастомных тегов ещё и так называемые MarkupExtension-ы, офигительно мощный механизм, используемый в том числе и для Binding-а. Грамотное использование механизмов WPF даёт огромные возможности и очень простой код. Я как раз сейчас разрабатываю фреймворк для быстрого постоения приложений на WPF — не нарадуюсь. Прошлый фреймворк (тоже я делал) был на DHTML. Так что я могу сравнивать

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

D>Даже в таком ключе — сделать небольшую библиотечку для WPF, догоняющую по функциональности HTMLayout не есть долго. Согласны?

Не знаю

Посмотрим.

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

CS>>Про какое множество объектов идет речь?
D>Ну ведь поднимаются структуры/классы выполняющие тот самый запрос. А в XAML эти структуры описываются явно.

Да какие-то структуры создаются. Но эти структры достаточно просты и у GC каши не просят.
Для runtime запросов типа element::find_first/find_all эти структуры рождаются и умирают на стеке.

CS>>По ходу дела:

CS>>CSS selectors это такой SQL для DOM элементов.

D>Можно. Вообще все основные WPF-объекты потомки DependencyObject (можно провести аналогию с IDomNode) так что по деревьям ходить можно. Их кстати 2 — логическое и визуальное

Осталось дело за малым. Построить CSS процессор.
Я видел попытку сделать оный на Java и мелькал где-то проект броузера на .NET. Но умер по каки-то причинам.

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

CS>Осталось дело за малым. Построить CSS процессор.

Жжёшь!

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

A>>паттерн-фасад + паттерн-адаптер + паттерн-фабрика? Чтобы обобщённо раскрасить нечётные строки в другой цвет? Это не м... overkill?
D>нет, не оверкилл. вместо сложной цепочки тригеров будете писать что -то вроде:
D>

D><a:MyDynamicStyle SelectorExpression="select:focus &gt; option:current">
D>   <Setter Property="Button.Background" Value="BlueViolet" />
D>   <Setter Property="Button.FontSize" Value="20" />
D>   <Setter Property="Button.Width" Value="200" />
D>   <Setter Property="Button.Height" Value="30" />
D></a:MyDynamicStyle>
D>

D>или, если хотите то вообще
D><a:MyDynamicStyle
D> SelectorExpression="select:focus > option:current">
D> background:BlueViolet;
D> font-size:20px;
D> width:200px;
D> height:200px;
D></a:MyDynamicStyle>

а собственно почему тогда уже не

<style>
  select:focus > option:current {...}
</style>

?

D>Опять таки тут спорный вопрос. Некоторые вещи делаются сложнее, некоторые проще. XAML поддерживает помимо кастомных тегов ещё и так называемые MarkupExtension-ы, офигительно мощный механизм, используемый в том числе и для Binding-а. Грамотное использование механизмов WPF даёт огромные возможности и очень простой код. Я как раз сейчас разрабатываю фреймворк для быстрого постоения приложений на WPF — не нарадуюсь. Прошлый фреймворк (тоже я делал) был на DHTML. Так что я могу сравнивать

"Я как раз сейчас разрабатываю фреймворк для быстрого постоения приложений"
А вот с этого и надо было начинать. А то "могильщик, могильщик..."

Про MarkupExtension-ы... самый офигительный markup extension это старый добрый PHP или ASP/ASP.NET процессор.
А runtime extension это behavior и prototype (в Sciter) с четким и понятным life cycle.

Если ты про data binding то это из категории несбыточных мечт человечества.

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

CS>Осталось дело за малым. Построить CSS процессор.
CS>Я видел попытку сделать оный на Java и мелькал где-то проект броузера на .NET. Но умер по каки-то причинам.

Есть виджет для тикля

, который проходит даже ACID тест.

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

CS>>И вообще про "наступает время managed code" — в "священные войны".
D>Насчёт войн — спорить не буду но рекомендую посмотреть статистику по СЕРЬЁЗНЫМ проектам уровня предприятия. Все сервера приложений — 90% либо J2EE либо .NET. Бизнес-код в основном пишут на Managed. Тот же самый 1С — там тоже Managed.
1) Вам сколько лет?
2) А что на "проектах уровня предприятия" свет клином сошелся?

Или вы думаете что круче их ничего нет?

. Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет,
все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его.
Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"

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

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

CS>>Осталось дело за малым. Построить CSS процессор.
CS>>Я видел попытку сделать оный на Java и мелькал где-то проект броузера на .NET. Но умер по каки-то причинам.

8>Есть виджет для тикля

, который проходит даже ACID тест.

"тикля" это чего у нас такое будет?

ACID тест это отдельная песня.

ACID тестирует в том числе обработку невалидных конструкций.
Т.е. если например кто-нибудь туда воткнет скажем margin:*; то я автоматом его не пройду. Потому как для h-smile сие валидно.

Ну и потом конструкции типа display:table которые подразумевают создание rows и cells на лету (пусть и в shadow tree) я поддерживать не собираюсь. Все равно display:table это далеко не <table> (spanned cells например) тогда зачем оно?
ACID2 использует display:table поэтому не судьба.

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

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

CS>>Осталось дело за малым. Построить CSS процессор.

A>Жжёшь!

Да ну, это действительно несложно.

Проблема в другом: DOM должен быть CSS friendly.
Скажем button[type="menu"] подразумевает то что CSS процессор имеет
возможность быстро вытащить значение атрибута type. Reflection тут "не канает" скажем так.

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

8>>Есть виджет для тикля

, который проходит даже ACID тест.
CS>"тикля" это чего у нас такое будет?

TCL.TK

http://tkhtml.tcl.tk/index.html

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

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

CS>>Проблема в другом: DOM должен быть CSS friendly.
CS>>Скажем button[type="menu"] подразумевает то что CSS процессор имеет
CS>>возможность быстро вытащить значение атрибута type. Reflection тут "не канает" скажем так.

C>Генерация байт-кода и кэширование?

кэширвание чего? значения атрибута? или нагенерирванного байткода?

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

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

8>>>Есть виджет для тикля

, который проходит даже ACID тест.
CS>>"тикля" это чего у нас такое будет?

8>TCL.TK

Ага, понятно.

Смотря для чего там html позиционируется.
Если на просто help показать то для этого ACID не нужен.
Если для нужд UI на экране то фич CSS21 явно недостаточно.

8>http://tkhtml.tcl.tk/index.html

( прикольно, но тяжко такие штуки на голимом C писать )

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

A>>Очень хочется HTMLayout для .Net (2.0) — т.е. без Native C++. Если этого не будет, то WPF — победит (когда не будет W2k/win9x)
W>Когда не будет W2k/win9x — .NET уже тоже не будет

. Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет,
W>все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его.
W>Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"

Все правильно, .NET такой же движетель рынка как был/есть COM.
Кстати ничего плохого в .NET нет. Есть попытка засунуть его во все возможные отверстия
квадратно гнездовым методом. Что и получилось с COM.
Употребленный массивно, очень часто не к месту и не квалифицировано создал кучу проблем.
Как бы .NET не постигла та же участь.

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

C>>Генерация байт-кода и кэширование?
CS>кэширвание чего? значения атрибута? или нагенерирванного байткода?
Да, кэширование атрибута. У меня есть подобная задача — выбирать объекты из графа по осям (наподобии XPath), у меня получается кэшировать атрибуты на время выполнения выражения.

Кстати, хотел спросить — а для Java в HTMLayout еще никто адаптерами не занимался?

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

> COM .. употребленный массивно, очень часто не к месту и не квалифицировано создал кучу проблем.

А примеры?

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

W>Когда не будет W2k/win9x — .NET уже тоже не будет

. Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет,

.Net живет уже 5 лет (первая студия с C# появилась в 2002 году)

COM — 14 лет (он появился в 1993 году). Я не могу согласиться с тем, что COM отправлен на свалку. Просто в своем развитии эта технология достигла максимума, трудно себе представить, что там можно реально улучшить, на написав попутно новый .Net. Масса программ использует и будет продолжать использовать COM. И его поддержка будет всегда существовать в ОС Windows.

W>все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его.
W>Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"

А вот интересно, люди говорящие подобные вещи вообще понимают, почему в начале появилась технология COM (ее недостатки были понятны практически сразу), и только теперь можно переходить на более удобый, гибкий и безопасный .Net? Если нет, то могу объяснить — COM в 1993 году мог работать на компютере IBM PC AT с 1-м мегабайтом памяти и процессором Intel 20286 c частотой (точно не помню, но типа мегагерц 20-30). При этом работал не просто "абстрактный COM", а MS Excel рисовало табличку в MS Word, т.е. взаимодействовало два солидных приложения. Все это жило в Windows 3.1. Теперь, когда машины стали помощьнее, и технологии стали более сложными. При этом COM и .Net весьма не плохо совмещаются.

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

A>А примеры?

Это я в принципе к тому, что представь себе, например, C++ "употребленный массивно, очень часто не к месту и не квалифицировано".

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

>> COM .. употребленный массивно, очень часто не к месту и не квалифицировано создал кучу проблем.
A>А примеры?
IE с его утечками памяти в JavaScript'е...

A>А вот интересно, люди говорящие подобные вещи вообще понимают, почему в начале появилась технология COM (ее недостатки были понятны практически сразу), и только теперь можно переходить на более удобый, гибкий и безопасный .Net?
На мой вгляд .НЕТ хоть и даёт удобство,гибкость и безопасность. Всё идёт к удешевлению труда специалистов. Я сталкивался с тем что написанием программ на .НЕТ причём в коммерческих целях занимались люди имеющих довольно скудное представление об ООП. В начале появился ком который избавил от ада dll щас .NET. Причём сам по себе .НЕТ даже для БД в сыром виде не используется. А распространены ОО Обёртки над ним, такие как NHibernate ,и\или собственного написания. Причём зачастую даже там где требуется скорость, где бы необходимо написать используя DataReader и пр. Всёравно используются высокоуровневые обёртки . Мотивируя это тем что код мегауниверсален и маштабируем. А получаем что получаем. "тормозность", но удобство, красивое IDE,хорошо организованая идеалогия ООП, делают своё дело и технология успешно продвигается. скоро популярность спадёт и после какого нибудь .NET 7.0 отправится на полку. А все будут поклонятся новой обёртке над WinApi.

A>При этом COM и .Net весьма не плохо совмещаются.
Но и не весьма хорошо. MIDL и CLR не одно и тоже и каждый раз конвертить типы приходится. разве это удобство?

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

A>А вот интересно, люди говорящие подобные вещи вообще понимают, почему в начале появилась технология COM (ее недостатки были понятны практически сразу), и только теперь можно переходить на более удобый, гибкий и безопасный .Net?

Я, глядя на последнии технологии мелкомягких, склоняюсь к мысли,
что они таки научат обезьян "программировать",
и наступит хаос и тьма спустится на землю обетованную.

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

CS>Проблема в другом: DOM должен быть CSS friendly.
CS>Скажем button[type="menu"] подразумевает то что CSS процессор имеет
CS>возможность быстро вытащить значение атрибута type. Reflection тут "не канает" скажем так.

DependencyProperty

CS>Здравствуйте, Cyberax, Вы писали:
C>>Генерация байт-кода и кэширование?
CS>кэширвание чего? значения атрибута? или нагенерирванного байткода?
И нагенерированный байткод тоже кэшировать можно.

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

W>Здравствуйте, dimzon, Вы писали:
CS>>>И вообще про "наступает время managed code" — в "священные войны".
D>>Насчёт войн — спорить не буду но рекомендую посмотреть статистику по СЕРЬЁЗНЫМ проектам уровня предприятия. Все сервера приложений — 90% либо J2EE либо .NET. Бизнес-код в основном пишут на Managed. Тот же самый 1С — там тоже Managed.
W>1) Вам сколько лет?
W>2) А что на "проектах уровня предприятия" свет клином сошелся?

Или вы думаете что круче их ничего нет?

1) А какая ВАМ разница? Достаточно.
2) Будем "пиписьками" мерятся?

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

A>А вот интересно, люди говорящие подобные вещи вообще понимают, почему в начале появилась технология COM (ее недостатки были понятны практически сразу), и только теперь можно переходить на более удобый, гибкий и безопасный .Net?

Java? Издавна есть на телефонах и как-то никто не горевал что мощности мало.
Ядро .Net не требует каких-то особых ресурсов, тем более по сравнению с СОМ.

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

A>Java? Издавна есть на телефонах и как-то никто не горевал что мощности мало.

Это, мягко говоря, немного другая Java, чем та, что ставиться на PC. Кроме того, современный телефон (или PDA) будет помошьнее персонального компьютера конца 90-х. Например, я на моем PDA могу играть в Doom, а вот на моей IBM PC AT c Intel 80286 и 1 мегабайтом памяти (а именно про такую машину я говорил) я этого не мог. Но на этой машине работала Windows 3.1 и COM.

A>Ядро .Net не требует каких-то особых ресурсов, тем более по сравнению с СОМ.

Угу. Ты урежь себе память мегабайтов до 16-ти и запусти прораммку на .Net, которая рисует на экране окошко с текстом Hello, World и кнопкой. Окошко на экране появиться минут через 10.

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

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

W>>Когда не будет W2k/win9x — .NET уже тоже не будет

. Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет,

A>.Net живет уже 5 лет (первая студия с C# появилась в 2002 году)

A>COM — 14 лет (он появился в 1993 году). Я не могу согласиться с тем, что COM отправлен на свалку. Просто в своем развитии эта технология достигла максимума, трудно себе представить, что там можно реально улучшить, на написав попутно новый .Net. Масса программ использует и будет продолжать использовать COM. И его поддержка будет всегда существовать в ОС Windows.
И это нам говорит "сертифицированный специалист Microsoft"

Ничего подобного. Небыло COM в 1993 году.
В 1993 году у MS был OLE1.0 — технолгия не имеющая практически НИЧЕГО общего с COM, она строилась поверх DDE.
В 1995 году вместе с Win95 вышел OLE2.0 который ничего кроме первых 3 букв в названии не имеел с OLE1.0.
Так вот эта OLE2.0 базировалась на COM. Причем если мне не изменяет память, то время в COM — MIDL'а еще не было
был ODL. До MIDL'а MS доросла году в 96-98м. А сколько раз они переливали из пустого в порожнее называя весь этот стафф
то OLE, то COM, то ActiveX в разных сочетаниях, к 2000 году я думаю даже в самой MS врядли кто-нить мог внятно объяснить
что именно они называют технологией ActiveX

W>>все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его.
W>>Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"

A>А вот интересно, люди говорящие подобные вещи вообще понимают, почему в начале появилась технология COM (ее недостатки были понятны практически сразу), и только теперь можно переходить на более удобый, гибкий и безопасный .Net? Если нет, то могу объяснить — COM в 1993 году мог работать на компютере IBM PC AT с 1-м мегабайтом памяти и процессором Intel 20286 c частотой (точно не помню, но типа мегагерц 20-30). При этом работал не просто "абстрактный COM", а MS Excel рисовало табличку в MS Word, т.е. взаимодействовало два солидных приложения. Все это жило в Windows 3.1. Теперь, когда машины стали помощьнее, и технологии стали более сложными. При этом COM и .Net весьма не плохо совмещаются.
Повторяю — не было тогда COM, см. выше

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

A>>Ядро .Net не требует каких-то особых ресурсов, тем более по сравнению с СОМ.

A>Угу. Ты урежь себе память мегабайтов до 16-ти и запусти прораммку на .Net, которая рисует на экране окошко с текстом Hello, World и кнопкой. Окошко на экране появиться минут через 10.

Окошко это не ядро. Учи матчасть.

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

A>Окошко это не ядро. Учи матчасть.

Ядро само по себе никому не нужно, если оно не будет окошки рисовать, файлы открывать и еще что-нибудь такое делать, ради чего вообще программы пишутся. И вот когда я рисую окошко "через ядро .Net" (а не напрямую, через WinAPI), я получаю внушительный расход памяти. Я, в принципе, не против и даже понимаю куда и зачем она использовалась.

А вот для COM приктически ничего не нужно — IUnknown, вот и все его "ядро".

W>И это нам говорит "сертифицированный специалист Microsoft"

W>Ничего подобного. Небыло COM в 1993 году.
W>В 1993 году у MS был OLE1.0 — технолгия не имеющая практически НИЧЕГО общего с COM, она строилась поверх DDE.....

OLE 2 (в основе которой лежал COM) появилась в 1993 году в Windows 3.1 — ее использовали и Word 6.0 и Excel 5.0 (в котором появился VBA http://en.wikipedia.org/wiki/Microsoft_Excel — Since 1993, Excel has included Visual Basic for Applications (VBA)...), я в то время лично при помощи Visual C++ 1.5 (http://support.microsoft.com/kb/145669 — New Features: ... OLE 2.0 SDK) и Visual Basic 4 писал и использовал объекты OLE Automation.

Вот тебе ссылка на статью 1993 года (с подходящим названием

)
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarolegen/html/msdn_aboutole.asp

Вот тебе ссылка на OLE 2.03 для Windows 3.1 — http://support.microsoft.com/kb/123087

И вот тебе ссылка на Wikipedia — http://en.wikipedia.org/wiki/Component_object_model

Такие вот дела.

A>Вот тебе ссылка на статью 1993 года (с подходящим названием

)

Пардон, шутка не получилась, вот ссылка на статью с с подходящим названием

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarolegen/html/msdn_ole2a.asp

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

A>Ядро само по себе никому не нужно, если оно не будет окошки рисовать, файлы открывать и еще что-нибудь такое делать, ради чего вообще программы пишутся. И вот когда я рисую окошко "через ядро .Net" (а не напрямую, через WinAPI), я получаю внушительный расход памяти. Я, в принципе, не против и даже понимаю куда и зачем она использовалась.

Вот как раз окошки и файлы суть разные вещи. Файлы давай читать на .Net — память изличшне расходоваться не будет. А вот для окошек будет. И я как раз очень хорошо понимаю почему.

A>А вот для COM приктически ничего не нужно — IUnknown, вот и все его "ядро".

Здрасьте

А маршалинг? А апартменты? А IDispatch/TLB?

PS Обрати внимание на год статьи. На шутку не обжайся.

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

A>Вот как раз окошки и файлы суть разные вещи. Файлы давай читать на .Net — память изличшне расходоваться не будет.

Ну да — я из потока читаю, например, строки. Прочитал, посмотрел на строчку, прочитал следующую, когда я читаю следующую строку, то старая останется висеть в памяти (я не могу в string прочитать новое значение) — чем больше строк прочитаю, тем больше памяти отестся. Разве не так?

Ну а если говорть так — я при помощи interop обращаюсь к API-функии ReadFile и в один и тот же буфер (byte[]) читаю данные, тогда да, тогда память не расходуется. Но многие ли так делают. Тогда и CreateWindow особого расхода памяти не потребует.

A>>А вот для COM приктически ничего не нужно — IUnknown, вот и все его "ядро".

A>Здрасьте

А маршалинг? А апартменты? А IDispatch/TLB?

Для Windows 3.1 маршалиг как таковой был не нужен (там не было защиты памяти, все жили в одной "куче") — хотя в OLE 2 он был "по честному", очевидно для NT 3.1 (и для тормозов

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

A>Ну да — я из потока читаю, например, строки. Прочитал, посмотрел на строчку, прочитал следующую, когда я читаю следующую строку, то старая останется висеть в памяти (я не могу в string прочитать новое значение) — чем больше строк прочитаю, тем больше памяти отестся. Разве не так?

А кто сказал что эффективный строкой IO делается на основе класса System.String?! Вот в Си++ (который совсем unmanaged) есть scanf и std::cin. Предлагаю на досуге убедиться что скорость работы различается на порядки.

A>Ну а если говорть так — я при помощи interop обращаюсь к API-функии ReadFile и в один и тот же буфер (byte[]) читаю данные, тогда да, тогда память не расходуется. Но многие ли так делают. Тогда и CreateWindow особого расхода памяти не потребует.

Можно указывать byte[], ничего зазорного тут нет. Лично я, когда нужна была эффективная работа, так и делал.

A>>>А вот для COM приктически ничего не нужно — IUnknown, вот и все его "ядро".
A>>Здрасьте

А маршалинг? А апартменты? А IDispatch/TLB?

A>Для Windows 3.1 маршалиг как таковой был не нужен (там не было защиты памяти, все жили в одной "куче") — хотя в OLE 2 он был "по честному", очевидно для NT 3.1 (и для тормозов

. Апартментов там тоже не было (т.к. не было threads). IDispath/TLB — по слухам — полностью разрабатывались командой Visual Basic (они делали OLE Automation) — какое же это ядро? Ядро COM — IUnknown + куча функций Co.... + реестр (для COM в Windows 3.1 был маленький реестрик — только HKCR)

Маршалинг может быть не только в пределах одной машины. IDispatch и TLB неотемлемая часть СОМ, так как default marshaling делается именно на основе TLB. Короче в вопросе ты не разбираешься, как я погляжу.

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

A>Можно указывать byte[], ничего зазорного тут нет. Лично я, когда нужна была эффективная работа, так и делал.

Да нет, конечно ничего зазорного в этом нет. Но смысл в том, что ты не сможешь в очень большом круге задачь ограничится этим byte[] — тебе будет нужна строка (ведь говорим об строковом вводе/выводке, а в .Net это System.String) (например, мы читаем xml-файл). Как только ты получшь из byte[] эту строку, ты "повесишь" ее в памяти до сборки мусора.

A>Маршалинг может быть не только в пределах одной машины.

В начале (в OLE 2.0 в Windows 3.1) ни о каком DCOM речи вообще не шло. Причем, обрати внимание, я не говорил о том, что в OLE 2 не было маршалинга. Но только для Windows 3.1 его можно было и не создавать.

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

A>Да нет, конечно ничего зазорного в этом нет. Но смысл в том, что ты не сможешь в очень большом круге задачь ограничится этим byte[] — тебе будет нужна строка (ведь говорим об строковом вводе/выводке, а в .Net это System.String) (например, мы читаем xml-файл). Как только ты получшь из byte[] эту строку, ты "повесишь" ее в памяти до сборки мусора.

Ещё раз, чтобы обработать byte[] как строку, например найти подпоследовательность символов, переводить byte[] в System.String нет необходимости.

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

A>Ещё раз, чтобы обработать byte[] как строку, например найти подпоследовательность символов, переводить byte[] в System.String нет необходимости.

Это конечно так, но .Net — это не C/C++. Много ты знаешь стандартных классов, которым можно вместо строки передавать byte[] или char[] вмето System.String?

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

A>>Ещё раз, чтобы обработать byte[] как строку, например найти подпоследовательность символов, переводить byte[] в System.String нет необходимости.
A>Это конечно так, но .Net — это не C/C++. Много ты знаешь стандартных классов, которым можно вместо строки передавать byte[] или char[] вмето System.String?

Ну вот char[] то как раз много куда можно передать. А соответствие byte[] <-> char[] вообще говоря неоднозначное.

Здравствуйте, aloch, Вы писали:
A>Ну да — я из потока читаю, например, строки. Прочитал, посмотрел на строчку, прочитал следующую, когда я читаю следующую строку, то старая останется висеть в памяти (я не могу в string прочитать новое значение) — чем больше строк прочитаю, тем больше памяти отестся. Разве не так?
Старая строка будет собрана GC и очень быстро. Сборка нулевого поколения почти ничего не стоит. По расходу памяти это будет значительно лучше, чем выделять строчки в классическом хипе.
A>Ну а если говорть так — я при помощи interop обращаюсь к API-функии ReadFile и в один и тот же буфер (byte[]) читаю данные, тогда да, тогда память не расходуется. Но многие ли так делают. Тогда и CreateWindow особого расхода памяти не потребует.
Никакого Interop не надо. Ты можешь точно так же читать в char[], но это вряд ли даст тебе значительный выигрыш по памяти.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

Да я все это знаю — я сам сейчас программирую на С#, и возвразаться к старым способам особено не тянт (хотя и приходится).

Разговор шел о другом — о том, что технологии типа .Net (или Java) было практически не возможно реализовать на том "железе", на котором изначально реализовывался COM (да и сам Windows). Когда "железо" "подросло", то открылись совершенно новые возможности, которые привели к созданию новых технологий программирования, при этом старые технологии (COM) в утиль никто не отправляет.

А то есть такая легенда (в основном она популярна среди линуксойдов) о том, что "Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет, все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его. Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"", при этом люди это говорящие совсем не понимают причин, по которым сначало создавалас A, а теперь можно использовать B.

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

A>А то есть такая легенда (в основном она популярна среди линуксойдов) о том, что "Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет, все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его. Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"", при этом люди это говорящие совсем не понимают причин, по которым сначало создавалас A, а теперь можно использовать B.

Прочины простые — надо было подождать, пока поменяется мышление программистов. До сих пор многие сидят на VC6 и пишут мелкие вещи на WinAPI потому что "быстрее работает". Было время когда классы, виртуальные функции считали плохой идеей.

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

A>А то есть такая легенда (в основном она популярна среди линуксойдов) о том, что "Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет, все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его. Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"", при этом люди это говорящие совсем не понимают причин, по которым сначало создавалас A, а теперь можно использовать B.

Я себя к линуксоидам не отношу, но вот два раза наблюдал Дона Бокса на конференциях Микрософт.
Вот что из этого вышло:
http://www.rsdn.ru/Forum/?mid=1482487
Третья (Mix) уже сам БГ представлял .web что называется. Но сей совместный опус с Геннадием писан до Mix.
Но я как в воду глдел.

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

A>рочины простые — надо было подождать, пока поменяется мышление программистов.

И типа оно сейчас само-собой поменялось? И, например, если бы не эта костность мышления, нам MS забабахала бы на 1 мегабайте памяти сборку мусора?
Или COM и OLE2 не меняли мышление "так сильно"?

8>>http://tkhtml.tcl.tk/index.html

CS>( прикольно, но тяжко такие штуки на голимом C писать )

Tcl/Tk — это далеко не голый С. Имхо, это похоже на html+css+javascript. Хотя "css там" это и не "css сдесь", но работает весело. Жаль, что всё заканчивается в конце концов накиданием батонов на формочки

Здравствуйте, Andrei N.Sobchuck, Вы писали:

8>>>http://tkhtml.tcl.tk/index.html

CS>>( прикольно, но тяжко такие штуки на голимом C писать )

ANS>Tcl/Tk — это далеко не голый С. Имхо, это похоже на html+css+javascript. Хотя "css там" это и не "css сдесь", но работает весело. Жаль, что всё заканчивается в конце концов накиданием батонов на формочки

Я конкретно tkhtml (http://tkhtml.tcl.tk/index.html) имел ввиду.

И вообще, если задаваться целью сделать html layout (эдакий рисующий layout manager в терминах AWT) то я считаю подход который я использовал в Harmonia он наиболее
подходящий что-ли для такого рода use cases. В harmonia html используется именно как layout manager. DOM как таковой там не нужен. Сугубо parse/measure/draw методы + callback replace_widget(child_widget). Доводить конструкции типа tkhtml.tcl.tk до уровня полного html/css2.1 движка и ACID тестов я считаю пустой тратой времени. И все равно css2.1 всего спектра задач UI не решает. Например те же flex units в htmlayout (или flex аттрибут в XUL).

Т.е. нужно четко ставить задачу для чего и как оно.

Полный html/css rendering это достаточно нетривиальная штука. Там много деталей которые не должны торчать наружу.
Т.е. периметр движка должен быть компактным насколько это возможно.

Концептуально говоря... Не вчера родилась идея по разделению tiers.

Я считаю что html + css + behaviors как UI tier естественным образом замыкающий логику и представление UI это good thing (tm).

Такой подход позволяет опять же естественным образом отделить слой который отвечает за логику обработки и представления данных.
Эти два слоя должны обмениваться сугубо абстрактными данными в стиле CGI/form submit — json-messaging?. Такой подход позволяет как развязать данные
так и изолировать сущности/namespaces. Например обработку данных удобно делать в managed средах типа .NET и Java.
Собственно не зря .NET и Java так популярны на server side. И GC там в принципе работает (или может работать) детерменировано и эффективно — исполнил запрос — почистил память.

Т.е. по большому счету связка browser/server как модель взаимодейтвия UI/логика представляется достаточно устойчивой.
И в рамках desktop приложения такая модель "играет" хорошо. Даже более чем хорошо.

В качестве примера вот BugTracking system типа: http://www.seapine.com/ttpro.html
Я уверен что в случае htmlayout её можно сделать значительно интереснее и эффективнее.
А вот WPF почему-то представляется неподходящей технологией для такого рода приложений.

Скорее всего WPF и htmlayout имеют несколько разные среды обитания что-ли...

От:	dimzon	http://dimzon541.narod.ru
Дата:	18.12.07 15:58
Оценка:	8 (1)

От:	adontz	http://adontz.wordpress.com/
Дата:	18.12.07 17:20
Оценка:

От:	dimzon	http://dimzon541.narod.ru
Дата:	18.12.07 17:55
Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	18.12.07 17:56
Оценка:

От:	dimzon	http://dimzon541.narod.ru
Дата:	18.12.07 18:01
Оценка:

От:	ShaggyOwl	http://www.rsdn.org
Дата:	18.12.07 20:11
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	18.12.07 23:21
Оценка:	20 (3)

От:	Flamer	http://users.livejournal.com/_flamer_/
Дата:	21.12.07 13:57
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	27.12.07 06:39
Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	02.01.08 21:20
Оценка:

	От:	aloch
	Дата:	19.12.07 16:30
	Оценка:	-1

	От:	aloch
	Дата:	19.12.07 16:47
	Оценка:	-1

	От:	aloch
	Дата:	19.12.07 16:50
	Оценка:	-1

	От:	aloch
	Дата:	19.12.07 16:57
	Оценка: