Здравствуйте, Аноним, Вы писали:
А>Вообще, если по-честному сказать, сомневаюсь, что дизайнер (тот, который настоящий дизайнер, а не «веб-дизайнер») сможет редактировать 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, большинству сказанного было бы достаточно. Или автор вопроса сам предлагал бы варианты, а его поправляли бы. Это же публичный форум, а не техсаппорт.