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

I>Псевдокод стиля.

По-прежнему не понимаю. Вы хотите вместо C#-подобного псевдокода XML-подобный? Типа, можете выбрать любой цвет, при условии, что он чёрный?

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

Q>По-прежнему не понимаю. Вы хотите вместо C#-подобного псевдокода XML-подобный? Типа, можете выбрать любой цвет, при условии, что он чёрный?

IT выше по теме предложил использовать циклы в стилях. Я вот не очень понимаю, каким боком они там будут полезны. То что вы привели, это обычный код, который пишется в code behind, на стиль это никак не тянет.

Можно, конечно, применить этот код ко всем датагридам в своём проекте, но от этого настоящим стилем он не станет.

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

I>IT выше по теме предложил использовать циклы в стилях.

Я не предлагал использовать циклы именно в стилях. Я предложил использовать циклы в языке разметки, которым является XAML. Инициализация визуальных компонент в циклах может легко заменить использование стилей, решить вопрос копипасты там, где стили не играют и обеспечить компактную инициализацию в зависимости от счётчика/элемента цикла.

Кстати, циклы лишь один из вариантов. Колонки грида вполне можно было бы инициализировать с помощью LINQ выражений.

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

IT>>Давай обойдёмся без подобных аргументов.
AVK>Ну тогда я могу, путем выдумывания правильной задачи, обосновать непригодность любой технологии.

В данном случае твой аргумент — это аргумент в стиле Влада, раз мне не надо, то никому не надо. Мне, например, за 20 лет существования джавы её было не надо, значит она никому не надо.

AVK>Если тебе нужно стоя, в гамаке и в ластах — C# тебе в руки, задвать стили программно позволяет и текущая реализация WPF.

Стоя в гамаке и в ластах бывает нужно примерно в каждом первом проекте и частенько на C# действительно получается код, который значительно проще поддерживать.

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

IT>В данном случае твой аргумент — это аргумент в стиле Влада, раз мне не надо, то никому не надо.

Неверно. Тут другой расклад. Покрыть 100% всех задач все равно не получится. Поэтому нужно покрывать максимцум возможного. А вот отказываться от декларативного описания стилей только потому что какая то вычурная задача декларативно описывается плохо — явно не самый разумный подход.

IT> и частенько на C# действительно получается код, который значительно проще поддерживать.

Так в чем проблема то? Проще описать в императивном стиле — описывай в императивном. Это не значит что декларативное описание не нужно.

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

IT>>В данном случае твой аргумент — это аргумент в стиле Влада, раз мне не надо, то никому не надо.
AVK>Неверно. Тут другой расклад. Покрыть 100% всех задач все равно не получится. Поэтому нужно покрывать максимцум возможного. А вот отказываться от декларативного описания стилей только потому что какая то вычурная задача декларативно описывается плохо — явно не самый разумный подход.

Есть хороший пример — Razor. В нём всё отлично описывается и в нём явно лучший подход, чем в .aspx.

IT>> и частенько на C# действительно получается код, который значительно проще поддерживать.
AVK>Так в чем проблема то? Проще описать в императивном стиле — описывай в императивном. Это не значит что декларативное описание не нужно.

Я нигде не утверждал, что декларативное описание не нужно. Я вообще начал с того, что нужно выкинуть XAML и заменить его на нормальный DSL. Если в нём будет кроме декларации ещё и циклы, то это будет только плюс.

Кстати, LINQ по-твоему декларация или цикл?

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

IT>Есть хороший пример — Razor. В нём всё отлично описывается и в нём явно лучший подход, чем в .aspx.

Только вот и там и там стили описываются на декларативном css.

AVK>>Так в чем проблема то? Проще описать в императивном стиле — описывай в императивном. Это не значит что декларативное описание не нужно.
IT>Я нигде не утверждал, что декларативное описание не нужно. Я вообще начал с того, что нужно выкинуть XAML и заменить его на нормальный DSL.

Ага, императивный. Помню.

IT>Кстати, LINQ по-твоему декларация или цикл?

Сам запрос — разумеется декларация. В цикле обязательно должен быть mutable state.

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

IT>>Есть хороший пример — Razor. В нём всё отлично описывается и в нём явно лучший подход, чем в .aspx.
AVK>Только вот и там и там стили описываются на декларативном css.

И что?

IT>>Я нигде не утверждал, что декларативное описание не нужно. Я вообще начал с того, что нужно выкинуть XAML и заменить его на нормальный DSL.
AVK>Ага, императивный. Помню.

В том числе. Razor ведь императивный в том числе и никому это не мешает.

IT>>Кстати, LINQ по-твоему декларация или цикл?
AVK>Сам запрос — разумеется декларация. В цикле обязательно должен быть mutable state.

Ну вот тебе кошерно-декларативный вариант того же цикла. Мне на кошерность, как и на тотальную декларативность по большому счёту наплевать, но для принципиальных фанатов это можно ввести похожие конструкции.

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

IT>>>Я нигде не утверждал, что декларативное описание не нужно. Я вообще начал с того, что нужно выкинуть XAML и заменить его на нормальный DSL.
AVK>>Ага, императивный. Помню.
IT>В том числе. Razor ведь императивный в том числе и никому это не мешает.

Razor решает другую задачу.

IT>>>Кстати, LINQ по-твоему декларация или цикл?
AVK>>Сам запрос — разумеется декларация. В цикле обязательно должен быть mutable state.
IT>Ну вот тебе кошерно-декларативный вариант того же цикла.

Это не вариант цикла. Цикл появляется только когда ты потребляешь результат запроса. А описание некоего подмножества в виде предиката с увязкой предиката с неким набором значений — на этом, собственно, построены практически все языки стилей, в том числе и в WPF. Просто в WPF он убогий и извратный в угоду совместимости с XAML.

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

IT>>В том числе. Razor ведь императивный в том числе и никому это не мешает.
AVK>Razor решает другую задачу.

Пусть UI DSL тоже решает другую задачу, мне пофиг.

IT>>Ну вот тебе кошерно-декларативный вариант того же цикла.
AVK>Это не вариант цикла. Цикл появляется только когда ты потребляешь результат запроса. А описание некоего подмножества в виде предиката с увязкой предиката с неким набором значений — на этом, собственно, построены практически все языки стилей, в том числе и в WPF. Просто в WPF он убогий и извратный в угоду совместимости с XAML.

Для инициализации компонентов вполне себе нормальный заменитель цикла. Что касается убогости, то об этом я тут как бы всё это время и распинаюсь.

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

IT>Для инициализации компонентов вполне себе нормальный заменитель цикла.

Ну то есть на самом деле никакой императивности у стилей нет?

IT> Что касается убогости, то об этом я тут как бы всё это время и распинаюсь.

Я напомню точную цитату:

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

ЕА>Про Qml согласен — лучше Xaml, остальное не видел — посмотрю на досуге

Народ, вы вообще красавцы ...
А у борланда описание формы на DEF файлах были еще лучше, там вообще ничего нельзя было сделать,
кроме инициализации свойств — за то как все просто и наглядно.
приведите мне описание на Qml кнопки неправильной формы с неровными краями, тогда сравним что проще.
про остальные ссылки я просто молчу.
конвертор с Qml на wpf пишется за пару дней, только вот в обратную сторону никак.
Если вы такие поклонники данной технологии — в чем собственно проблема? — сел да написал.
Проблема в том, что мы привыкли к тому что мы делаем разметку и мне тут же показывают как выглядит то, что я сделал?
без этого никакие Qml просто не имеют смысла?

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

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

PZT>>А как бы вы переделали WPF?

IT>Как переделали ASP.NET WebForms? Выкинули нафиг XML и сделали нормальный C# подобный язык, органично совмещающийся с html. Что-то подобное нужно и здесь. XAML ведь всё равно сначала транслируется в C#, а уже потом исполняется.

Вот здесь была попытка http://habrahabr.ru/post/165943/
Но по мне выглядит хуже оригинала.

Вот здесь концепт WPF на YAML https://gist.github.com/scottlowe/488749 Хз только как в реале будет.

Написать конвертер в XAML несложно, но придумать ему толковую замену будет непросто.

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

А>приведите мне описание на Qml кнопки неправильной формы с неровными краями, тогда сравним что проще.
А>про остальные ссылки я просто молчу.
А>конвертор с Qml на wpf пишется за пару дней, только вот в обратную сторону никак.
Ты спутал теплое с мягким. Я нигде не утверждал что компоненты QtQuick мощнее или лучше WPF.
Просто ИMXO(и не только И) XML(XAML) гораздо хуже YAML(QML) для описания UI.

А>Проблема в том, что мы привыкли к тому что мы делаем разметку и мне тут же показывают как выглядит то, что я сделал?
А>без этого никакие Qml просто не имеют смысла?
Согласен. Только не понял к чему ты это спросил.

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

IT>>Для инициализации компонентов вполне себе нормальный заменитель цикла.
AVK>Ну то есть на самом деле никакой императивности у стилей нет?

На самом деле мне на это глубоко наплевать. Любой фанатичный шизняк насчёт всевозможной кошерности меня уже давно не возбуждает.

IT>> Что касается убогости, то об этом я тут как бы всё это время и распинаюсь.
AVK>Я напомню точную цитату:

Ага, спасибо.