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>Умножьте на почасовую ставку и поймите, чего вы не понимаете.
По поводу дизайнера тут тонкие моменты, поэтому отвечу чуть позже.
Это был рафинированный пример отображения объекта из модели предметной области с помощью шаблона данных. Если мы отображаем на экране объект Customer, то все его свойства таким же макаром можно будет отобразить в виде секции с заголовком, текстбоксами и лейблами. Писать дополнительные классы для "логических понятий интерфейса" типа "секции" не потребуется. Повторяющиеся куски разметки можно будет выделить в отдельные шаблоны данных и стили.
