Как это реализовано? Реализовано через достаточно простую кодогенерацию. Например, одно из правил кодогенерации такое – на каждое свойство заданного типа генерируем extension метод, которые просто вызывает сеттер свойства.
Полный список правил кодогенерации можно увидеть в проекте CodeGenerator.
Какие вкусности получаем?
1. Сценарий аля “master page” получаем как само собой разумеющееся -- просто вынос кода в отдельный метод с параметрами. Смотрите метод Section и его использование.
2. Проблема организации системы стилей пропадает. Код просто разбивается по методам. В частности, в WPF до сих пор не реализовано множественное наследование стилей (хотя, вроде, обещали); в C# коде такой проблемы просто не возникает. Например, для реализации на XAML-е логики, за которую отвечает метод SetFontStyle (см. использование метода), пришлось бы использовать наследование стилей. А по мере развития формы стили уже не будут укладываться в иерархию.
Отмечу, что запись на C#-е часто короче, чем на XAML-е. Например, объем кода для записи стиля в методе CreateStyleInCode на 10 процентов меньше, чем на XAML-е. Для Template-а запись на C#-е на один процент больше.
Текущие проблемы. Сгенерированный код получается достаточно большим. Уже на текущем примере 132 тысячи строк. IntelliSense от ReSharper-а неприемлемо тормозит -- счет идет на десятки секунд. IntelliSense от Visual Studio показывается почти сразу, но небольшая задержка уже есть. В связи с этим, можно отказаться от части правил в кодогенерации. Например, вместо “.Grid_Row(1)”, надо будет писать “.Attach(C<Grid>().Row(1))”. Это несколько удлинит код, но, на мой взгляд, это не принципиальное удлинение.
P.S. Интересно, что в этом плане можно сделать на Nemerle?
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Текущие проблемы. Сгенерированный код получается достаточно большим. Уже на текущем примере 132 тысячи строк. IntelliSense от ReSharper-а неприемлемо тормозит -- счет идет на десятки секунд. IntelliSense от Visual Studio показывается почти сразу, но небольшая задержка уже есть. В связи с этим, можно отказаться от части правил в кодогенерации. Например, вместо “.Grid_Row(1)”, надо будет писать “.Attach(C<Grid>().Row(1))”. Это несколько удлинит код, но, на мой взгляд, это не принципиальное удлинение.
В первую очередь нужно выкинуть код вида
public static System.Windows.Controls.ContentControl BorderBrush_AliceBlue(this System.Windows.Controls.ContentControl it)
{
return it.BorderBrush(System.Windows.Media.Brushes.AliceBlue);
}
Ибо писать
BorderBrush_AliceBlue()
или
BorderBrush(Brushes.AliceBlue)
по большому счету без разницы.
А такого кода у тебя там ну очень много.
AP>P.S. Интересно, что в этом плане можно сделать на Nemerle?
От того что сделал ты до на что фантазии хватит.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
, приведу код C# для решения тех задач, для которых используется XAML. AP>Требуется сверстать вот такую формочку. AP>Вот C# код для этой формочки http://propertyexpression.codeplex.com/SourceControl/changeset/view/43314#669767
AP>Как это реализовано? Реализовано через достаточно простую кодогенерацию. Например, одно из правил кодогенерации такое – на каждое свойство заданного типа генерируем extension метод, которые просто вызывает сеттер свойства. AP>
S>почему нельзя сделать поддержку чего-то типа JSON?
Можно. Но это должны сделать разработчики языка. C# 3.0/4.0 для этого не достаточно (подробнее см. ниже). Этот вопрос я и поднимал в первом треде
Ведь Object и Collection Initializers в шарпе уже есть. S>Типа S>
S>Border = new Border{Padding=5};
S>Nested =
S>{
S> new Grid
S> {
S> Rows =
S> {
S> new RowDefinition { Height=Auto },
S> new RowDefinition
S> {
S> Nested = new Grid
S> {
S> ColumnDefinitions =
S> {
S> new ColumnDefinition(),
S> new ColumnDefinition { Width=18 },
S> new ColumnDefinition()
S> },
S> Nested =
S> {
S> new Section{ Name = "Customer", Content = CustomerSection(), GridPosition = Position(0, 0) },
S> new Section( Name = "Dealer", Content = DealerSection(), GridPosition = Position(0, 2)}
S> }
S> }
S> }
S> }
S> }
S>}
S>
Да, Object и Collection Initializers это первое, что хочется заиспользовать. Но:
1. Collection Initializers применять не получается, поскольку они работают только около конструктора коллекции. При построении UI-ного дерева конструкторы коллекций явно не вызываются. UI-ые элементы уже содержат инстансы коллекций. У свойства RowDefinitions даже сеттера нет.
2. Object Initializers тоже работают только около конструктора. Это мешает резать цепочку проставления свойств на отдельные методы. В моем примере часть свойств проставляется в методе TextBox(…), а часть после вызова этого метода
TextBox(1, 1).Grid_ColumnSpan(3)
3. Нет аналога перегрузки метода. Придется писать new Border{Padding= new Thickness(5)} Вместо new Border().Padding(5)
S>По-моему, это будет иметь все вкусности, которые тебе нужны, с гораздо меньшим количеством сгенерированного кода.
1. Не понятно, какой природы в твоем коде объект Section; его должен проглатывать метод Nested. Наверное, ты имел ввиду какие-то правила на этот счет. Но в моем коде такие вопросы даже не возникают.
2. Второй пункт вкусностей, по-моему, не работает в силу выше упомянутых причин.
WH>Ибо писать WH>BorderBrush_AliceBlue() WH>или WH>BorderBrush(Brushes.AliceBlue) WH>по большому счету без разницы.
Я тоже так считал, и делал это по причине -- отрапортовать, что запись на C# получается не длиннее записи на XAML. Но когда сделал это, то мне показалось это удобной мелочью. Случайно натолкнулся на пост совершенно из другой темы, где человек хочет такой же краткой записи.
AUD>А просто chain-ить большинство вещей без кодогенерации не рассматривали?
Да, рассматривали, но вариант отличался от вашего, см. ниже.
AUD>
AUD> public static class Ext
AUD> {
AUD> public static T _<T>(this T target, Action<T> action)
AUD> {
AUD> action(target);
AUD> return target;
AUD> }
AUD> }
AUD> new Grid().
AUD> _(g => g.RowDefinitions
AUD> ._(rd => rd.Add(new RowDefinition()._(r => r.IsEnabled = true)))
AUD> ._(rd => rd.Add(new RowDefinition()._(r => r.Height = new GridLength(10)))));
AUD>
AUD>Или слишком много кода получается? AUD>В любом случае так IMO более discoverable — в ваш fluent interface-е еще надо будет разбираться что где.
Здесь теряется одна из основных прелестей цепочной записи -- отсутствие лишних временных переменных. Даже в вашем коротком фрагменте кода их уже три g, rd, r. В коде реального приложения эти переменные будут мешать достаточно сильно. Как пример, часто используются вложенные Grid-ы, как будут назваться переменные g1, g2, g3?
Вот такая запись рассматривалась в качестве кандидата.
new Grid()._(_ => _.RowDefinitions,
new RowDefinition()._(_ => _.IsEnabled)(true),
new RowDefinition()._(_ => _.Height)(new GridLength(10))
)
Но кодогенерация показалась более приемлемым вариантом.
Читабельность нулевая. Стройное дерево графа объектов порублено на ветки, которые аккуратно разложены по методам. Я хорошо читаю XAML и могу себе в голове примерную картинку результата нарисовать, но тут спасовал. А ведь ещё приходится рефакторить XAML — упрощать некоторые участки, заменять одни элементы другими, выносить повторяемые участки в ресурсы...
AP>Отмечу, что запись на C#-е часто короче, чем на XAML-е. Например, объем кода для записи стиля в методе CreateStyleInCode на 10 процентов меньше, чем на XAML-е. Для Template-а запись на C#-е на один процент больше.
Судя по паре примеров, повторное использование участков графа достигается за счёт создания новых экземпляров этого участка, вместо использования ресурсов? Другой вопрос — как WPF обнаружит стиль для самодельного контрола, ежели стиль задан вот в такой манере? Как будет работать переопределение стилей?
AP>Текущие проблемы. Сгенерированный код получается достаточно большим. Уже на текущем примере 132 тысячи строк.
К проблемам можно добавить ещё труп дизайнера, повесившегося на галстуке в сортире.
, приведу код C# для решения тех задач, для которых используется XAML. AP>>Требуется сверстать вот такую формочку. AP>>Вот C# код для этой формочки http://propertyexpression.codeplex.com/SourceControl/changeset/view/43314#669767
V>Читабельность нулевая. Стройное дерево графа объектов порублено на ветки, которые аккуратно разложены по методам. Я хорошо читаю XAML и могу себе в голове примерную картинку результата нарисовать, но тут спасовал. А ведь ещё приходится рефакторить XAML — упрощать некоторые участки, заменять одни элементы другими, выносить повторяемые участки в ресурсы...
AP>>Отмечу, что запись на C#-е часто короче, чем на XAML-е. Например, объем кода для записи стиля в методе CreateStyleInCode на 10 процентов меньше, чем на XAML-е. Для Template-а запись на C#-е на один процент больше.
V>Судя по паре примеров, повторное использование участков графа достигается за счёт создания новых экземпляров этого участка, вместо использования ресурсов? Другой вопрос — как WPF обнаружит стиль для самодельного контрола, ежели стиль задан вот в такой манере? Как будет работать переопределение стилей?
AP>>Текущие проблемы. Сгенерированный код получается достаточно большим. Уже на текущем примере 132 тысячи строк.
V>К проблемам можно добавить ещё труп дизайнера, повесившегося на галстуке в сортире.
С процитированным полностью согласен.Собственно, добавлю еще, что некоторым удобно гланды перректально удалять. XAML для того и придумали, чтобы дизайнеры на галстуках в сортирах не вешались. Опять же, непонятно как быть, если потребуется вносить в разметку изменения. Подозреваю, по трудоемкости это будет значительно превосходить правку XAML. Автору топика — попробуйте реализовать конструкцию темплейт в темплейте в темплейте. Интересно, после какого уровня вложенности код будет полностью нечитабельным, в отличие от XAML.
V>Читабельность нулевая. Стройное дерево графа объектов порублено на ветки, которые аккуратно разложены по методам. Я хорошо читаю XAML и могу себе в голове примерную картинку результата нарисовать, но тут спасовал.
Давайте разберемся что порублено.
1. Для методов CustomerSection и DealerSection, действительно, можно сделать inline (вставить тело метода в то место, где используется метод) http://propertyexpression.codeplex.com/SourceControl/changeset/view/43726#761520
2. Остальные методы используются более одного раза, поэтому эта "рубка" обоснована.
2.1 Относительно методов SetFrameBorderBrush, SetFontStyle -- на XAML-е это было бы вынесено в ресурсы, т.е. "рубка" тоже имеет место.
2.2 Относительно методов TextBox, TextBlock. Здесь на XAML-е придется проставлять свойства с помощью стилей, а стили выносить в ресурсы. Но в указанных методах уже задействован стиль (метод SetFontStyle), поэтому придется использовать наследование стилей. А при развитии формы стили не будут укладываться в иерархию.
2.3 Остался метод Section. С этим в XAML-е еще сложнее. Приходится городить специальный контрол аля "master page". Получается неоправданно много кода (да и логических составляющих). Причем в MSDN-е этот очевидный, часто встречающийся use case не освещен, народ сам придумывает решения. Это наводит на мысль, что архитекторы WPF не задумывались о таком сценарии. И это печально.
V>А ведь ещё приходится рефакторить XAML — упрощать некоторые участки, заменять одни элементы другими,
Что вы хотите этим сказать? Что C# код хуже, чем XAML, воспринимает рефакторинг? На мой взгляд, как раз верно обратное -- C# рефакторится не хуже XAML-а. А скорее всего лучше, это еще одна причина, по которой хочется писать на C#-е.
V>выносить повторяемые участки в ресурсы...
В нормальных языках для этого используются методы, поля, локальные переменные, классы и т.д. А ресурсы в качестве механизма выноса повторяемых участков кода -- это просто убожество. Например, методы могут принимать параметры, с ресурсами такой простой трюк не проходит.
V>Судя по паре примеров, повторное использование участков графа достигается за счёт создания новых экземпляров этого участка, вместо использования ресурсов?
Вы говорите об оптимизации производительности и объема памяти? Во-первых, вместо методов можно использовать поля borderBrush, fontStyle. Во-вторых, на мой взгляд, в большинстве случаев выигрыш от такой оптимизации будет не заметен. В-третьих, можно организовать создание по требованию и кэширование, это не сильно увеличит объем кода.
V>Другой вопрос — как WPF обнаружит стиль для самодельного контрола, ежели стиль задан вот в такой манере? Как будет работать переопределение стилей?
Не совсем понял, о чем Вы, но механизмы WPF работают в не зависимости от того, как создаются WPF элементы, через XAML или через C#.
V>К проблемам можно добавить ещё труп дизайнера, повесившегося на галстуке в сортире.
О дизайнере шла речь еще в первом треде
. По моим наблюдениям, и тот тред их подтвердил, дизайнеру (программному обеспечению) пока не находится места в процессе разработки реальных приложений. Пока дизайнер выглядит, как не удавшаяся попытка реализации идеи о разделении труда, а так же, как оправдание названия среды разработки "Visual". В ASP.NET дизайнер улучшают с каждой версией (и пишут об этом в рекламных проспектах), но его использование до сих пор выглядит просто смешным.
C>Собственно, добавлю еще, что некоторым удобно гланды перректально удалять.
Ухты , в Вашем дополнении так много информации, относящейся к теме треда.
C>XAML для того и придумали, чтобы дизайнеры на галстуках в сортирах не вешались.
Это уже обсуждалось.
C>Опять же, непонятно как быть, если потребуется вносить в разметку изменения. Подозреваю, по трудоемкости это будет значительно превосходить правку XAML.
Об этом я уже писал.
C>Автору топика — попробуйте реализовать конструкцию темплейт в темплейте в темплейте. Интересно, после какого уровня вложенности код будет полностью нечитабельным, в отличие от XAML.
В метод CreateDataTemplateInCode добавил вложенный DataTemplate
New<ListBox>().ItemsSource(new Binding("Cars")).ItemTemplate(
new DataTemplate().Nested(
New<Label>().Content(new Binding("Brand"))
)
C>>Автору топика — попробуйте реализовать конструкцию темплейт в темплейте в темплейте. Интересно, после какого уровня вложенности код будет полностью нечитабельным, в отличие от XAML. AP>В метод CreateDataTemplateInCode добавил вложенный DataTemplate AP>
Собственно, к чему енто я.XAML в 99,999999999% удобнее кодогенерации. Разговоры о перфомансе и оптимизации — уж извините, в разработке UI в первую очередь речь должна идти об удобстве разработчика и удобстве поддержки. Признаю, Вы проделали колоссальную работу.Проблема лишь одна — в реальных проектах применение данного подхода весьма сомнительно. Причины тут озвучивали выше:
1. Наглядность. Опять же, есть куча отличных редакторов XAML(KaXaml тому примером), которые позволяют нормально видеть, что получается, еще на стадии прототипирования(без привязок к данным и т.д.)
2. Легкость внесения изменений.
3. Гибкость.
4. Четкое разделение логики и представления.
Не сомневаюсь, что ваш кодогенератор до этого дорастет когда-нибудь, но не уверен, что это будет удобно. А как программисткий этюд — сделано супер. Проблема в том, что это никому особо не нужно.
. По моим наблюдениям, и тот тред их подтвердил, дизайнеру (программному обеспечению) пока не находится места в процессе разработки реальных приложений. Пока дизайнер выглядит, как не удавшаяся попытка реализации идеи о разделении труда, а так же, как оправдание названия среды разработки "Visual". В ASP.NET дизайнер улучшают с каждой версией (и пишут об этом в рекламных проспектах), но его использование до сих пор выглядит просто смешным.
А сколько вы видели реальных приложений в разработке, чтобы делать такие выводы? А кроме Visual Studio вы визуальных инструментов для xaml не смотрели? А они есть. Более того, есть реальные дизайнеры, которые рисуют в своих дизайнерских пакетах и потом это импортируют в xaml, а потом это все в реальных проектах используется. Ну да, кое-что приходится потом в этом xaml'е править, чтобы не наступать на грабли с производительностью, но черта-с-два вы это в коде нарисуете. Мой lookless контрол в релизе уже около двух лет и я каждый раз поражаюсь, когда юзеры мне свои сэмплы присылают, в которых новый UI в xaml'е отрисован. Не представляю, как это можно делать в вашей концепции.
По-моему, вы просто не умеете готовить xaml.
А не можете пояснить, что у вас за Master Page и почему нельзя вместо этого использовать какой-нибудь DataGrid, или DataForm (последнего пока вроде в WPF нет, но планируется, но уже можно найти портированные с третьего сильверлайта версии).
Хотя нет, не в этом дело. Лучше скажите, кто может использовать вашу реализацию и в каких случаях? У меня такое ощущение, что это подходит для коллектива, где один человек более-менее в матчасти разбирается, а остальные должны TextBox'ы с кнопками на формы складывать. Так все равно им будет проще в дизайнере это сделать. Т.е., если уж человек понимает, как наследуются стили, что такое темплейты и т.д., то зачем ему еще учиться пользоваться чем-то еще кроме xaml'а? А если человек этого всего не понимает, то возможность делать это в коде ему тоже не поможет.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Почему в примере темплейты просто не вложены друг в друга, а используются ссылки через ресурсы? Использование ресурсов это принципиально?
Да, принципиально. Считайте, что файлы с темплейтами разрабатывает другая команда. Я бы мог вынести объявления ресурсов в отдельный файл для наглядности. BTW, я хотел бы просто увидеть данный пример, реализованный с помощью Вашего кодогенератора. Поскольку возникают вопросы, почему темплейты в ресурсах и т.д., я прихожу к выводу, что требуюмую гибкость Ваш кодогенератор обеспечить все-таки не может. Думаю, в конце концов Вы придете к мысли, что не получится покрыть все сценарии, которые могут быть реализованы в XAML. Отдельно отмечу, что для XAML не существует единственно правильного и верного написания кода. Обычно существует несколько путей добиться желаемого результата.
А по поводу инлайн- темплейтов — смысла их так объявлять нету никакого.Иначе пример получается надуманным и сильно оторванным от реальной жизни.
З.Ы. А увидеть код все-таки хочется. Чтобы читаемость сравнить.
Re: C# vs. XAML
От:
Аноним
Дата:
23.09.09 11:54
Оценка:
Вообще, если по-честному сказать, сомневаюсь, что дизайнер (тот, который настоящий дизайнер, а не «веб-дизайнер») сможет редактировать XAML без глубокой специальной подготовки.
Ведь XAML — это, в принципе, тоже язык программирования, может быть, слегка более абстрактный, чем C#. Он всего лишь является способом доступа к объектной модели через XML.
А объектная модель — это удел программистов. Для человека, далекого от программирования, все объектные модели будут такой же китайской грамотой, как и все программирование в целом.
Мне кажется, на XAML нереально написать что-то серьезное, не понимая, как он внутри работает, а чтобы это понимать, нужно быть программистом.
Кстати, знаменательно, что в какой-то газете я прочитал неграмотное замечание о том, что XML — это язык программирования. И какая-то доля правды в этом есть.
Так что идея о том, что дизайнер может напрямую редактировать XAML, мне кажется наивной.
Дизайнер сможет работать с визуальным интерактивным редактором, но тогда не все ли равно, в каком виде представляется код, который генерирует визуальный редактор — в XAML, C# или вообще в бинарном формате?
Но ваша идея с WPF в C# имеет очевидный недостаток — сложная и трудоемкая запись. Синтаксис C# вы ведь не расширяете, не приближаете его к предметной области.
Для этого вам нужно было бы встроиться в компилятор C# и внести изменения в спецификацию языка (этакие «WPF extensions»).
А ведь ещё приходится рефакторить XAML — упрощать некоторые участки, заменять одни элементы другими, выносить повторяемые участки в ресурсы... 
, в Вашем дополнении так много информации, относящейся к теме треда.
