Как это реализовано? Реализовано через достаточно простую кодогенерацию. Например, одно из правил кодогенерации такое – на каждое свойство заданного типа генерируем 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 без глубокой специальной подготовки.
XAML не сложнее HTML. А>Ведь XAML — это, в принципе, тоже язык программирования, может быть, слегка более абстрактный, чем C#. Он всего лишь является способом доступа к объектной модели через XML.
Флейм по этому поводу разводить не буду А>А объектная модель — это удел программистов. Для человека, далекого от программирования, все объектные модели будут такой же китайской грамотой, как и все программирование в целом.
Не путайте объектную модель с отображением. Это две разных вещи. А>Мне кажется, на XAML нереально написать что-то серьезное, не понимая, как он внутри работает, а чтобы это понимать, нужно быть программистом.
Неверное утверждение. Дизайнер в XAML пишет внешний вид, все остальное на откуп программисту(биндинги и пр.). XAML — язык для верстки. А>Кстати, знаменательно, что в какой-то газете я прочитал неграмотное замечание о том, что XML — это язык программирования. И какая-то доля правды в этом есть. А>Так что идея о том, что дизайнер может напрямую редактировать XAML, мне кажется наивной. А>Дизайнер сможет работать с визуальным интерактивным редактором, но тогда не все ли равно, в каком виде представляется код, который генерирует визуальный редактор — в XAML, C# или вообще в бинарном формате?
Утверждения неверны,имхо.См. выше. А>Но ваша идея с WPF в C# имеет очевидный недостаток — сложная и трудоемкая запись. Синтаксис C# вы ведь не расширяете, не приближаете его к предметной области.
Тут полностью согласен А>Для этого вам нужно было бы встроиться в компилятор C# и внести изменения в спецификацию языка (этакие «WPF extensions»).
Вообще, стремление изобретать велосипеды неистребимо в российском программисте. А по поводу данного конкретного велосипеда — если бы Майкрософт избрала путь,предложенный автором топика, то не думаю, что WPF была бы легче в освоении. Человеческий мозг так устроен, что ему проще видеть целую картину из некоего декларативного описания(HTML,XAML,XML etc), чем из нескольких сотен строчек кода, которые очень тяжело визуализировать во внятную картинку. А в целом, если кодогенератор данный позволяет реализовать все(я подчеркиваю, все) сценарии, реализуемые в XAML, почему бы и нет. Проблемы тут начнутся на больших приложениях с развесистым UI. Вот тут редактирование и изменение может превратиться в реальный кошмар. Я бы проект, написанный подобным образом, править бы не решился.
Ну и в догонку — XAML позволяет без перекомпиляции изменять внешний вид UI(если правильно организовать структуру приложения), что тоже является несомненным плюсом с моей точки зрения.
C>З.Ы. А увидеть код все-таки хочется. Чтобы читаемость сравнить.
Если Вы хотите в точности тот фрагмент, то вот. Но все же, зачем это надо?
const string template2 = "Template2";
const string template3 = "Template3";
const string template1 = "template1";
this.Nested(
new Grid().Resources(
new ResourceDictionary
{
{
template1,
new TextBox().Text("t1").ToDataTemplate()
},
{
template2,
new Grid().RowDefinitions(
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto()).Nested(
new TextBlock().Text("template2"),
new ContentPresenter().Grid_Row(1).Content(new Binding()).ContentTemplate(new Resource(template1))
).ToDataTemplate()
},
{
template3,
new Grid().RowDefinitions(
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto()).Nested(
new TextBlock().Text("template3"),
new ContentPresenter().Grid_Row(1).Content(new Binding()).ContentTemplate(new Resource(template2))
).ToDataTemplate()
}
}).Nested(
new ContentPresenter().ContentTemplate(new Resource(template3))
)
);
http://propertyexpression.codeplex.com/SourceControl/changeset/view/43919#762610
Отмечу, что это пока эксперименты.
C>А по поводу инлайн- темплейтов — смысла их так объявлять нету никакого.Иначе пример получается надуманным и сильно оторванным от реальной жизни.
То есть этот огород с темплейтами и ресурсами только ради того, чтобы вынести часть кода в отдельный файл? На C#-е это делается через простое выделение куска кода в метод. Показать, как это без темплейтов и ресурсов выглядит на C#?
C>Поскольку возникают вопросы, почему темплейты в ресурсах и т.д., я прихожу к выводу, что требуюмую гибкость Ваш кодогенератор обеспечить все-таки не может.
Вы всегда так поспешны с выводами? Если да, то вы много интересного пропускаете .
C>Думаю, в конце концов Вы придете к мысли, что не получится покрыть все сценарии, которые могут быть реализованы в XAML.
Что значит, не получится покрыть? На худой конец, можно просто реализовать паттерн билдер для построения XAML-а. И тогда любой код на XAML можно переписать на C#-е. Весь вопрос во временных затратах и в удобстве получаемого синтаксиса. Оценкой этих двух вещей я и занимаюсь сейчас, а Вы почему-то решили, что уже что-то сделано. Спасибо за помощь в этом процессе, ваши вопросы оказались весьма полезными .
C>Вообще, стремление изобретать велосипеды неистребимо в российском программисте. А по поводу данного конкретного велосипеда — если бы Майкрософт...
C>Человеческий мозг так устроен, что ему проще видеть целую картину из некоего декларативного описания(HTML,XAML,XML etc), чем из нескольких сотен строчек кода, которые очень тяжело визуализировать во внятную картинку. А в целом, если кодогенератор данный позволяет реализовать все(я подчеркиваю, все) сценарии, реализуемые в XAML, почему бы и нет. Проблемы тут начнутся на больших приложениях с развесистым UI. Вот тут редактирование и изменение может превратиться в реальный кошмар. Я бы проект, написанный подобным образом, править бы не решился.
Все наоборот. Эта деятельность, как раз, нацелена на большие проекты. Недостатки XAML-а, против которых нацелен мой проект (см. первый пост), становятся головной болью именно на больших проектах. На небольших проектах можно и копипастом поддерживать UI в консистентном состоянии. Преимущества языка (в данном случае C#) с развитыми механизмами реюза кусков кода проявляются именно на больших проектах (возможно, на группе проектов, где используются общие куски UI-я). На C#-е код получается логически более чистым, поэтому в него легче вносить изменения. В большом проекте "целую картину" вы все равно не увидите, поэтому остается полагаться на "острый инструмент". А XAML, к сожалению, таким не является.
C>Ну и в догонку — XAML позволяет без перекомпиляции изменять внешний вид UI(если правильно организовать структуру приложения), что тоже является несомненным плюсом с моей точки зрения.
А C# 5.0 нам не поможет?
C>Вообще, стремление изобретать велосипеды неистребимо в российском программисте. А по поводу данного конкретного велосипеда — если бы Майкрософт избрала путь...
Вы уверены, что правильно понимаете и употребляете термин “изобретать велосипед”?
Здравствуйте, Alexander Polyakov, Вы писали:
C>>З.Ы. А увидеть код все-таки хочется. Чтобы читаемость сравнить. AP>Если Вы хотите в точности тот фрагмент, то вот. Но все же, зачем это надо? AP>
AP> const string template2 = "Template2";
AP> const string template3 = "Template3";
AP> const string template1 = "template1";
AP> this.Nested(
AP> new Grid().Resources(
AP> new ResourceDictionary
AP> {
AP> {
AP> template1,
AP> new TextBox().Text("t1").ToDataTemplate()
AP> },
AP> {
AP> template2,
AP> new Grid().RowDefinitions(
AP> new RowDefinition().Height_Auto(),
AP> new RowDefinition().Height_Auto()).Nested(
AP> new TextBlock().Text("template2"),
AP> new ContentPresenter().Grid_Row(1).Content(new Binding()).ContentTemplate(new Resource(template1))
AP> ).ToDataTemplate()
AP> },
AP> {
AP> template3,
AP> new Grid().RowDefinitions(
AP> new RowDefinition().Height_Auto(),
AP> new RowDefinition().Height_Auto()).Nested(
AP> new TextBlock().Text("template3"),
AP> new ContentPresenter().Grid_Row(1).Content(new Binding()).ContentTemplate(new Resource(template2))
AP> ).ToDataTemplate()
AP> }
AP> }).Nested(
AP> new ContentPresenter().ContentTemplate(new Resource(template3))
AP> )
AP> );
AP>
C>Думаю, в конце концов Вы придете к мысли, что не получится покрыть все сценарии, которые могут быть реализованы в XAML.
Что значит, не получится покрыть? На худой конец, можно просто реализовать паттерн билдер для построения XAML-а. И тогда любой код на XAML можно переписать на C#-е. Весь вопрос во временных затратах и в удобстве получаемого синтаксиса. Оценкой этих двух вещей я и занимаюсь сейчас, а Вы почему-то решили, что уже что-то сделано. Спасибо за помощь в этом процессе, ваши вопросы оказались весьма полезными .
Ну хоть чем-то помог .Возможно я не в теме, но все же, не совсем ясны стремления, подвигнувшие вас на этот шаг. Вы не разобрались в XAML? Или лично Вам проще читать код, приведенный выше, который по сути от XAML ничем не отличается(такой же язык разметки, но основанный не на XML)? Что ж, я только за разнообразие, но пользоваться буду тем, чем удобнее.
З.Ы. Сдается мне, в конце концов данный язык будет сильно похож на XAML .
З.Ы.Ы.Пользоваться данным генератором не рискну — скорость разработки важнее,как, впрочем, и наглядность кода.
З.Ы.Ы.Ы. Мы еще не обсудили вариант со сложными биндингами, кстати.(RelativeSource,FindAncestor и т.д.).
C>... но пользоваться буду тем, чем удобнее.
И все же, приведите код для реализации формочки из первого поста. Хотя бы схематично, интересен момент, как вы будите реализовывать две одинаковые секции Customer, Dealer, каждая из них имеет свой заголовок и свое внутреннее содержание. Будите ли Вы реюзать этот кусок разметки или скопипастите?
AP>Почему в примере темплейты просто не вложены друг в друга, а используются ссылки через ресурсы? Использование ресурсов это принципиально?
А вы поизучайте как раз этот вопрос. Именно тут в xaml'е находится повторное использование без копипаста. И ваши две формочки из первого поста именно так и делаются, ничего копировать для этого не нужно (хотя их можно и другими способами без копипаста реализовать).
AP>Все наоборот. Эта деятельность, как раз, нацелена на большие проекты. Недостатки XAML-а, против которых нацелен мой проект (см. первый пост), становятся головной болью именно на больших проектах. На небольших проектах можно и копипастом поддерживать UI в консистентном состоянии.
Вы всерьез полагаете, что вашим изобретением никто не сможет пользоваться так же, как вы пользуетесь xaml'ом — с копипастом и прочими недостатками?
Лучше давайте по пунктам, какие недостатки xaml'а вы видите, кроме того, что вам приходится копипастить (именно вам, по идее там это совсем не нужно, а как раз наоборот) и что нельзя вынести что-то в отдельный метод? Читаю ваши сообщения, читаю, код ваш смотрела — никак яснее не могу для себя вашу точку зрения сформулировать. С чего вдруг стили не будут куда-то укладываться, а код уложится? Может надо какую-то конкретную задачку взять, на которой у вас все вопросы к xaml'у возникли, и решить ее нормально, чтобы уже четко понять — есть ли реальная проблема, или это ваше непонимание.
C>>Думаю, в конце концов Вы придете к мысли, что не получится покрыть все сценарии, которые могут быть реализованы в XAML. AP>Что значит, не получится покрыть? На худой конец, можно просто реализовать паттерн билдер для построения XAML-а. И тогда любой код на XAML можно переписать на C#-е.
Понятно, что можно сделать практически все, кроме высовывания долларов из cd привода, а зачем?
Т.е., когда вы говорите о недостатках xaml'а, я еще понимаю, что я возможно не все понимаю. Но переписать любой xaml на c# — это уже просто ради того, чтобы переписать?
Ну и потом, почитайте, например документацию к FrameworkElementFactory — не все можно создать в коде просто по определению. И, судя по тому, что в Сильверлайте темплейт можно ТОЛЬКО загрузить из xaml, то и дальнейшее развитие этой темы в WPF пойдет в эту же сторону.
Рано или поздно уткнетесь в то, что не сможете использовать все возможности WPF, а вынуждены будете делать какие-то вещи в стиле WinForms.
Скриншот для указанной мной формы рисовал профессиональный дизайнер. Требуется в точности соблюсти все задумки дизайнера. Если какие-то правила лайаута не видны из рисунка, их можно уточнить у дизайнера (сейчас можно спросить у меня или посмотреть в C# код). Сейчас ваша реализация выглядит некрасиво. Отмазка, что Вы не прописывали все детали, не катит, поскольку кода Вы написали уже больше, чем в моей C# реализации.
То, что увидел при первом просмотре:
1. Текст “Fax:” должен быть прижат к правому краю.
2. В оригинале текст “State\province:” выдавливает свой текстбокс вправо. Но при этом текстбоксы для Fax и Country выровнены по линии.
3. Ширина колонки для лейблов должна выравниваться по максимальному тексту в колонке. У Вас же тупо захарткожено Width="100", причем для обоих колонок (ширина колонок необязательно одинакова).
4. Все три шрифта (в заголовке секции, в лайблах, в текстбоксах) должны иметь одни и те же FontFamily=”Tahoma” Font Size=”11”.
AP>>Может надо какую-то конкретную задачку взять, на которой у вас все вопросы к xaml'у возникли, и решить ее нормально, чтобы уже четко понять — есть ли реальная проблема, или это ваше непонимание.
Да, можете реализовать формочку из первого поста. Вот здесь
N>Именно тут в xaml'е находится повторное использование без копипаста. И ваши две формочки из первого поста именно так и делаются, ничего копировать для этого не нужно (хотя их можно и другими способами без копипаста реализовать).
Ждем от Вас вариант формочки.
Здравствуйте, Vladek, Вы писали:
V>Здравствуйте, Alexander Polyakov, Вы писали:
AP>>Все же, лучше увидеть полную реализацию формочки на XAML-е. Как будут выглядеть стили, тоже интересно.
V>В случае реального приложения, такого кода будет ещё меньше за счёт использования биндингов и шаблонов данных. Разметка резиновая.
V>
AP>4. Все три шрифта (в заголовке секции, в лайблах, в текстбоксах) должны иметь одни и те же FontFamily=”Tahoma” Font Size=”11”.
вот по этому пункту, сдается мне, достаточно все упоминания шрифтов в разных элементах поудалять и один раз в свойствах страницы написать FontFamily и FontSize. AP> Скриншот для указанной мной формы рисовал профессиональный дизайнер. Требуется в точности соблюсти все задумки дизайнера. Если какие-то правила лайаута не видны из рисунка, их можно уточнить у дизайнера (сейчас можно спросить у меня или посмотреть в C# код).
Я не уверена, что кто-то из ваших оппонентов обязался соблюдать все в точности и спрашивать у дизайнера или вашего кода. По-моему, большинство присутствующих считают, что достаточно показать принцип, а дальше вы сами сообразите.
В реальных проектах, программист ничего не спрашивает у дизайнера, потому что дизайнер сам все это сделает, а программист просто вставит в проект.
Ну или наоборот — я, например, делаю рыбу с триггерами, байндингами и т.п. вещами, которые нужны для правильного функционирования, а потом отдаю все дизайнеру и больше об этом не вспоминаю. Очень хорошо делится работа, не надо тратить время на уточнение, чего хотел дизайнер.
N>>Именно тут в xaml'е находится повторное использование без копипаста. И ваши две формочки из первого поста именно так и делаются, ничего копировать для этого не нужно (хотя их можно и другими способами без копипаста реализовать). AP>Ждем от Вас вариант формочки.
Времени нет. Если бы это обсуждение было в форуме про .Net, большинству сказанного было бы достаточно. Или автор вопроса сам предлагал бы варианты, а его поправляли бы. Это же публичный форум, а не техсаппорт.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Скриншот для указанной мной формы рисовал профессиональный дизайнер. Требуется в точности соблюсти все задумки дизайнера. Если какие-то правила лайаута не видны из рисунка, их можно уточнить у дизайнера (сейчас можно спросить у меня или посмотреть в C# код). Сейчас ваша реализация выглядит некрасиво. Отмазка, что Вы не прописывали все детали, не катит, поскольку кода Вы написали уже больше, чем в моей C# реализации.
Офигеть. Напоминает подход некоторых ПМ. Вам продемонстрировали принципиальную вещь. О соответствии разметке или чему-либо еще речи не шло. AP>То, что увидел при первом просмотре: AP>1. Текст “Fax:” должен быть прижат к правому краю.
Я в курсе. Больше 15 минут на данный пример тратить не хотелось. AP>2. В оригинале текст “State\province:” выдавливает свой текстбокс вправо. Но при этом текстбоксы для Fax и Country выровнены по линии. AP>3. Ширина колонки для лейблов должна выравниваться по максимальному тексту в колонке. У Вас же тупо захарткожено Width="100", причем для обоих колонок (ширина колонок необязательно одинакова). AP>4. Все три шрифта (в заголовке секции, в лайблах, в текстбоксах) должны иметь одни и те же FontFamily=”Tahoma” Font Size=”11”.
AP>Остальные комментарии позже.
Речь шла о темплейтах вроде как. Вы что написали? "Меня особенно интересует, как обойтись без копипаста". Вам написали аж два варианта(у Владека красивее). Теперь начались претензии по лайауту. Интересно, что будет дальше. У меня впечатление, что мы дальше и дальше отодвигаемся от темы беседы и скатываемся в обсуждение мелочей.
Пройдусь-ка по вашей реализации:
1.
new Grid().ColumnDefinitions(
new ColumnDefinition(),
new ColumnDefinition().Width(18),
new ColumnDefinition()).Nested(
Section("Customer", CustomerSection()).Grid_Position(0, 0),
Section("Dealer", DealerSection()).Grid_Position(0, 2))
Это будет себя вести не слишком правильно при ресайзе. Хардкод выделен.
2.
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto()).ColumnDefinitions(
new ColumnDefinition().Width_Auto(),
new ColumnDefinition(),
new ColumnDefinition().Width_Auto(),
Разметка в подобном стиле тоже ни к чему хорошему не приведет.
3.
private static TextBlock TextBlock(int row, int column)
{
return new TextBlock().Grid_Position(row, column).Margin(5, 0, 5, 0)
.MaxWidth(75).TextWrapping_Wrap().Execute(SetFontStyle)
.VerticalAlignment_Center();
}
Ну тут кагбэ тоже понятно. Вы мне тут где-то выше про хардкод писали, ога.
N>Ну и потом, почитайте, например документацию к FrameworkElementFactory — не все можно создать в коде просто по определению. N>ТОЛЬКО загрузить из xaml,
С этим история была такая. Про FrameworkElementFactory я прочитал еще почти в самом начале и подумывал об отказе от этого проекта. Но потом случайно наткнулся на вот эту статью и все же продолжил заниматься проектом. А вчера натолкнулся на то, что через FrameworkElementFactory нельзя установить Grid.RowDefinitions, поскольку это свойство не является dependency property. Но оказалось, что FrameworkElementFactory можно не использовать, а использовать вот такой метод
public static DataTemplate ToDataTemplate(this object obj)
{
return (DataTemplate)
XamlReader.Load(
XmlReader.Create(
new StringReader(
string.Format(
@"<DataTemplate xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation"">{0}</DataTemplate>",
XamlWriter.Save(obj)))));
}
C>Теперь начались претензии по лайауту. Интересно, что будет дальше. У меня впечатление, что мы дальше и дальше отодвигаемся от темы беседы и скатываемся в обсуждение мелочей.
Вы можете потратить еще несколько минут и внести исправления с учетом моих 4-х замечаний? Это может оказаться принципиальным.
AP>>4. Все три шрифта (в заголовке секции, в лайблах, в текстбоксах) должны иметь одни и те же FontFamily=”Tahoma” Font Size=”11”. N>вот по этому пункту, сдается мне, достаточно все упоминания шрифтов в разных элементах поудалять и один раз в свойствах страницы написать FontFamily и FontSize.
Известно, что использование наследования стиля через дерево элементов хуже при внесении изменений. В этом случае сложнее смотреть, откуда пришло то или иное значение стиля. Лучше явно прописывать, тогда простой Find Usage поможет вам увидеть что где используется и внести изменения так, чтобы ничего не поломать.
AP>>>4. Все три шрифта (в заголовке секции, в лайблах, в текстбоксах) должны иметь одни и те же FontFamily=”Tahoma” Font Size=”11”. N>>вот по этому пункту, сдается мне, достаточно все упоминания шрифтов в разных элементах поудалять и один раз в свойствах страницы написать FontFamily и FontSize. AP>Известно, что использование наследования стиля через дерево элементов хуже при внесении изменений. В этом случае сложнее смотреть, откуда пришло то или иное значение стиля. Лучше явно прописывать, тогда простой Find Usage поможет вам увидеть что где используется и внести изменения так, чтобы ничего не поломать.
Откуда это известно? Вы с WinForms работали? Там тоже каждому элементу руками шрифт прописывали? Или все-таки иногда достаточно было того, что шрифт для всей формы задан? А чем хуже-то? Если надо изменить шрифт для всей формы, что лучше — сделать это в одном месте один раз, или с find usage 33 раза?
По-моему, вы не поймете чужих объяснений, пока не попробуете самостоятельно свои две формочки в xaml'е сделать.
Возьмите пример Vladek'а и доведите до идеального состояния. Что не нравится — спрашивайте как исправить. Пока что вы по верхам скачете типа "Пастернака не читал, но осуждаю".
N>Вы с WinForms работали?
Я работал и с WinForms и c HTML/CSS. WinForms как layout engine это убожество.
N>Если надо изменить шрифт для всей формы, что лучше — сделать это в одном месте один раз, или с find usage 33 раза?
В 33 местах стоят ссылки, а значение храниться в одном месте. Find Usage вам показывает, где это используется, вы просматриваете, затем в 31 месте оставляете как есть, а в 2-х местах ставите новое значение или ссылку.
Здравствуйте, notacat, Вы писали:
N>По-моему, вы не поймете чужих объяснений, пока не попробуете самостоятельно свои две формочки в xaml'е сделать. N>Возьмите пример Vladek'а и доведите до идеального состояния.
Кстати да. Там довольно странный лайаут для state\province на скриншоте. Не знаю, насколько дизайнер профессионален, но в глаза бросается сильно.
Кароч. Финальная моя версия. Со state\province возиться не стал, потому что там разметка выглядит странно, мягко говоря. Более заниматься данным примером не буду. Автор топика, судя по всему- начинающий форумный тролль.
C>Кароч. Финальная моя версия. Со state\province возиться не стал, потому что там разметка выглядит странно, мягко говоря. Более заниматься данным примером не буду. Автор топика, судя по всему- начинающий форумный тролль.
Извиняюсь, просто хотелось получить побольше кода для сравнения. Это не совсем получилось, ну да ладно, остановимся на том, что уже написали.
Вернемся к вопросу реюза разметки для двух секций. Вы воспользовались готовыми GroupBox (а Vladek контролом HeaderedItemsControl). В принципе задача решена, но в этом решении не просматривается прием, который можно было бы применять в похожих задачках. WPF темплетирование, конечно, придает достаточно широкую гибкость, но все же при использовании конкретных контролов GroupBox и HeaderedItemsControl вы (возможно не отдавая в этом себе отчет) завязываетесь на специфику этих контролов. Т.е. в силу применяемого технического решения вносите лишние, не обусловленные самой задачей ограничения. А это порочная стратегия. Специфика контрола GroupBox состоит в том, он может принимать всего два “параметра” Header и вложенный Content. А что если потребуется передавать третий параметр? Например, надо будет разместить картинку вдоль правой вертикальной границы секции. Картинка должна указываться как параметр секции. В итоге вы придете к решению аля “master page”, описано, например, тут http://www.codeproject.com/KB/WPF/WPFMasterPageControl.aspx
Как я уже неоднократно писал, это слишком громоздко для такой простой проблемы. На C#-е это выльется просто в добавление третьего параметра в метод Section.
Здравствуйте, Alexander Polyakov, Вы писали:
C>>Кароч. Финальная моя версия. Со state\province возиться не стал, потому что там разметка выглядит странно, мягко говоря. Более заниматься данным примером не буду. Автор топика, судя по всему- начинающий форумный тролль. AP>Извиняюсь, просто хотелось получить побольше кода для сравнения. Это не совсем получилось, ну да ладно, остановимся на том, что уже написали.
AP>Вернемся к вопросу реюза разметки для двух секций. Вы воспользовались готовыми GroupBox (а Vladek контролом HeaderedItemsControl). В принципе задача решена, но в этом решении не просматривается прием, который можно было бы применять в похожих задачках. WPF темплетирование, конечно, придает достаточно широкую гибкость, но все же при использовании конкретных контролов GroupBox и HeaderedItemsControl вы (возможно не отдавая в этом себе отчет) завязываетесь на специфику этих контролов. Т.е. в силу применяемого технического решения вносите лишние, не обусловленные самой задачей ограничения. А это порочная стратегия. Специфика контрола GroupBox состоит в том, он может принимать всего два “параметра” Header и вложенный Content. А что если потребуется передавать третий параметр? Например, надо будет разместить картинку вдоль правой вертикальной границы секции. Картинка должна указываться как параметр секции. В итоге вы придете к решению аля “master page”, описано, например, тут http://www.codeproject.com/KB/WPF/WPFMasterPageControl.aspx AP>Как я уже неоднократно писал, это слишком громоздко для такой простой проблемы. На C#-е это выльется просто в добавление третьего параметра в метод Section.
По существу есть чего сказать? Или опять общие фразы из серии "не читал, но осуждаю"? Вы сами-то понимаете, насколько феерический бред Вы сейчас несете?
Реальная задача(с реальными объектами) решается несколько по-другому.WPF тем и хорош, что практически любую задачу можно решить несколькими способами.GroupBox(или HeaderedContentControl) взят для удобства.В общем, что я собственно хотел до вас донести, товарисч: вы можете сколько угодно допиливать свою реализацию XAML — вводить новые аргументы, параметры и т.д., но требуемой гибкости вы не достигнете никогда.
Тут еще куча вопросов неохваченных осталась:
1. Custom MarkupExtensions. Как их реализовывать.
2. Биндинги во всем их многообразии
3. Команды(куда ж без них)
4. Конвертеры
А про картинку как "параметр секции" мне тут заливать не надо. В большинстве сценариев ее можно реализовать внутри конкретного темплейта. В общем, утомился я что-то с Вами спорить, уважаемый. Я Вам про одно толкую, Вы мне совсем про другое. В общем, судя по всему, опыта в WPF у Вас прискорбно мало, что не может радовать в свете данной дискуссии.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>В принципе, может быть, достаточно создать общий темплетированный контрол скажем с 5-ю параметрами. Arg1, Arg2, …, Arg5.
Офигенный подход. Давайте еще создадим контрол с 40 параметрами. На все случаи жизни, так сказать. Или, как .Net 4.0 выйдет, Tuples туда прифигачим.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Вернемся к вопросу реюза разметки для двух секций. Вы воспользовались готовыми GroupBox (а Vladek контролом HeaderedItemsControl). В принципе задача решена, но в этом решении не просматривается прием, который можно было бы применять в похожих задачках. WPF темплетирование, конечно, придает достаточно широкую гибкость, но все же при использовании конкретных контролов GroupBox и HeaderedItemsControl вы (возможно не отдавая в этом себе отчет) завязываетесь на специфику этих контролов. Т.е. в силу применяемого технического решения вносите лишние, не обусловленные самой задачей ограничения. А это порочная стратегия. Специфика контрола GroupBox состоит в том, он может принимать всего два “параметра” Header и вложенный Content.
Здесь только одни возможности: этот контрол (а GroupBox отличается от HeaderedContentControl только своим видом в стиле визуальной темы ОС) представляет собой нечто, что имеет заголовок и содержимое. А всё остальное не ограничивается.
AP>А что если потребуется передавать третий параметр? Например, надо будет разместить картинку вдоль правой вертикальной границы секции. Картинка должна указываться как параметр секции.
Это будет частью шаблона контрола или частью содержимого контрола, которое в свою очередь будет состоять из подобного же контрола с заголовком, который (заголовок) будет представлен в виде картинки. Это всего лишь вопрос подходящей декомпозиции конечного результата на исходные составляющие и использование принципа самоподобия.
AP>В итоге вы придете к решению аля “master page”, описано, например, тут http://www.codeproject.com/KB/WPF/WPFMasterPageControl.aspx AP>Как я уже неоднократно писал, это слишком громоздко для такой простой проблемы. На C#-е это выльется просто в добавление третьего параметра в метод Section.
Если решение хоть и громоздкое, но его легко использовать — это хорошее решение. Master page из статьи, например, можно сделать с помошью двух HeaderedContentControl-ов, один из которых будет служить заголовком для второго. Принцип самоподобия и уместная декомпозиция.
V>...или частью содержимого контрола, которое в свою очередь будет состоять из подобного же контрола с заголовком, который (заголовок) будет представлен в виде картинки. Это всего лишь вопрос подходящей декомпозиции конечного результата на исходные составляющие и использование принципа самоподобия.
У Вас каждая из двух секций Customer и Dealer будет повторять вложение двух HeaderedItemsControl-ов друг в друга? Это и есть копипаст и неудобства развития и сопровождения.
Например, перемещение картинки внутрь первого заголовка у вас приведет к рефакторингу обеих секций Customer и Dealer. А в “логически чистой” реализации должно приводить только к рефакторингу тела самой секции (в одном месте); места использования секции не должны затрагиваться при внесении такого изменения.
Сделаю небольшое замечание. В задаче явно фигурирует понятие секции. Структура программного кода должна отражать это понятие (Это базовый принцип программирования). Если в каждом месте использовать по паре вложенных HeaderedItemsControl-ов, то в коде отсутствует понятие секции. Тем самым Вы пытаетесь не видеть понятия секции в задаче. Т.е. неправильная декомпозиция задачи на подзадачи. Отсюда и получаем стандартные следствия неправильной декомпозиции.
Делать такие вещи Вас заставляет выбранная технология -- XAML. А это одно из самых печальных явлений, когда не задача, а технология/инструмент ведет вас. Печально, потому что многие люди не отдают себе в этом отчет.
Здравствуйте, Alexander Polyakov, Вы писали:
V>>...или частью содержимого контрола, которое в свою очередь будет состоять из подобного же контрола с заголовком, который (заголовок) будет представлен в виде картинки. Это всего лишь вопрос подходящей декомпозиции конечного результата на исходные составляющие и использование принципа самоподобия. AP>У Вас каждая из двух секций Customer и Dealer будет повторять вложение двух HeaderedItemsControl-ов друг в друга? Это и есть копипаст и неудобства развития и сопровождения.
AP>Например, перемещение картинки внутрь первого заголовка у вас приведет к рефакторингу обеих секций Customer и Dealer. А в “логически чистой” реализации должно приводить только к рефакторингу тела самой секции (в одном месте); места использования секции не должны затрагиваться при внесении такого изменения.
AP>Сделаю небольшое замечание. В задаче явно фигурирует понятие секции. Структура программного кода должна отражать это понятие (Это базовый принцип программирования). Если в каждом месте использовать по паре вложенных HeaderedItemsControl-ов, то в коде отсутствует понятие секции. Тем самым Вы пытаетесь не видеть понятия секции в задаче. Т.е. неправильная декомпозиция задачи на подзадачи. Отсюда и получаем стандартные следствия неправильной декомпозиции.
AP>Делать такие вещи Вас заставляет выбранная технология -- XAML. А это одно из самых печальных явлений, когда не задача, а технология/инструмент ведет вас. Печально, потому что многие люди не отдают себе в этом отчет.
Жесть какая.Посмеялся, честно говоря. Диагноз ясен, озвучивать не буду.
AP>Сделаю небольшое замечание. В задаче явно фигурирует понятие секции. Структура программного кода должна отражать это понятие (Это базовый принцип программирования). Если в каждом месте использовать по паре вложенных HeaderedItemsControl-ов, то в коде отсутствует понятие секции. Тем самым Вы пытаетесь не видеть понятия секции в задаче. Т.е. неправильная декомпозиция задачи на подзадачи. Отсюда и получаем стандартные следствия неправильной декомпозиции.
Вы уж определитесь — мы в форуме что-то обсуждаем, или вы нас при приеме на работу тестируете? Никто себе не ставил целью Вашу задачу декомпозировать и тем более телепатией заниматься. Если вам очень хотелось иметь в примерах замла это понятие — надо было об этом писать ДО того, а не ПОСЛЕ.
Даю подсказку. Если очень хочется иметь понятие секции, пишется свой контрольчик с названием Секция и имеете счастье. Это просто — чуть-чуть кода и может быть чуть-чуть xaml'а. Главное правильно выбрать, от чего унаследоваться.
Вы не пытайтесь убедить других, что xaml плох, вы попытайтесь лучше понять, почему они с вами не согласны.
Может другим путем пойти? Давайте попросим кого-нибудь выложить хороший с его точки зрения пример на xaml'е с перечнем требований типа — никаких явных заданий свойств в каждом месте, плавающая разметка, возможность отдать отдельную часть работы дизайнеру на причесывание, и т.п.
А вы все это реализуете в коде. Вот потом и посравниваем, что получится.
Здравствуйте, Alexander Polyakov, Вы писали:
V>>...или частью содержимого контрола, которое в свою очередь будет состоять из подобного же контрола с заголовком, который (заголовок) будет представлен в виде картинки. Это всего лишь вопрос подходящей декомпозиции конечного результата на исходные составляющие и использование принципа самоподобия. AP>У Вас каждая из двух секций Customer и Dealer будет повторять вложение двух HeaderedItemsControl-ов друг в друга? Это и есть копипаст и неудобства развития и сопровождения.
Если секции будут подобны, они будут сделаны с помощью общего шаблона.
AP>Например, перемещение картинки внутрь первого заголовка у вас приведет к рефакторингу обеих секций Customer и Dealer. А в “логически чистой” реализации должно приводить только к рефакторингу тела самой секции (в одном месте); места использования секции не должны затрагиваться при внесении такого изменения.
Если шаблон будет общим, рефакторинг коснётся только его.
AP>Сделаю небольшое замечание. В задаче явно фигурирует понятие секции. Структура программного кода должна отражать это понятие (Это базовый принцип программирования). Если в каждом месте использовать по паре вложенных HeaderedItemsControl-ов, то в коде отсутствует понятие секции. Тем самым Вы пытаетесь не видеть понятия секции в задаче. Т.е. неправильная декомпозиция задачи на подзадачи. Отсюда и получаем стандартные следствия неправильной декомпозиции.
Не путайте модель предметной области и элементы интерфейса. Имея в виду пример, рискну предположить, что Customer и Dealer являются частью модели предметной области, а секция относится к интерфейсу. И да, тогда понятие секции в коде фигурировать не будет, там будут только классы Customer и Dealer. Зато в XAML будет описано как именно отображать такие объекты, как Customer или Dealer — в виде секций или как-нибудь ещё.
Другими словами, каждый слой моделирования задачи обладает своей степью абстракции. Чем ближе к интерфейсу, тем абстракции конкретнее и подробнее. Например: в сделке принимают участие клиент и торговец, участники сделки отображаются на экране в виде секций. Одна цель — совершить акт сделки, другая — отобразить детали её совершения. Первое — относится к предметной области задачи, второе — к интерфейсу. Секция не участвует в сделке, в предметной области ей не место, понятие секции возникает лишь при отображении заказчика и торговца.
AP>Делать такие вещи Вас заставляет выбранная технология -- XAML. А это одно из самых печальных явлений, когда не задача, а технология/инструмент ведет вас. Печально, потому что многие люди не отдают себе в этом отчет.
WPF наоборот позволяет использовать такой замечательный архитектурный шаблон, как Model-View-ViewModel, благодаря шаблонам данных и связыванию данных, что ведёт к полному разграничению модели предметной области и элементов интерфейса.
Здравствуйте, Alexander Polyakov, Вы писали:
C>>Жесть какая.Посмеялся, честно говоря. Диагноз ясен, озвучивать не буду. AP>Вы, действительно, не видите дублирование кода?
Вам более компетентные и выдержанные товарищи уже ответили.Не путайте божий дар с яичницей, уважаемый. Как правильно сказали выше, в данной задаче к предметной области относятся Customer и Dealer, остальное не более чем отображение. С какого перепоя я должен вводить в предметную область Section, неясно. А если завтра UI радикально поменяется, и надо будет отображать данные совсем по-другому(а такое случается, особенно на стадии прототипирования)?Вы тут много и пространно говорите о дублировании кода, копипасте и т.п., не учитывая одной простой вещи — ваш код, в принципе, тот же копипаст. Потому как с вашей точки зрения два разных темплейта, определенных для одного объекта — это уже копипаст. Третий темплейт — уже зло, не так ли? С моей точки зрения зло — плодить лишние сущности в коде, чрезмерно усложняя и раздувая его. То, что может быть сделано в XAML — должно быть там сделано. Нельзя логику отображения мешать с остальным кодом. Нельзя связывать объекты с их отображением, потому что один и тот же объект может быть отображен сотней-другой разных способов(в одном и том же проекте причем).И последнее. Стиль общения, имхо, стоит сменить на более нейтральный. На этом форуме Вам никто ничего не должен. То, что люди делают, они делают из интереса, а не потому, что их кто-то заставляет. Опять же, не стоит путать вещи, принципиальные для дискуссии, с вещами непринципиальными(типа разметки, которой Вы, если честно, выели мне мозг).
Я очень не завидую Вашим подчиненным, если они у Вас есть.
V>Если секции будут подобны, они будут сделаны с помощью общего шаблона.
Не могли бы вы пояснить это подробнее. У секции есть три переменные величины: заголовок, содержание и картинка. В темплейте для HeaderedItemsControl есть всего две “дырки” Header и Content. О каком общем шаблоне вы говорите?
Здравствуйте, Alexander Polyakov, Вы писали:
V>>Если секции будут подобны, они будут сделаны с помощью общего шаблона. AP>Не могли бы вы пояснить это подробнее. У секции есть три переменные величины: заголовок, содержание и картинка. В темплейте для HeaderedItemsControl есть всего две “дырки” Header и Content. О каком общем шаблоне вы говорите?
Здравствуйте, Vladek, Вы писали:
V>>>Если секции будут подобны, они будут сделаны с помощью общего шаблона. AP>>Не могли бы вы пояснить это подробнее. У секции есть три переменные величины: заголовок, содержание и картинка. В темплейте для HeaderedItemsControl есть всего две “дырки” Header и Content. О каком общем шаблоне вы говорите?
V>DataTemplate для пользовательских классов.
V>
V>public class Section
V>{
V> public string Caption { get; set; }
V> public string Content { get; set; }
V> public string Image { get; set; }
V>}
V>
Какое-то феерическое непонимание. То, что вы написали совершенно не по теме. Вопрос был задан в контексте нашего разговора, т.е. относится все к той же формочке и из первого поста. Не понятно, зачем Вы приводите пользовательский класс Section со стринговым Content-ом и демонстрируете элементарный байндинг. В нашем примере Content у секции это набор текстбоксов с лейблами. Понятие секции, которое я упомянул, логическое понятие пользовательского интерфейса.
Пользователь notacat почему-то сразу поняла, о чем речь
Если вам очень хотелось иметь в примерах замла это понятие — надо было об этом писать ДО того, а не ПОСЛЕ. ... Если очень хочется иметь понятие секции, пишется свой контрольчик с названием Секция и имеете счастье. http://www.rsdn.ru/forum/design/3548131.1.aspx
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Какое-то феерическое непонимание. То, что вы написали совершенно не по теме. Вопрос был задан в контексте нашего разговора, т.е. относится все к той же формочке и из первого поста. Не понятно, зачем Вы приводите пользовательский класс Section со стринговым Content-ом и демонстрируете элементарный байндинг. В нашем примере Content у секции это набор текстбоксов с лейблами. Понятие секции, которое я упомянул, логическое понятие пользовательского интерфейса.
Это был рафинированный пример отображения объекта из модели предметной области с помощью шаблона данных. Если мы отображаем на экране объект Customer, то все его свойства таким же макаром можно будет отобразить в виде секции с заголовком, текстбоксами и лейблами. Писать дополнительные классы для "логических понятий интерфейса" типа "секции" не потребуется. Повторяющиеся куски разметки можно будет выделить в отдельные шаблоны данных и стили.
Глянул ещё раз в пример. Так и есть, объекты Customer и Dealer не существуют. Вместо этого есть холостой UI. Смоделируйте-ка два этих класса, Customer и Dealer, создайте по одному экземпляру, заполните их данными, и перепишите форму так, что бы в ней можно было редактировать эти объекты. Тогда ваш пример будет полноценным, а обсуждать пустую разметку смысла нет — ясен пень, что нарисовать можно что-угодно и как-угодно.
AP>Пользователь notacat почему-то сразу поняла, о чем речь AP>
AP>Если вам очень хотелось иметь в примерах замла это понятие — надо было об этом писать ДО того, а не ПОСЛЕ. ... Если очень хочется иметь понятие секции, пишется свой контрольчик с названием Секция и имеете счастье.
AP>http://www.rsdn.ru/forum/design/3548131.1.aspx
Во-первых, XAML гораздо сложнее HTML, к тому же, у них разная функциональность, разные основополагающие идеи и разный подход к реализации. Во-вторых, для обычного дизайнера (не «веб-дизайнера») и то, и другое будет китайской грамотой без специальной подготовки.
C>Не путайте объектную модель с отображением. Это две разных вещи.
Не путайте объектную модель с объектной моделью. Когда я пишу
<Control Width="200" Height="300"/>
я создаю объект класса Control, и задаю ему свойства Width и Height. А класс Control входит в объектную модель WPF (в объектную модель отображения, если хотите).
C>Неверное утверждение. Дизайнер в XAML пишет внешний вид, все остальное на откуп программисту(биндинги и пр.). XAML — язык для верстки.
Во-первых, внешний вид в XAML пишет специально обученный дизайнер (если у него вообще получилось освоить этот XAML), а во-вторых, если что-то в XAML будет делать еще и программист, то это будет противоречить той основной идее, ради которой XAML, по заявлению Microsoft, и создавался, а именно, они подразумевали, что XAML будет редактировать дизайнер.
C>Человеческий мозг так устроен, что ему проще видеть целую картину из некоего декларативного описания(HTML,XAML,XML etc), чем из нескольких сотен строчек кода, которые очень тяжело визуализировать во внятную картинку. А в целом, если кодогенератор данный позволяет реализовать все(я подчеркиваю, все) сценарии, реализуемые в XAML, почему бы и нет.
Человеческий мозг устроен так (тем более, мозг дизайнера), что ему проще видеть картину, чем декларативное описание. А декларативное (или императивное) описание обычно понимают только программисты, или те, кто освоил программирование в достаточном объеме.
Кстати, опять этот дурацкий термин «декларативный». Попробуйте-ка формально определить, чем отличается декларативное описание от императивного. Ничего не выйдет, потому что ничем не отличаются.
Императивный-де — это конкретная последовательность команд. А декларативный-де — это описание того, что требуется сделать. Дескать, императивный говорит «как сделать», а декларативный — «что сделать».
Вот это как бы императивно:
1. Встаньте со стула;
2. Отодвиньте стул от стола.
А это — как бы декларативно?
1. Требуется встать со стула;
2. Требуется отодвинуть стул от стола.
Первая запись на XAML — якобы, «декларативна», а вторая — на C# (полностью эквивалентная) — уже, почему-то, «императивна»:
<Control Width="200" Height="300"/>
Controls.Add(new Control { Width=200, Height=300 });
А на F#, кстати, она уже должна стать «декларативной», как ни крути.
C>Проблемы тут начнутся на больших приложениях с развесистым UI. Вот тут редактирование и изменение может превратиться в реальный кошмар. Я бы проект, написанный подобным образом, править бы не решился.
Кстати, как правильно заметил топикстартер, практика показывает, что проблемы как раз начинаются на больших приложениях с развесистым UI.
Строго говоря, даже если UI очень большой, не бывает так, чтобы он в каждой своей части был полностью уникален, обычно в нем существуют четкие закономерности. Так вот для выражения таких закономерностей упрощенные средства вроде XAML плохо подходят в силу своей ограниченности.
Примеров много можно привести. Например, настраиваемые меню и панели инструментов. XAML позволяет в простейшем варианте легко придать любой дизайн какому-нибудь меню, панели инструментов или окну. Но когда нужно сделать, чтобы это же меню настраивалось пользователем, причем интерактивно, его можно было бы перетаскивать в окне, или менять его поведение в интерфейсе (сделать окно «плавающим» или прикрепленным к определенному месту экрана). Естественно, все настройки должны сохраняться в файле пользовательских настроек. При этом интерфейс должен поддерживать стили («скины»), которые могут поставляться отдельно.
На самом деле, легко увидеть, что введение многочисленных требований, присущих реальным программам, делает гибкость XAML отчасти бесполезной, поскольку без специального кодирования в этих задачах все равно не обойтись, а мощь XAML оказывается весьма ограниченной.
Интересно что:
1. Трое программистов не увидели правильную декомпозицию UI-я. На мой взгляд, это является следствием того, что программисты думали в терминах XAML-а.
2. Двое программистов написали код, в котором реализовано решение, которое не выживает при следующем изменении задачи -- добавление третьей изменяемой части к секции. Указанное изменение можно внести только при полной замене указанного решения.
3. Один из программистов внес указанное изменение таким образом, что получилось дублирование кода.
Ну что ж, как и ожидалось, получили классические примеры низкого качества кодирования. Термины типа “реальная задача(с реальными объектами) решается несколько по-другому
” не верно отражают ситуацию. Было продемонстрировано, действительно, низкое качество кодирования.
N>Никто себе не ставил целью Вашу задачу декомпозировать и тем более телепатией заниматься. Если вам очень хотелось иметь в примерах замла это понятие — надо было об этом писать ДО того, а не ПОСЛЕ.
Ха , ситуация тут не настолько прямолинейна. Реализовывая эту формочку на C#, я не задумывался, как декомпозировать формочку, я сразу кодировал (см. Приложение 2). У меня понятие секции появилось, когда я уже был глубоко в процессе кодирования. Поэтому я и вам предложил первоначальную задачу. Суть состоит в том, что кодирование на C#-е меня привело к правильной декомпозиции задачи, а кодирование на XAML-е привело программистов к неправильной декомпозиции.
N>Даю подсказку. Если очень хочется иметь понятие секции, пишется свой контрольчик с названием Секция и имеете счастье. Это просто — чуть-чуть кода и может быть чуть-чуть xaml'а. Главное правильно выбрать, от чего унаследоваться.
В этом то и дело, что на XAML-е “если очень хочется”, а на C# это примитивная, само собой разумеющаяся вещь. Как я уже отмечал, решение аля master page слишком громоздко, трудоемко, сложнее в сопровождении и т.п. Решение на C# (см. Приложение 2) выполняется в течение одной минуты, причем вероятность сделать хотя бы одну ошибку крайне мала, т.е. получаем рабочий вариант без запуска приложения даже без компиляции. Обратная задача Inline Method также выполняется автоматически ReSharper-ом. Для решения аля master page на XAML-е вышесказанное не выполняется.
N>Может другим путем пойти? Давайте попросим кого-нибудь выложить хороший с его точки зрения пример на xaml'е с перечнем требований типа — никаких явных заданий свойств в каждом месте, плавающая разметка, возможность отдать отдельную часть работы дизайнеру на причесывание, и т.п.
Да было бы здорово, если кто-нибудь выложил такой пример. Только требования надо сделать нейтральными к средству исполнения: >никаких явных заданий свойств в каждом месте
Заменить на, избегать дублирования значений свойств. >возможность отдать отдельную часть работы дизайнеру на причесывание
Это следует убрать. По поводу дизайнера, разделения труда и т.п. обсуждение уже было в первом треде
. Слегка утрируя, результат обсуждения такой, никто так и не смог доказать существование таких дизайнеров и такого разделения труда. Да и на рынке труда таких дизайнеров пока не заметно.
И так, с кодированием секций разобрались. Осталось разобраться с организацией стилей: множественное наследование и т.д. Об этом напишу отдельный пост чуть позже.
Приложение 1: Прямого указания на согласие Codechanger-а нет, но, насколько я понял, его позиция совпадает с позицией Vladek-а.
Приложение 2: Моя последовательность действий была проста и прямолинейна. Я взял первую по порядку секцию, и реализовал ее. Затем перешел ко второй. Опа, а тут надо писать тот же код, который у меня уже есть. С помощью ReShrper-а выполняю следующую последовательность Extract Method->Extract Parameter (content)->Extract Parameter (header). Использую полученный метод второй раз и продолжаю реализовывать вторую секцию.
Вы почему-то отождествляете путанность своих мыслей с архитектурой. Вряд ли вам кто-то с этим поможет.
Не буду тут писать своих "ха" по поводу ваших умных мыслей. У вас гвоздями вбито, что в xaml все сложно, а в ваших методах — все просто. Мне лично кажется — что все ровно наоборот и бОльшей дикости, чем вы сделали — трудно придумать.
>>возможность отдать отдельную часть работы дизайнеру на причесывание AP>Это следует убрать. По поводу дизайнера, разделения труда и т.п. обсуждение уже было в первом треде
. Слегка утрируя, результат обсуждения такой, никто так и не смог доказать существование таких дизайнеров и такого разделения труда. Да и на рынке труда таких дизайнеров пока не заметно.
Для тупых еще раз повторю — вот у нас в команде есть такой дизайнер и если у вас его нет — это ваши проблемы.
Для меня это требование первое в списке. И не только из-за наличия отстутсвия дизайнера у нас в команде, а еще и потому, что большинство людей, которые покупают наши контролы, вполне понимают, зачем нужен xaml, и очень хорошо этим знанием пользуются.
Учите матчасть, а если не согласны — попробуйте свое произведение кому-нибудь продать, потом расскажете о результатах.
Я больше не участвую.
N>... У вас гвоздями вбито, что в xaml все сложно, а в ваших методах — все просто. Мне лично кажется — что все ровно наоборот ...
В последнем моем сообщении, на которое Вы отвечаете, речь не обо “ВСЕМ”, а всего лишь об отдельно взятом примере -- о кодировании двух секций.
Здравствуйте, Тролль-323, Вы писали:
Т3>Вот это как бы императивно:
Т3>1. Встаньте со стула; Т3>2. Отодвиньте стул от стола.
Т3>А это — как бы декларативно?
Т3>1. Требуется встать со стула; Т3>2. Требуется отодвинуть стул от стола.
Нет, это тоже императивно.
Декларативно — это так:
1. Субъект должен стоять прямо
2. Стул должен быть на расстоянии 0.6 метра от стола
А уж будет ли кто-то вставать, будет ли отодвигать стул он, или кто-то другой, или стул вообще унесут и принесут другой сразу на нужное место — это излишние подробности.
И вся декларативность кзамла — как раз в том, что в нём нельзя написать между "стоять прямо" и "стул на расстоянии 0.6 метра от стола" какую-нибудь чушь типа "повернитесь вокруг своей оси три раза". Благодаря этому получаем возможность править состояние сцены в редакторе — к примеру, заменить 0.6 метра на 0.1 метра, или заменить "стоять прямо" на "сидеть на корточках". Редактору кзамла легко исправить декларативную запись, потому что в ней нет побочных эффектов.
Исправить текст на C# визуальному редактору гораздо сложнее — как раз потому, что он не может быть уверен в отстутствии побочных эффектов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Декларативно — это так: S>1. Субъект должен стоять прямо S>2. Стул должен быть на расстоянии 0.6 метра от стола
Эта программа не эквивалентна оригинальной императивной.
Для этой программы эквивалентом будет такая императивная:
1. Сделать, чтобы субъект стоял прямо,
2. Сделать, чтобы стул был на расстоянии 0.6 метра от стола.
(Как вы заметили, она отличается от декларативной, в основном, словом «сделать»).
S>А уж будет ли кто-то вставать, будет ли отодвигать стул он, или кто-то другой, или стул вообще унесут и принесут другой сразу на нужное место — это излишние подробности.
Вот именно, ваша программа просто более высокоуровневая.
S>Редактору кзамла легко исправить декларативную запись, потому что в ней нет побочных эффектов.
Это не так, поскольку XAML, фактически, является просто интерпретируемым объектно-ориентированным языком программирования с ограниченными возможностями.
Когда в документации Microsoft говорят, что он декларативный — они просто врут.
C>В общем, по результатам обсуждения программисты делятся на две категории: C> те, кто XAML не любят и те, кто в нем разобрался...
У меня сложилось ровно противоположное впечатление. Те, кто выступает за XAML не далеко ушли от tutorial-ов. Они не продемонстрировали (и даже не упомянули) приемы, которые важны при разработке серьезных приложений.
C> ... те, кто XAML не любят и те, кто в нем разобрался...
Вы можете привести 2-3 ссылки, из которых было бы видно, что те, кто указывает на недостатки XAML-а, не разобрались с этим языком?
C> ... кто в нем разобрался...
Это Вы о тех, кто предлагает вот такие решения?
AP>А что если потребуется передавать третий параметр? Например, надо будет разместить картинку вдоль правой вертикальной границы секции. Картинка должна указываться как параметр секции.
Это будет частью шаблона контрола или частью содержимого контрола, которое в свою очередь будет состоять из подобного же контрола с заголовком, который (заголовок) будет представлен в виде картинки. Это всего лишь вопрос подходящей декомпозиции конечного результата на исходные составляющие и использование принципа самоподобия. http://www.rsdn.ru/forum/design/3547732.1.aspx
C>В общем, по результатам обсуждения программисты делятся на две категории: C> те, кто XAML не любят и те, кто в нем разобрался...
Вот это далеко не мой случай. Я не только в нем разобрался, но и написал аналогичную, работающую по таким же принципам (конечно, не такую мощную) систему для C++.
Здравствуйте, Alexander Polyakov, Вы писали:
C>>В общем, по результатам обсуждения программисты делятся на две категории: C>> те, кто XAML не любят и те, кто в нем разобрался... AP>У меня сложилось ровно противоположное впечатление. Те, кто выступает за XAML не далеко ушли от tutorial-ов. Они не продемонстрировали (и даже не упомянули) приемы, которые важны при разработке серьезных приложений.
Я повторюсь:
Глянул ещё раз в пример. Так и есть, объекты Customer и Dealer не существуют. Вместо этого есть холостой UI. Смоделируйте-ка два этих класса, Customer и Dealer, создайте по одному экземпляру, заполните их данными, и перепишите форму так, что бы в ней можно было редактировать эти объекты. Тогда ваш пример будет полноценным, а обсуждать пустую разметку смысла нет — ясен пень, что нарисовать можно что-угодно и как-угодно.
Дайте нам шанс таки-продемонстрировать приёмы, которые важны при разработке серьёзных приложений, приблизив пример к реальной жизни.
AP>У меня сложилось ровно противоположное впечатление. Те, кто выступает за XAML не далеко ушли от tutorial-ов. Они не продемонстрировали (и даже не упомянули) приемы, которые важны при разработке серьезных приложений.
Ну, батенька, если вы спросите меня, как приготовить манную кашу, я вряд ли догадаюсь вам объяснить, что в конце ее надо положить в тарелку, а потом ложкой есть, и как ложку держать..
Вам непременно хочется, чтобы в форумах кто-то догадался о том, что вы чего-то не понимаете и превентивно разжевал, да еще и в рот положил?
Вы придумали какой-то частный случай без претензий, вам в таком же стиле и ответили. При этом ответов было несколько и разных, умному — достаточно, дураку — бесполезно жевать дальше. Во всяком случае, Вы в продолжение дискуссии ни одного умного вопроса по теме не задали, поэтому все тишиной и закончилось.
Это, знаете ли, в саппорт люди иногда пишут — "помогите подключить мои кнопки" — так и то, прежде чем отвечать, убеждаешься, что человек купил продукт с саппортом в том числе, чтобы зря время не тратить на чужое образование. А вы захотели бесплатно.
Сделайте так, чтобы людям было интересно с вами разговаривать, подумайте прежде чем говорить, глядишь, у кого-нибудь возникнет желание упомянуть "приемы, которые важны при разработке серьезных приложений". А еще лучше, воспользуйтесь поиском по RSDN и почитайте старые дискуссии на похожие темы. Много того, что вам неясно, уже обсуждалось (ищите только по всем форумам, а не только по этому).
N>Много того, что вам неясно, уже обсуждалось (ищите только по всем форумам, а не только по этому).
Вы можете привести 2-3 цитаты из моих постов, из которых было бы видно, что мне что-то неясно? А то не понятно, о чем идет речь в вашем сообщении.
Всего было два вопроса:
1. про секции
2. организация стилей (множественное наследование)
Кодирование секций закончилось вот этим
Все участники согласились (см. Приложение 1) с тем, что правильным решением является решение аля master page, на которое я указывал еще месяц назад
V>Смоделируйте-ка два этих класса, Customer и Dealer, создайте по одному экземпляру, заполните их данными, и перепишите форму так, что бы в ней можно было редактировать эти объекты.
public class Customer: INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
public string Name { get{ throw new NotImplementedException();} set{ throw new NotImplementedException();} }
public string ContactName { get { throw new NotImplementedException(); } set { throw new NotImplementedException(); } }
public string Phone { get { throw new NotImplementedException(); } set { throw new NotImplementedException(); } }
public string Fax { get { throw new NotImplementedException(); } set { throw new NotImplementedException(); } }
public string Address { get { throw new NotImplementedException(); } set { throw new NotImplementedException(); } }
public string City { get { throw new NotImplementedException(); } set { throw new NotImplementedException(); } }
}
public class Dealer : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
public string FirstContactName { get { throw new NotImplementedException(); } set { throw new NotImplementedException(); } }
public string SecondContactName { get { throw new NotImplementedException(); } set { throw new NotImplementedException(); } }
}
Этого достаточно? Если да, то ждем от Вас код для формочки из первого поста с возможностью добавления третьей переменной части секции. Можно схематично.
N>>Много того, что вам неясно, уже обсуждалось (ищите только по всем форумам, а не только по этому). AP>Вы можете привести 2-3 цитаты из моих постов, из которых было бы видно, что мне что-то неясно?
Без цитат.
Я понимаю, что вы уверены, что вам все ясно. А с другой стороны, то, что вы пишете про эту ясность, типа "отсутствует понятие секции" — это абсолютно неверное понимание ситуации. Вашу задачку можно решить ста способами. В зависимости от того, частью чего эта задачка является, какой-то конкретный способ может быть хорош или плох. Вам предложили несколько вариантов в надежде, что вы идею поймете. Вы же начинаете цепляться к частностям и объявлять "понятие секции" единственно верным. Тупик какой-то. Потому что на этом месте полностью исчезает предмет обсуждения. Если что-то уже единственно верно и других людей вы не слышите, то зачем другим людям пытаться продолжать диалог? Есть бОлее интересные занятия.
Вот я вам предложила попробовать решить задачу с учетом моих требований, так вы сразу сказали, что самое важное требование "необходимо исключить, потому что это заведомо никому не нужно". Ну как и о чем можно дальше разговаривать? Может, если вам все ясно, обоснуете, почему мои требования плохи? Или вы просто не желаете их понимать?
На всякий случай еще раз: отделение дизайна в отдельный слой и возможность дизайнеру самостоятельно с этим слоем работать — это не фантазия MS, и не фикция, а вполне реальная вещь, с которой люди работают уже не первый год. И более того, дизайнеры работают не в Visual Studio, а в отдельных пакетах. Возьмите триаловскую версию Бленда, поглядите — и xaml есть, и дизайн превью, и довольно много инструментов. И Бленд — это тоже не последняя точка. Посмотрите в Бленде на такие фичи, как "создать копию темплейта" и т.д.. Как бы так сказать, чтобы дошло? В наших коммерческих продуктах — это действительно реальное требование. И наши юзеры, которые покупают наши контролы за деньги, действительно работают с xaml'ом в дизайнере и действительно есть реальные дизайнеры (не программисты), которые этим всем занимаются.
В конце концов, попробуйте освоить фотошоп на хорошем уровне. Это же гораздо сложней, чем xaml. Если дизайнер умеет пользоваться графическими пакетами, с чего вдруг ему будет сложно работать с xaml'ом? Поучится немного и научится. Когда мы только начинали WPF заниматься, наш дизайнер смог более-менее самостоятельно что-то делать уже через пару месяцев. А сейчас уже вообще никаких вопросов не возникает.
С чего вдруг нарисовать какой-нибудь заковыристый Path в коде может быть проще, чем то же самое сделать дизайнеру в специальном пакете? Сколько нужно человеко-часов, чтобы программист выяснил у дизайнера, как это должно выглядеть, и нарисовал то же самое в коде?
Простая же формула:
В наших проектах время, затраченное дизайнером, равно времени, затраченному на отрисовку UI.
При вашем подходе к этому времени добавляется еще время, затраченное программистом, и время, затраченное на терки программиста с дизайнером.
Умножьте на почасовую ставку и поймите, чего вы не понимаете.
N>... Вашу задачку можно решить ста способами. В зависимости от того, частью чего эта задачка является, какой-то конкретный способ может быть хорош или плох. ...
Тем самым у вас растет связность -- у вас наличие остальных частей сущности (в данном случае формы) влияет на способ реализации маленькой части. А мне как раз интересны приемы, которые не приводят к росту связности. То есть, интересны такие способы, которые хороши вне зависимости от того, частью чего является задачка. Уменьшение связности критично при разработке больших проектов. Это я и имел ввиду, когда говорил “приемы, которые важны при разработке серьезных приложений”.
N>На всякий случай еще раз: отделение дизайна в отдельный слой и возможность дизайнеру самостоятельно с этим слоем работать — это не фантазия MS, и не фикция, а вполне реальная вещь, с которой люди работают уже не первый год. И более того, дизайнеры работают не в Visual Studio, а в отдельных пакетах. Возьмите триаловскую версию Бленда, поглядите — и xaml есть, и дизайн превью, и довольно много инструментов. И Бленд — это тоже не последняя точка. Посмотрите в Бленде на такие фичи, как "создать копию темплейта" и т.д.. Как бы так сказать, чтобы дошло? В наших коммерческих продуктах — это действительно реальное требование. И наши юзеры, которые покупают наши контролы за деньги, действительно работают с xaml'ом в дизайнере и действительно есть реальные дизайнеры (не программисты), которые этим всем занимаются. N>В конце концов, попробуйте освоить фотошоп на хорошем уровне. Это же гораздо сложней, чем xaml. Если дизайнер умеет пользоваться графическими пакетами, с чего вдруг ему будет сложно работать с xaml'ом? Поучится немного и научится. Когда мы только начинали WPF заниматься, наш дизайнер смог более-менее самостоятельно что-то делать уже через пару месяцев. А сейчас уже вообще никаких вопросов не возникает. N>С чего вдруг нарисовать какой-нибудь заковыристый Path в коде может быть проще, чем то же самое сделать дизайнеру в специальном пакете? Сколько нужно человеко-часов, чтобы программист выяснил у дизайнера, как это должно выглядеть, и нарисовал то же самое в коде? N>Простая же формула: N>В наших проектах время, затраченное дизайнером, равно времени, затраченному на отрисовку UI. N>При вашем подходе к этому времени добавляется еще время, затраченное программистом, и время, затраченное на терки программиста с дизайнером. N>Умножьте на почасовую ставку и поймите, чего вы не понимаете.
По поводу дизайнера тут тонкие моменты, поэтому отвечу чуть позже.
N>>... Вашу задачку можно решить ста способами. В зависимости от того, частью чего эта задачка является, какой-то конкретный способ может быть хорош или плох. ... AP>Тем самым у вас растет связность -- у вас наличие остальных частей сущности (в данном случае формы) влияет на способ реализации маленькой части. А мне как раз интересны приемы, которые не приводят к росту связности.
Да с чего вдруг она растет? Я же не про это.
Ваши две формы в чистом виде можно нарисовать за полчаса. Если этим задача ограничивается, то способ вообще не имеет значения, лишь бы он в полчаса реализации укладывался. А если эти две формы будут частью приложения, в котором 200 подобных форм, то я возьму датагрид, который уже умеет карточки рисовать, и задача будет решена в общем виде с минимальной связностью. При этом каждый первый WPF датагрид будет использовать внутри себя xaml. В этом варианте я буду думать только про свои данные и (может быть) немного про темплейты.
Ну а в промежутке может быть масса вариантов. Не для каждой задачи надо выдумывать сущности.
Понимаете в чем дело? Вы начали обсуждать c# и xaml, а теперь скатились к связности. А это же вообще перпендикулярно, можно в шарпе все плохо сделать, а можно в xaml'е никаких архитектурных принципов не нарушить. Так что мы обсуждаем?
N>>... Вам предложили несколько вариантов в надежде, что вы идею поймете. ... AP>Идею я понял, и подробно описал ее недостатки.
Там нет недостатков, которые вы описали. Вы описываете недостатки конкретных маленьких примеров, а не идеи.
Вот если бы вы начали с того, что сделали дизайн просто в терминах ООП и разговаривали об этом, то вам бы и примеры дали близкие к тому, чего вы хотите. Вы же начала разговор с двух формочек, а потом поплыли с одного на другое. А остальным уже не интересно дальше плавать. Конечно, я могу ошибаться.
N>Там нет недостатков, которые вы описали. Вы описываете недостатки конкретных маленьких примеров, а не идеи.
Идея была использовать недоступный для изменений готовый контрол HeaderedContentControl. И вкладывать HeaderedContentControl-ы друг в друга. Это кривизна, было описано почему.
N>Вот если бы вы начали с того, что сделали дизайн просто в терминах ООП и разговаривали об этом, то вам бы и примеры дали близкие к тому, чего вы хотите. Вы же начала разговор с двух формочек, а потом поплыли с одного на другое. А остальным уже не интересно дальше плавать. Конечно, я могу ошибаться.
Еще раз повторю заниматься декомпозицией (я так понял, Вы это назвали ООП) просто так ради самой декомпозиции никому не нужно. И я сам стою на этой позиции. К декомпозиции я обратился только для того, чтобы показать, в чем кривизна предложенного решения. Моя позиция такая, что если выбран хороший инструмент, то о правильной декомпозиции можно не беспокоится, она сама будет вырисовываться при использовании простых приемчиков.
Здравствуйте, Alexander Polyakov, Вы писали:
N>>Вот если бы вы начали с того, что сделали дизайн просто в терминах ООП и разговаривали об этом, то вам бы и примеры дали близкие к тому, чего вы хотите. Вы же начала разговор с двух формочек, а потом поплыли с одного на другое. А остальным уже не интересно дальше плавать. Конечно, я могу ошибаться. AP>Еще раз повторю заниматься декомпозицией (я так понял, Вы это назвали ООП) просто так ради самой декомпозиции никому не нужно. И я сам стою на этой позиции. К декомпозиции я обратился только для того, чтобы показать, в чем кривизна предложенного решения. Моя позиция такая, что если выбран хороший инструмент, то о правильной декомпозиции можно не беспокоится, она сама будет вырисовываться при использовании простых приемчиков.
AP>>Тем самым у вас растет связность -- у вас наличие остальных частей сущности (в данном случае формы) влияет на способ реализации маленькой части. А мне как раз интересны приемы, которые не приводят к росту связности. N>Да с чего вдруг она растет? Я же не про это.
Я же написал что на что у вас влияет. Это лишнее влияние.
N>Ваши две формы в чистом виде можно нарисовать за полчаса. Если этим задача ограничивается, то способ вообще не имеет значения, лишь бы он в полчаса реализации укладывался.
Если время одинаковое, то почему не выбрать решение, которое лучше принимает изменения?
N>А если эти две формы будут частью приложения, в котором 200 подобных форм, то я возьму датагрид, который уже умеет карточки рисовать, и задача будет решена в общем виде с минимальной связностью. При этом каждый первый WPF датагрид будет использовать внутри себя xaml. В этом варианте я буду думать только про свои данные и (может быть) немного про темплейты.
Почему у вас 200 форм является критичной точкой, проходя которую вы будете менять способ решения? Могу предположить, что это решение имеет большие накладные расходы, которые можно оправдать только при наличии 200 форм. Это так?
На C#-е решение диктуется появлением 2-ой секции, а не 200-ой.
N>Если этим задача ограничивается, то способ вообще не имеет значения, лишь бы он в полчаса реализации укладывался. А если эти две формы будут частью приложения, в котором 200 подобных форм, то я возьму датагрид, который уже умеет карточки рисовать, и задача будет решена в общем виде с минимальной связностью. При этом каждый первый WPF датагрид будет использовать внутри себя xaml. В этом варианте я буду думать только про свои данные и (может быть) немного про темплейты.
Зачем там датагрид? Этого решения я пока не понимаю, нужны подробности. Желательно код.
N>Не для каждой задачи надо выдумывать сущности.
Согласен. Надо выбирать “острый” инструмент, тогда правильные сущности появляются сами.
N>а можно в xaml'е никаких архитектурных принципов не нарушить
На xaml-е сценарий с секциями выглядит громоздко, требует больше времени на написание, развитие и сопровождение. Архитектура это или нет, называйте, как хотите, суть от этого не поменяется.
N>Вы начали обсуждать c# и xaml, а теперь скатились к связности. А это же вообще перпендикулярно, можно в шарпе все плохо сделать, а можно в xaml'е никаких архитектурных принципов не нарушить. Так что мы обсуждаем?
Мы обсуждаем выразительные способности двух языков. К связности скатились, потому что перед вами встала задача выбора из ста решений. На языке с высокой выразительной способностью правильное решение пишется при минимальном количестве сведений о задаче, вам же требуется дополнительные сведения, чтобы сделать выбор из ста решений.
Фактически мы обсуждаем отрицательные проявления вот этой философии
One of the primary architectural philosophies used in building WPF was a preference for properties over methods or events. Properties are declarative and allow you to more easily specify intent instead of action. http://msdn.microsoft.com/en-us/library/ms750441.aspx
т.е. майрософтовцы решили, что свойства предпочтительней функций. А на самом деле, именно функция является фундаментальным понятием большинства успешных языков.
Было бы еще полбеды, если они придерживались этой философии только при построении объектной модели WPF. Самое неприятное, что они эту философию распространили на язык -- сделали язык без понятия функции.
P.S. Замечу, что я тоже люблю свойства, в описание моего проекта написано “Property-oriented programming” .
AP>т.е. майрософтовцы решили, что свойства предпочтительней функций. А на самом деле, именно функция является фундаментальным понятием большинства успешных языков.
Вот кто вас научил говорить "на самом деле"? Откуда вы взяли, что ваша точка зрения единственно верная?
Я не читаю всех ваших возражений, ибо бред. Еще раз — идея была не во вкладывании HeaderedContentControl. Вы каждый раз считаете, что вам все ясно, и кто-то должен лоб расшибить, чтобы каждый раз объяснять, чего именно вы не поняли.
В общем, я голосую за то, чтобы перенести эту тему во флуд, где ей и место.
N>В общем, я голосую за то, чтобы перенести эту тему во флуд, где ей и место.
афигеть, сами же не написали ни строчки кода, по большей части анализируете мою личность, вместо обсуждения технических моментов. А теперь во флуд, ... просто нет слов ...
N>>В общем, я голосую за то, чтобы перенести эту тему во флуд, где ей и место. AP>афигеть, сами же не написали ни строчки кода, по большей части анализируете мою личность, вместо обсуждения технических моментов. А теперь во флуд, ... просто нет слов ...
а вы посмотрите, что огребли те, кто вам строчки кода написал. Считаете, что с вами можно обсуждать технические моменты? Вы же тут достаточно много написали, чтобы можно было это понять. Технические моменты я обуждаю тогда, когда мне это интересно. А с вами никак не удается даже сам предмет дискуссии выявить. Каждый раз оказывается, что он был опять в чем-то другом.
Тут есть такой форум, "Священные войны" называется — почитайте. Вы ведете дискуссию как раз в таком стиле. Если эту тему туда перенесут, то вы, скорей всего, только выиграете. Именно там тусуются люди, которые любят поспорить или которым как раз сейчас нечем заняться. А мне лично подобный стиль дискуссий не близок. Поэтому и код вам не пишу. Спросите что-нибудь конкретное в .Net UI — может быть отвечу с кодом.
AP>P.S. Замечу, что я тоже люблю свойства, в описание моего проекта написано “Property-oriented programming” .
Судя по количеству скачавших, идея в массы не пошла... А теперь по существу. Уважаемый, вы, конечно, считаете, что вы всегда правы и ваш подход априори верен во всех случаях. В таких случаях дискуссии не получается. Вы или начинаете придираться к мелочам, либо, как тут верно заметили, утверждаете, что имели в виду совсем другое. В общем, типичное поведение форумного тролля.
Теперь по поводу подхода. Все эти споры по поводу того, что круче, XAML или Ваша реализация, будут валидны только при следующих условиях:
1. Ваша поделка пойдет в массы.
2. Ваша поделка по функционалу не будет уступать XAML.
3. У вашей поделки будет нормальная читабельность кода.
4. У XAML есть возможность загрузить XAML файл в приложение без компиляции проекта. Где такая возможность у Вас?
В заключение, для того, чтобы поднять Ваше ЧСВ, утверждаю:
1. Вы нереально крутой программист, видящий то, что не видят все остальные.
2. Ваша имплементация завоюет мир и Microsoft откажется от XAML как от жалкого подобия Вашего продукта.
3. Миллионы программистов и дизайнеров во всем мире, использующие XAML, коренным образом неправы. Эту ересь надо выжигать каленым железом.
4. Единственно правильная точка зрения на проблемы архитектуры и программирования — Ваша. Все остальные точки зрения по дефолту считаются неправильными и вредными.
Собственно, к чему это я. Присоединяюсь к просьбе notacat перенести данную тему в СВ. Там можно и пофлудить всласть, и полаяться.В данном разделе теме не место, ибо неконструктивно.
В принципе все устраивает. Слегка портит жизнь (но не критично) то, что дизайнер не работает в следующем случае. Если свойство MergeStyle выставлять через property element syntax. Компилируется и запускается, а дизайнер пишет “The attachable property 'MergeStyle' was not found in type 'MergedStyles'.” Может какой-нибудь атрибутик надо вставить?
Кстати, если пойти по ссылке в конце той статьи, то встретим фразу
XAML cannot do everything, and in any good application we need to write code. However if there are some code that are repetitive and we want to declare those code in XAML markup we can write our own markup extensions. http://dotnet.dzone.com/news/extend-wpf-add-your-own-keywor
То есть, народ чтобы избежать дублирования кода применяет кастомные Markup Extension-ы. Но ведь Markup Extension-ы не настолько мощные для решения проблемы дублирования кода как обычные функции (в ООП языках к ним добавляются еще классы).
Отмечу, что моя позиция начинает меняться в сторону XAML-а. С XAML-ом можно попытаться ужиться, набирая костыли для примитивных задачек. Но любви к этому недоязычку вряд ли возникнет. Просто хотелось, чтобы хотя бы примитивные изъезженные задачки были "out of the box".
На простой вопрос ответите? Зачем вы применяете inline стили? Глупо же.
Про "Dependency Property Value Precedence" читали что-нибудь? А поняли?
Если у вас руки тянутся стиль заинлайнить — не мучайтесь, а прямо сразу значения свойств напишите, без стилей. Такое ощущение, что вы просто не знаете, как стиль из ресурсов применить к текст боксу или действительно открыли для себя "множественное наследование".
Нет никакого смысла создавать стиль, если единственная цель — задать локальные значения свойств. Может я какой-то глубины вашей мысли не постигла.
Приведу все-таки строчки кода. Может быть я где-то ошиблась, не охота было проверять ваш пример целиком, прямо в тексте поправила. Но вся ваша простыня должна бы выглядеть примерно так:
N>На простой вопрос ответите? Зачем вы применяете inline стили? Глупо же. N>Про "Dependency Property Value Precedence" читали что-нибудь? А поняли? N>Если у вас руки тянутся стиль заинлайнить — не мучайтесь, а прямо сразу значения свойств напишите, без стилей. N> ... N>Нет никакого смысла создавать стиль, если единственная цель — задать локальные значения свойств. Может я какой-то глубины вашей мысли не постигла.
Просто в демонстрационном примере не стал плодить именованные стили, а сами стили хотелось показать. Никаких других мыслей (или недопониманий с мой стороны) в инлайн стилях нет. В реальном приложении большинство инлайн стилей уйдут в ресурсы, например, для TextBox-а точно уйдет, потому что будет несколько похожих текстбоксов.
Кстати, Вам всегда удается точно определить какие свойства пойдут в стиль, а какие задавать по месту? Просто, если не угадать с этими, и потом переделывать свойства, заданные по месту, на стили/ресурсы -- это не очень приятное занятие (а тулзы с таким автоматическим рефакторингом пока не наблюдается, или я ошибаюсь?). Это аргумент в пользу того, чтобы сразу использовать стили, т.е. пишем инлайн стиль, а потом, если требуется его заиспользовать, переносим в ресурсы. (В CSS это как-то унифицировано, инлайн стили выглядят точно так же, как вынесенные.)
не хотелось делать. Хотелось иметь стиль TextBoxStyle без стиля FontStyle.
N>Такое ощущение, что вы просто не знаете, как стиль из ресурсов применить к текст боксу или действительно открыли для себя "множественное наследование". N>Custom markup extension тут вообще ни с какого боку не нужны. Не надо микроскопом гвозди заколачивать.
А как Вы живете с таким множественным наследование стилей? Терпите? Да же просто при открытии в Visual Studio разметки XAML в списке появляются ошибки и волнистая синяя линия в месте ошибки. Да и дизайнер не работает, для Вас же он критичен.
AP>А как Вы живете с таким множественным наследование стилей? Терпите? Да же просто при открытии в Visual Studio разметки XAML в списке появляются ошибки и волнистая синяя линия в месте ошибки. Да и дизайнер не работает, для Вас же он критичен.
С чего вдруг дизайнер не работает? Пишите нормально и будет вам счастье. Последний раз у меня в WPF дизайнер не работал где-то до первого сервиспака к VS 2008, и то это были специальные баги, которые я постила в MS и они их в сервиспаке фиксили. Вы пока ничего подобного по сложности не изобразили, что бы могло не работать.
А синии линии сами по себе меня не тревожат.
N>С чего вдруг дизайнер не работает? Пишите нормально и будет вам счастье. Последний раз у меня в WPF дизайнер не работал где-то до первого сервиспака к VS 2008, и то это были специальные баги, которые я постила в MS и они их в сервиспаке фиксили. Вы пока ничего подобного по сложности не изобразили, что бы могло не работать. N>А синии линии сами по себе меня не тревожат.
Вы множественное наследование стилей используете? Свойство MergeStyle выставляете через property element syntax?
Мой вышеприведенный XAML дизайнер не открывает. Вот можете взять солюшен в сборе http://files.rsdn.ru/74431/WpfApplication8.zip
N>>С чего вдруг дизайнер не работает? Пишите нормально и будет вам счастье. Последний раз у меня в WPF дизайнер не работал где-то до первого сервиспака к VS 2008, и то это были специальные баги, которые я постила в MS и они их в сервиспаке фиксили. Вы пока ничего подобного по сложности не изобразили, что бы могло не работать. N>>А синии линии сами по себе меня не тревожат. AP>Вы множественное наследование стилей используете? Свойство MergeStyle выставляете через property element syntax?
Нет, не собираюсь, и вам не советую. Вы ничем не обосновали необходимость подобных извращений. А я вам говорю, что в большом проекте от этого будет больше неприятностей, чем пользы.
Здравствуйте, Codechanger, Вы писали:
C>Судя по количеству скачавших, идея в массы не пошла... А теперь по существу. Уважаемый, вы, конечно, считаете, что вы всегда правы и ваш подход априори верен во всех случаях. В таких случаях дискуссии не получается. Вы или начинаете придираться к мелочам, либо, как тут верно заметили, утверждаете, что имели в виду совсем другое. В общем, типичное поведение форумного тролля.
Что-то из вас такая ненависть прет, как будто вас с завтрашнего дня решением Александра Полякова пользоваться заставляют.
C>Теперь по поводу подхода. Все эти споры по поводу того, что круче, XAML или Ваша реализация, будут валидны только при следующих условиях: C> 1. Ваша поделка пойдет в массы. C> 2. Ваша поделка по функционалу не будет уступать XAML. C> 3. У вашей поделки будет нормальная читабельность кода. C> 4. У XAML есть возможность загрузить XAML файл в приложение без компиляции проекта. Где такая возможность у Вас?
C>В заключение, для того, чтобы поднять Ваше ЧСВ, утверждаю: C> 1. Вы нереально крутой программист, видящий то, что не видят все остальные. C> 2. Ваша имплементация завоюет мир и Microsoft откажется от XAML как от жалкого подобия Вашего продукта. C> 3. Миллионы программистов и дизайнеров во всем мире, использующие XAML, коренным образом неправы. Эту ересь надо выжигать каленым железом. C> 4. Единственно правильная точка зрения на проблемы архитектуры и программирования — Ваша. Все остальные точки зрения по дефолту считаются неправильными и вредными.
C>Собственно, к чему это я. Присоединяюсь к просьбе notacat перенести данную тему в СВ. Там можно и пофлудить всласть, и полаяться.В данном разделе теме не место, ибо неконструктивно.
Александр показал, что xaml как язык имеет определенные ограничения, части из которых нет у полноценных языков программирования вроде С#. И предложил обсудить как эти ограничения можно обойти на xaml'е и сравнить это с тем, что может дать кодогенерация. Пользоваться своим решением Александр никого не заставлял и не заставляет. Вы же вместо конструктивного диалога почему-то постоянно скатываетесь на обсуждение личности автора и лозунгам, что xaml это абсолютный идеал.
U>Александр показал, что xaml как язык имеет определенные ограничения, части из которых нет у полноценных языков программирования вроде С#. И предложил обсудить как эти ограничения можно обойти на xaml'е и сравнить это с тем, что может дать кодогенерация.
А не могли бы вы своими словами конспективно перечислить эти ограничения xaml'а и пользу кодогенерации? Я почему-то ни один аргумент Александра воспринять не могу. Мое ощущение, что он просто не понимает, как работать с xaml'ом и делает выводы из неверных предпосылок, никак не изменилось с момента его первого сообщения.
Если вы прониклись, может сможете объяснить так, чтобы кто-то еще понял?
AP>Кстати, Вам всегда удается точно определить какие свойства пойдут в стиль, а какие задавать по месту? Просто, если не угадать с этими, и потом переделывать свойства, заданные по месту, на стили/ресурсы -- это не очень приятное занятие (а тулзы с таким автоматическим рефакторингом пока не наблюдается, или я ошибаюсь?). Это аргумент в пользу того, чтобы сразу использовать стили, т.е. пишем инлайн стиль, а потом, если требуется его заиспользовать, переносим в ресурсы. (В CSS это как-то унифицировано, инлайн стили выглядят точно так же, как вынесенные.)
Я стараюсь не задаваться такими вопросами. Это как анекдот про сороконожку, которую спросили, с какой ноги она шагает.
Вы что, постоянно об этом думаете и рефакторингом занимаетесь?
Ну например для текстбоксов:
— если я знаю, что в приложении будет куча текстбоксов, как в ваших формочках, то логично для них сделать общий дефолтный стиль, куда включить
Padding, Margin, FontSize, FontStyle, VerticalAlignment, MinWidth, можно еще цвета. На самом деле, я бы предпочла ограничиться Padding и Margin, шрифты лучше задавать глобально на родительском элементе. Ну, а если у какого-то конкретного текстбокса что-то должно быть не так, то свойства, заданные в стиле, переопределяются по месту.
Да, Width и Height в моем xaml'е скорей всего вообще не будет, ни в стилях, ни в свойствах. По крайней мере, для текста это должно задаваться выбором адекватного лейаута.
Если уж вы выясняете у дизайнера, как и что должно выглядеть, спросите у него, что общее в оформлении разных элементов, а что индивидуально должно настраиваться. Он вам скажет, а вы общее в стиль вынесете.
Здравствуйте, Undying, Вы писали:
U>Александр показал, что xaml как язык имеет определенные ограничения, части из которых нет у полноценных языков программирования вроде С#. И предложил обсудить как эти ограничения можно обойти на xaml'е и сравнить это с тем, что может дать кодогенерация. Пользоваться своим решением Александр никого не заставлял и не заставляет. Вы же вместо конструктивного диалога почему-то постоянно скатываетесь на обсуждение личности автора и лозунгам, что xaml это абсолютный идеал.
XAML — не идеален. А обсуждение ограничений, как вы это называете, вылилось в итоге в то, что лично я так толком и не понял, чего же автор хочет добиться. Далее была куча умных слов про декомпозицию, master page и т.д. Ничего полезного, кроме увеличения опыта троллинга, я для себя из этой дискуссии не вынес.
N>Я стараюсь не задаваться такими вопросами. Это как анекдот про сороконожку, которую спросили, с какой ноги она шагает.
Если Вы о вот этом анекдоте^
Как говорится в старом анекдоте: "Когда сороконожку спросили, с какой ноги она начинает шагать, она задумалась и не смогла сделать ни одного шага."
Тогда ваше восприятие XAML-а объясняется. Вы о нем не задумываетесь, а просто используете его как сороконожка заученные движения. Так же как движение ноги, повторенное многократно, приводит к передвижению в пространстве, так и небольшие приемчики кодирования определяют качество кода в целом, и, как следствие, качество продукта.
N>Вы что, постоянно об этом думаете ... ?
Нет, не постоянно. Но нахожу время сформулировать используемые приемчики для того, например, чтобы передать другим, да и в своей голове от этого больше порядку будет. Так же с большим удовольствием слушаю и использую интересные приемы, наработанные коллегами. Поэтому и вам задал этот вопрос.
N>Вы что, постоянно об этом думаете и рефакторингом занимаетесь?
Да, без рефакторинга никуда! Про полезность и значимость рефакторинг много написано, и я не вижу причин, почему это неприменимо к UI-ой технологии.
N>Нет, не собираюсь, и вам не советую. Вы ничем не обосновали необходимость подобных извращений. А я вам говорю, что в большом проекте от этого будет больше неприятностей, чем пользы.
Ваша рекомендация-запрет не обоснована, так же как и моя позиция не подтверждена хорошим примером. Привести обоснование в абстрактном виде легко, но думаю, вы его знаете.
N>>Я стараюсь не задаваться такими вопросами. Это как анекдот про сороконожку, которую спросили, с какой ноги она шагает. AP>Если Вы о вот этом анекдоте^
AP>Как говорится в старом анекдоте: "Когда сороконожку спросили, с какой ноги она начинает шагать, она задумалась и не смогла сделать ни одного шага."
Тогда ваше восприятие XAML-а объясняется. Вы о нем не задумываетесь, а просто используете его как сороконожка заученные движения. Так же как движение ноги, повторенное многократно, приводит к передвижению в пространстве, так и небольшие приемчики кодирования определяют качество кода в целом, и, как следствие, качество продукта. Просто я об этом задумывалась два или три года назад и сейчас уже проблематично ход мыслей восстанавливать, да и незачем.
Мои привычки в этом смысле уже можно считать полезными. А Вы вот только счас начали, вам и карты в руки.
А до качества продукта, извините, вы еще долго не доберетесь. И наверняка оно вылезет совсем не в том, что что-то не то в стиль вынесено, а где-нибудь в производительности или утечках памяти.
Рефакторинг это хорошо, когда не самоцель. А вот заведомо писать что-то, что нужно рефакторить — это уже слишком. НагорОдите кучу с грудой, потом если вдруг это будет другой человек рефакторить — его ж тошнить будет. А чаще всего при рефакторинге сильно сложных художеств следующее молодое дарование просто все с нуля переписывает.
AP>Ваша рекомендация-запрет не обоснована, так же как и моя позиция не подтверждена хорошим примером. Привести обоснование в абстрактном виде легко, но думаю, вы его знаете.
Так подтвердите уже хоть то-нибудь хорошим примером, чтобы было о чем разговаривать. Это же ваша тема, а не моя. Зачем я буду что-то обосновывать, если вы ничего не обосновали?
N>Рефакторинг это хорошо, когда не самоцель. А вот заведомо писать что-то, что нужно рефакторить — это уже слишком. НагорОдите кучу с грудой, потом если вдруг это будет другой человек рефакторить — его ж тошнить будет. А чаще всего при рефакторинге сильно сложных художеств следующее молодое дарование просто все с нуля переписывает.
Понятно. Ваше отношение к рефакторингу находится в полном соответствии с вашем неприятием того, о чем я пишу в этом треде. Думаю, если бы вы глубоко прониклись концепцией рефакторинга и смежными вопросами (т.е. придерживались методологий ориентированных на код), то, по крайней мере, терпимее отнеслись к моему треду.
Рефпакторинг является неотъемлемой частью некоторых методологий
Ну конечно, если бы кто-то глубоко проникся чем-то, то он бы и вашу идею понял с полуслова, а раз кто-то не понимает — значит он еще непросветленный?
Может вернетесь к своей идее и в чистом виде ее обоснуете, без отсылок к википедии?
N>А не могли бы вы своими словами конспективно перечислить эти ограничения xaml'а
Вернемся в контекст задачи о секциях. С помощью XAML-а нельзя построить вот такое дерево:
С помощью XAML-а строится дерево:
Это явно показывает ограничения выразительных способностей XAML-а, как языка для построения UI-го дерева. Надеюсь, вы с этим согласны?
Следствия этих ограничений -- это отдельный вопрос.
N>>почему вы думаете, что нельзя? AP>Потому что мне не удалось с помощью гугла найти решение, и в этом треде его тоже не привели.
Проблема в том, что вы до сих пор не удосужились четко сформулировать задачу. Поэтому о решении говорить преждевременно.
А конкретно можно, что именно у вас не получилось (не про гугль, а про xaml)?
Кстати, вопрос про ограничения xaml'а был не к вам, а к Undying. Мне показалось, что он проникся вашими мыслями. Вдруг юы повезло и он смог бы их изложить в доступной для понимания форме.
N>Проблема в том, что вы до сих пор не удосужились четко сформулировать задачу. Поэтому о решении говорить преждевременно.
Вы это серьезно? Задача -- реализовать формочку из первого поста. Вы можете предложить решение. Далее пойдет его обсуждение. Будет рассматриваться, насколько хорошо решение вписывается в жизненный цикл программного обеспечения. Вот как-то так. Сценарий “задача -- решение” не очень интересен.
N>А конкретно можно, что именно у вас не получилось (не про гугль, а про xaml)?
Есть две секции, и у них есть повторяющийся код с двумя “дырками” Header и Content. (На инлайн стили не обращайте внимания)
У меня не получилось избежать дублирования кода без внесения в дерево дополнительных элементов таких как SectionControl и ContentPresenter.
N>Кстати, вопрос про ограничения xaml'а был не к вам, а к Undying. Мне показалось, что он проникся вашими мыслями. Вдруг юы повезло и он смог бы их изложить в доступной для понимания форме.
Это я видел. Но мне самому показалось полезным выписать явно эти ограничения.
N>>Проблема в том, что вы до сих пор не удосужились четко сформулировать задачу. Поэтому о решении говорить преждевременно. AP>Вы это серьезно? Задача -- реализовать формочку из первого поста. Вы можете предложить решение. Далее пойдет его обсуждение. Будет рассматриваться, насколько хорошо решение вписывается в жизненный цикл программного обеспечения. Вот как-то так. Сценарий “задача -- решение” не очень интересен.
Абсолютно серьезно. Если бы я хотела обсуждать мое решение, я бы сама тему завела. Я хочу ваше обсудить.
AP>У меня не получилось избежать дублирования кода без внесения в дерево дополнительных элементов таких как SectionControl и ContentPresenter.
Ну это уже что-то. И чем вам мешает внесение дополнительных элементов? Вернее так, чем вы заменяете эти дополнительные элементы в вашем подходе. И почему вы думаете, что дерево номер 2 — это ограничение именно xaml'а, а не вашей задачи или архитектуры WPF в целом?
Понимаете, если мыслить не в текстблоках, а делать декомпозицию задачи чисто умозрительно, или на C#, или еще хоть на чем, все равно можно эту самую задачу обобщить до какого-то объекта с заголовком и контентом. При чем тут ограничения xaml'а?
Этот вопрос имеет уклон в “философию”, в жизненный цикл программного обеспечения и т.п. Поэтому давайте пока отложим этот вопрос. Сейчас вопрос с первым приоритетом -- это ваше согласие или опровержение того, что на XAML-е нельзя выразить дерево 1.
N>Вернее так, чем вы заменяете эти дополнительные элементы в вашем подходе.
Ничем!!! UI-ное дерево ровно такое как при копипасте.
N>И почему вы думаете, что дерево номер 2 — это ограничение именно xaml'а, а не вашей задачи или архитектуры WPF в целом?
Потому что на другом языке (C#) существует решение без дерева 2.
N>Понимаете, если мыслить не в текстблоках, а делать декомпозицию задачи чисто умозрительно, или на C#, или еще хоть на чем, все равно можно эту самую задачу обобщить до какого-то объекта с заголовком и контентом. При чем тут ограничения xaml'а?
Умозрительно или в коде делайте какие хотите классы/интерфейсы/методы, но не надо засовывать дополнительные элементы в UI-ое дерево.
Мне кажется, что мне наконец-то все ясно. Вы просто перекладываете проблему в другое место. Вернее так, вы видите проблему в том, в чем ее не вижу я, и наоборот. Можно уже этот вопрос оставить, не чувствую в себе сил вас переубеждать. С опытом сами поумнеете может быть.
А теперь представьте, что вы сделали свою систему на шарпе, нагородили кучу методов с параметрами, внедрили это среди своей команды и счастливы.
Проходит полгода, хотите вы еще кого-нибудь в свою команду нанять. Как будете проводить собеседование и кого будете брать? Понятно, что со студентами проблем не будет. А если ведущий понадобится?
А как вы это все сопровождать будете? А если понадобится дизайн переделать. Грубо говоря, начальство скажет, что меняется корпоративная расцветка и вот вам новый дизайн — как будет процесс поставлен и сколько времени у вас займет натягивание новой шкуры? А если еще при этом скажут и лейаут поменять? Насколько ваш код будет reusable?
Здравствуйте, notacat, Вы писали:
N>Мне кажется, что мне наконец-то все ясно. Вы просто перекладываете проблему в другое место. Вернее так, вы видите проблему в том, в чем ее не вижу я, и наоборот. Можно уже этот вопрос оставить, не чувствую в себе сил вас переубеждать. С опытом сами поумнеете может быть.
N>А теперь представьте, что вы сделали свою систему на шарпе, нагородили кучу методов с параметрами, внедрили это среди своей команды и счастливы. N>Проходит полгода, хотите вы еще кого-нибудь в свою команду нанять. Как будете проводить собеседование и кого будете брать? Понятно, что со студентами проблем не будет. А если ведущий понадобится? N>А как вы это все сопровождать будете? А если понадобится дизайн переделать. Грубо говоря, начальство скажет, что меняется корпоративная расцветка и вот вам новый дизайн — как будет процесс поставлен и сколько времени у вас займет натягивание новой шкуры? А если еще при этом скажут и лейаут поменять? Насколько ваш код будет reusable?
Эх, так и не написали, можно ли на XAML-е сделать дерево 1 или нельзя...
AP>Эх, так и не написали, можно ли на XAML-е сделать дерево 1 или нельзя...
В вашей постановке, видимо нельзя. Но это проблема не xaml'а, а вашего понимания вашей задачи. С моей точки зрения тут нет предмета для обсуждения, который имел бы отношение к xaml'у. Можно, разве что, удивиться, зачем вы выбрали для своей задачи WPF, если он так очевидно вам не нравится. На том же шарпе можно не только WPF приложения писать.
И, в конце концов, чем вот этот ваш код:
private static Grid Section(string sectionName, UIElement nestedElement)
{
return new Grid().VerticalAlignment_Top().RowDefinitions(
new RowDefinition().Height_Auto(),
new RowDefinition()).Nested(
new Border().Grid_Position(0, 0).BorderThickness(1).Padding(10, 5, 10, 4)
.Execute(SetFrameBorderBrush)
.Background(new SolidColorBrush().Color(Color.FromRgb(128, 128, 128))).Nested(
new Grid().Nested(
new TextBlock().Text(sectionName).Execute(SetFontStyle).FontWeight_Bold()
.FontWeight_Bold().Foreground_White())
),
new Border().Grid_Position(1, 0).BorderThickness(1, 0, 1, 1)
.Execute(SetFrameBorderBrush).Padding(0, 11, 0, 11)
.Nested(nestedElement)
);
}
private static Grid CustomerSection()
{
return new Grid().RowDefinitions(
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto()).ColumnDefinitions(
new ColumnDefinition().Width_Auto(),
new ColumnDefinition(),
new ColumnDefinition().Width_Auto(),
new ColumnDefinition()).Nested(
TextBlock(0, 0).Text("Name:"), TextBox(0, 1).Grid_ColumnSpan(3),
TextBlock(1, 0).Text("Contact Name:"), TextBox(1, 1).Grid_ColumnSpan(3),
TextBlock(2, 0).Text("Phone:"), TextBox(2, 1),
TextBlock(2, 2).Text("Fax:").HorizontalAlignment_Right(), TextBox(2, 3),
TextBlock(3, 0).Text("Address:"), TextBox(3, 1).Grid_ColumnSpan(3),
TextBlock(4, 0).Text("City:"), TextBox(4, 1),
new Grid().Grid_Position(4, 2).Grid_ColumnSpan(2)
.ColumnDefinitions(
new ColumnDefinition().Width_Auto(),
new ColumnDefinition()
).Nested(
TextBlock(0, 0).Text("State/Province:"), TextBox(0, 1)),
TextBlock(5, 0).Text("ZIP/Postal code:"), TextBox(5, 1),
TextBlock(5, 2).Text("Country:"), TextBox(5, 3));
}
private static Grid DealerSection()
{
return new Grid().RowDefinitions(
new RowDefinition().Height_Auto(),
new RowDefinition().Height_Auto()).ColumnDefinitions(
new ColumnDefinition().Width_Auto(),
new ColumnDefinition()).Nested(
TextBlock(0, 0).Text("First Contact Name:"), TextBox(0, 0 + 1),
TextBlock(1, 0).Text("Second Contact Name:"), TextBox(1, 0 + 1));
}
отличается от того якобы дублирования, которое в xaml'е получается? По-моему, тот же самое, только в профиль.
Или я не туда смотрю?
Т.е. я прекрасно понимаю, чем оно отличается от дерева 1 и даже чем оно отличается от дерева 2. Но какой в этом всем глубокий смысл? В том, что секция не существует как отдельный объект? Ну и глупо. ООП не любите?
Допускаю, что дальше вы ответите, что это только маленький пример.. Ну так тем более, на больших проектах будет страдать именно что жизненный цикл продукта, его сопровождаемость, изменяемость, повторное использование кода вообще лесом пойдет. А археологи будущего, которые будут это дело рефакторить, попортят вам карму...
зыЖ обратите уже внимание, что никто кроме меня беседу не поддерживает. Было бы о чем спорить — не молчали бы.
N>Или я не туда смотрю?
Самое интересное в местах вызова метода Section
public Window2()
{
InitializeComponent();
this.SnapsToDevicePixels(true).Nested(
new Border().Padding(5).Nested(
new Grid().RowDefinitions(
new RowDefinition().Height_Auto(),
new RowDefinition()).Nested(
new Grid().ColumnDefinitions(
new ColumnDefinition(),
new ColumnDefinition().Width(18),
new ColumnDefinition()).Nested(
Section("Customer", CustomerSection()).Grid_Position(0, 0),
Section("Dealer", DealerSection()).Grid_Position(0, 2))
)
)
);
}
Здесь метод Section вызывается два раза. Это и есть избавление от дублирования кода.
Это все я давно поняла. Такое ощущение, что вы экономите на буквах. Вы выбрали одну конкретную вещь и в попытках от нее избавиться дошли до абсурда.
Давайте теперь обоснуйте, как вы в вашем случае сохраните те плюсы xaml'а, про которые вам уже тут сто раз говорили.
N>Вы выбрали одну конкретную вещь и в попытках от нее избавиться дошли до абсурда.
Вы не правы в том, с чего я начал. Постановка задачи была сформулирована на более абстрактном уровне (тем самым гораздо шире). Вот начало
. А проверять абстракции, да, действительно, надо на конкретных вещах. А не прикрываться теоретическими доводами, как Microsoft делала с размытыми шрифтами. Два года отбивалась (теоретическими отмазками по поводу DPI независимости) от видимого глазом очевидного косяка.
Серфил по Интернету и случайно наткнулся на проект Groovy builders. Цели этого проекта практически в точности совпадают с моими
Note that within the 'markup' you can embed normal expressions — i.e. this markup syntax is a normal part of the Groovy language.
Так что вещь, действительно, интересная и актуальная. Остается только вопрос реализации этой идеи. Язык C# от версии к версии вбирает все больше разных концепций, вполне вероятно, что и эту потребность заметят и добавят соответствующий синтаксис. Жаль, что при создании WPF сразу не пошли этим путем.
Тем, кто выступал за XAML и не понимал, зачем это надо: можете выдыхать, вы, действительно, чего-то не догоняете. Но все же обсуждения были полезными, спасибо.
Здравствуйте, notacat, Вы писали:
N>ну и каша у вас в голове
Ну, можно сказать, классический пример Петрушки — дашь ему химию, прочтет и химию. Есть знания, применимые на практике и есть неприменимые.XAML хорош тем, что это стандартизированный язык разметки, с 4-й версии .Net еще и не привязанный особо к WPF. А это открывает некие новые возможности, в т.ч. и в области кроссплатформенности(на данный момент об этом говорить, конечно, рановато, ибо остается привязка к .Net, но что-то мне подсказывает, что при наличии стандарта аналогичные библиотеки будут написаны).
Кстати, хочется у автора топика спросить — вы как, HTML не пробовали переизобрести?
Здравствуйте, Codechanger, Вы писали:
C>Ну, можно сказать, классический пример Петрушки — дашь ему химию, прочтет и химию. Есть знания, применимые на практике и есть неприменимые.XAML хорош тем, что это стандартизированный язык разметки, с 4-й версии .Net еще и не привязанный особо к WPF. А это открывает некие новые возможности, в т.ч. и в области кроссплатформенности(на данный момент об этом говорить, конечно, рановато, ибо остается привязка к .Net, но что-то мне подсказывает, что при наличии стандарта аналогичные библиотеки будут написаны).
Кстати, WPF для Java уже есть: http://www.soyatec.com/eface/
N>>ну и каша у вас в голове AP>Подробности будут? Вы не видите связь между Groovy builders и моими экспериментами по построению UI-ного дерева на C#-е?
А какая между ними связь? Вы что, знакомы с автором?
Вы лучше поясните, какая связь между связью Groovy builders с вашими эскпериментами и тем, что кто-то что-то должен был из этого понять и выдохнуть.
Какие вам еще подробности, ваше предыдущее сообщение выглядело как окончание дискуссии. А для всех остальных дискуссия закончилась еще раньше.
N>А какая между ними связь?
1. Синтаксис для вложенных древовидных структур ('markup') внутри “обычного” языка.
2. Factory mechanism из паттерна Builder/Interpreter.
Здравствуйте, Alexander Polyakov, Вы писали:
N>>А какая между ними связь? AP>1. Синтаксис для вложенных древовидных структур ('markup') внутри “обычного” языка. AP>2. Factory mechanism из паттерна Builder/Interpreter.
AP>>1. Синтаксис для вложенных древовидных структур ('markup') внутри “обычного” языка. AP>>2. Factory mechanism из паттерна Builder/Interpreter.
C>Классический пример duck typing
По-моему, duck typing тут ни причем. Указанные пункты можно реализовать и в рамках строго типизированного подхода.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>>>1. Синтаксис для вложенных древовидных структур ('markup') внутри “обычного” языка. AP>>>2. Factory mechanism из паттерна Builder/Interpreter.
C>>Классический пример duck typing AP>По-моему, duck typing тут ни причем. Указанные пункты можно реализовать и в рамках строго типизированного подхода.
AP>Или это такая шутка, игра слов?
Если что-то плавает в воде и крякает как утка, оно является уткой. Так понятнее?
C>Если что-то плавает в воде и крякает как утка, оно является уткой. Так понятнее?
Нет, не понятно. Можно поподробнее пояснить, как эта фраза про утку ложится на наш контекст разговора? Что в нашем контексте “утка”, что “что-то”?
И какую мысль вы хотите этим выразить?
Здравствуйте, Alexander Polyakov, Вы писали:
C>>Если что-то плавает в воде и крякает как утка, оно является уткой. Так понятнее? AP>Это duck test. Расскажите, при чем тут duck typing?
Жесть, однако. Вы, простите, термин duck typing только с одной точки зрения воспринимаете? С технической?
Я в общем-то что хотел сказать — при всей внешней похожести надо понимать, область применения различна.
C>>>Если что-то плавает в воде и крякает как утка, оно является уткой. Так понятнее? AP>>Это duck test. Расскажите, при чем тут duck typing? C>Жесть, однако. Вы, простите, термин duck typing только с одной точки зрения воспринимаете? С технической? Duck typing, Duck test. Попробуйте найти proof link для вашего не технического понимания duck typing-а. Такое ощущение, что вы на ходу это придумали. И вдобавок назвали это “классическим”. Забавно .
C>Я в общем-то что хотел сказать — при всей внешней похожести надо понимать, область применения различна.
Как раз все наоборот, внешняя схожесть ни при чем. Совпадение в сути и в целях. Сходите еще раз посылке, там все четко описано (все ключевые моменты).
А ведь ещё приходится рефакторить XAML — упрощать некоторые участки, заменять одни элементы другими, выносить повторяемые участки в ресурсы... 
, в Вашем дополнении так много информации, относящейся к теме треда.
.
Это был рафинированный пример отображения объекта из модели предметной области с помощью шаблона данных. Если мы отображаем на экране объект Customer, то все его свойства таким же макаром можно будет отобразить в виде секции с заголовком, текстбоксами и лейблами. Писать дополнительные классы для "логических понятий интерфейса" типа "секции" не потребуется. Повторяющиеся куски разметки можно будет выделить в отдельные шаблоны данных и стили.
...
