ASP.NET 4.0: можно ли сделать некоторые дочерние элементы управления пользователя общедоступными без использования FindControl или общедоступных свойств?

У меня есть настраиваемый пользовательский элемент управления, содержащий текстовые поля, раскрывающиеся списки и т. Д. Мне нужно, чтобы эти элементы управления были общедоступными, чтобы я мог работать как ucEmployeeAddress.txtAddr1.Text из-за пределов элемента управления.

Я знаю, что могу использовать общедоступные свойства в элементе управления, которые возвращают экземпляр элемента управления внутри, или использовать FindControl для обнаружения моего элемента управления вне пользовательского элемента управления, но я не хочу этого делать из-за избыточного кода.

Если нет возможности делать то, что я хочу, я просто пойду по маршруту общественной собственности.

Изменить: не будет ли человек, который проигнорировал мой вопрос, так любезен, объяснить, почему мой вопрос показывает отсутствие исследовательских усилий, неясен или бесполезен?


asp.net public controls user-controls
person oscilatingcretin    schedule 22.11.2011    source источник
comment
Итак, вы хотите раскрыть что-то как свойство, фактически не написав код, чтобы раскрыть это, потому что вам не нужен excess код ... интересно   -  person Richard Friend    schedule 22.11.2011

Ответы (4)


arrow_upward
1
arrow_downward

Вам просто нужно предоставить свойство в пользовательском элементе управления:

public string Address
{
    get
    {
        return txtAddr1.Text;
    }
    set
    {
        txtAddr1.Text = value;
    }
}
person James Johnson    schedule 22.11.2011
comment
Хотите убедиться, что в XAML есть оператор, похожий на x:FieldModifier="public"? - person Gqqnbig; 27.05.2015

arrow_upward
1
arrow_downward

Вам действительно нужно выставить весь контроль?

Если это просто свойство текста, вы можете просто раскрыть его.

public string TitleText
{
     get { return this.txtTitle.Text;}
}

Если вам действительно нужен элемент управления, я бы предложил раскрыть его через свойство, потребители могут даже не знать о существовании или имени элемента управления, и им не следует заботиться о вашей внутренней работе - использование FindControl - плохое решение вне элемента управления.

public TextBox TitleTextBox
{
     get { return this.txtTitle;}
}

В качестве альтернативы вы можете изменить шаблоны Visual Studio, чтобы сделать все ваши элементы управления общедоступными, однако я не уверен, такая ли это отличная идея и как вы бы это сделали.

person Richard Friend    schedule 22.11.2011

arrow_upward
1
arrow_downward

Часа через три я наконец нашел решение. Я не знаю, является ли это новым в VS2010, но вы действительно можете отредактировать конструктор пользовательского элемента управления и превратить всех участников из защищенных в общедоступные. Клянусь, я безуспешно пробовал это с более ранними версиями VS в прошлом, но, по-видимому, теперь у меня это работает.

Что интересно, среда IDE прекрасно понимает, какие части конструктора она должна и не должна восстанавливать. Например, если вы закомментируете все содержимое класса конструктора, он не будет повторно создавать закомментированные члены. Чтобы заставить его регенерировать их, вы должны полностью удалить участников, которых вы хотите регенерировать. Что еще круто, так это то, что вы можете закомментировать все содержимое класса дизайнера, вернуться к разметке и добавить серверный элемент управления, например текстовое поле, и вернуться к дизайнеру, чтобы обнаружить, что он сгенерировал определение члена только для этого элемента управления, а остальные ссылок на участников остаются закомментированными. Изменить. И если вы удалите элемент управления из разметки, элемент конструктора которого вы изменили с защищенного на общедоступный, он все равно удалит ссылку из дизайнера.

Замечу, что я также использую VB.NET. Я бы предположил, что это работает и с C #, но не могу сказать наверняка.

person oscilatingcretin    schedule 22.11.2011
comment
Это может сработать, но это неправильный способ. Просто создайте свойства для отображения данных, как в моем примере. - person James Johnson; 22.11.2011
comment
Ваш метод - это последний метод, о котором я упоминал в конце своего вопроса. Я определенно не хочу поступать неправильно, поэтому, прежде чем я приму окончательное решение, не могли бы вы более подробно рассказать, почему мой метод неправильный? Вы имеете в виду, что это просто не общепринятое решение или есть измеримые последствия для этого? - person oscilatingcretin; 22.11.2011
comment
Технически в упомянутом вами подходе нет ничего плохого, но стандартной практикой является использование свойств. Использование свойств позволяет вам контролировать, какая информация об элементе управления доступна, и выбирать значимые и описательные имена свойств. Например, MyUserControl.ContentTitle выглядит намного чище, чем MyUserControl.txtSomeTitle.Text.Trim() - person James Johnson; 22.11.2011
comment
Я, конечно, согласен с вами в этом. Однако в моем случае мне действительно нужен фактический экземпляр элемента управления, чтобы я мог передать его ссылку в другое место. Очень сложно объяснить, зачем мне это нужно, не создавая скучной стены текста. - person oscilatingcretin; 22.11.2011
comment
В этом случае вы можете просто создать свойство, которое предоставляет сам элемент управления. - person James Johnson; 22.11.2011
comment
Это возвращает нас к вопросу о том, почему изменение файла дизайнера подобным образом является неправильным. В программировании есть определенные методы, которые не принимаются просто потому, что они не соответствуют определенным субъективным принципам (соглашениям об именах переменных). Другие методы просто грубые и нетрадиционные (операторы goto, повторное использование переменных). Другие нарушают лучшие практики (повторяющийся код). Другие имеют измеримые последствия для вашего приложения (не закрывая соединения). Где бы вы отнесли изменение файла дизайнера, чтобы сделать некоторые элементы управления общедоступными? - person oscilatingcretin; 23.11.2011
comment
Я бы сказал, что это нарушает передовой опыт и общепринятые принципы дизайна. В этой статье это довольно хорошо объясняется: csharpindepth.com/articles/chapter8/propertiesmatter.aspx - person James Johnson; 23.11.2011

arrow_upward
0
arrow_downward

Правильный способ сделать это - всплытие событий. Таким образом, вы можете скрыть реализацию ваших элементов управления, сохраняя при этом возможность изменять выбранные вами свойства.

Эта ссылка хорошо объясняет как это сделать.

В качестве примечания: вас должна больше заботить элегантность кода, чем его объем.

Если вы потратите время на реализацию восходящей цепочки событий, например, в отличие от раскрытия дочерних элементов элемента управления как public, любые манипуляции с дочерними элементами элемента управления будут обрабатываться этим элементом управления. Это упрощает поддержку, если когда-либо изменится логика манипуляций, и легко реализуется во всем приложении.

Однако, если вместо этого вы выставляете дочерние элементы вашего элемента управления как public, вы должны повторять эту манипуляцию везде, где она используется.

Следовательно, «лишний код» улучшит качество вашего кода и фактически уменьшит этот «лишний код», который вас беспокоит.

person shuniar    schedule 22.11.2011