Здравствуйте, 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 очень прост, по сути конструкция вида
Т.е. в 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-классы.
Это сколько же желания надо
Здравствуйте, c-smile, Вы писали:
CS>Роман, может имеет смысл завернуть все behaviors в отдельную native dll c внешней функцией CreateBehavior() и звать ея из managed в HLN_ATTACH_BEHAVIOR?
Ау, это тоже не на 5 минут задача. У меня на работе сейчас завал: могу только работать, кушать, спать и сраться в форуме, на другое времени нет. Будет время, перепишу на C#. Это имеет смысл так как это будут ещё и дополнительные примеры behavior на C# и некоторый материал для совместных с пользователями размышлений. Скажем есть какие-то вещи, которые я могу делать лучше за счёт специфичного для .Net функционала (например, прямо в HTML коде указать полное имя метода — обработчика события) и точно копировать Си++ реализацию было бы идеологически неправильно. Душа не лежит делать абы как
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 > 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. Но умер по каки-то причинам.
Здравствуйте, dimzon, Вы писали:
A>>паттерн-фасад + паттерн-адаптер + паттерн-фабрика? Чтобы обобщённо раскрасить нечётные строки в другой цвет? Это не м... overkill? D>нет, не оверкилл. вместо сложной цепочки тригеров будете писать что -то вроде: D>
?
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) А что на "проектах уровня предприятия" свет клином сошелся? Или вы думаете что круче их ничего нет?
Здравствуйте, aloch, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
A>Маркетологчсеки.
A>Очень хочется HTMLayout для .Net (2.0) — т.е. без Native C++. Если этого не будет, то WPF — победит (когда не будет W2k/win9x)
Когда не будет W2k/win9x — .NET уже тоже не будет . Ни одна девелопмент технология Мелкомягких не живет дольше 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 поэтому не судьба.