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'а, про которые вам уже тут сто раз говорили.
Просто я об этом задумывалась два или три года назад и сейчас уже проблематично ход мыслей восстанавливать, да и незачем.
