Такая проблема.
Существует контрол "A". Сложный, т.е. В нем есть друге, например Label - "B" или другой контрол

Далее если например в страничке asp сделать рефренс на "A", тэг, сорс - всё написать в asp - все работает,

Но если в этой страничке попытаться динамически создать контрол "A" - то все внутренние контролы(Label - "B") - не
Инициализируются, т.е. равны null. Я подозреваю, что надо вызвать какойто метод насильного рендеринга, инициализации внутренних контролов.

Подскажите плиз, или хотя бы где прочитать

Понятно. Значит так. Твой "сложный" контрол породи от CompositeControl (или Control - по старинке). 
Почитай в MSDN об этом классе. Желательно, чтобы твой контрол еще наследовался от INamingContainer. 
Буквально вчера обсуждался вопрос с проблемами вложенных контролов. см тут
обрати внимание на функции CreateChildControls() и EnsureChildControls()

SpaceSpace, вызови DataBind -->> Биндятся как сам контрол, так и все child'ы этого контрола.

Добавлено через 53 секунды
замечтался   

Я дико извиняюсь, наверное савсем глупый, но....
опишу проблему подробно...
прошу, отнеситесь к этому серьезно

У меня есть контрол А.ascx, в нем например, лежит Table(хотя там есть и другие контролы),
в клетках которого есть Lable ,button, edit.
В  А.ascx.cs куча кода, который работает с A.Table ->> c Lables ,buttons, edits

Есть контрол B. 
если я в В.ascx ручками пропишу A
<% @Register  tagPrefix="d" tagName="t" src=".."  %>  
и засуну его куда нить 
<d:t runat=".." ID=".." />
то всё работает! 
Но я пытаюсь создать в нем  new А().
Динамически нужно создавать обязательно!!!

При запуске вылетает NullReffrenceException, т.к A.Table не существует! Table прописан в asp файле, я его динамически не создавал!

Неужели мне нужно в коде заново его инициализировать, забивать Id, runat?!!!
Я так понимаю, что ASP  среда парсирует этот файл .ascx и сама инициализирует все компоненты, которые я добросовестно ручками записал.

Внимание вопрос.
Какой контрол должен быть наследован от INamingContainer?(A или B?)
Куда нужно вставить CreateChildControls() или EnsureChildControls() (я вообще сомневаюсь в  пригодности этих методов в данном случае), чтобы инициализация контролов
(которые, мать их, должны уже быть инициализированы) прошла успешно?

Я подозреваю, что тут какая-то байда с порядком вызова обработчиков, и тот который должен прочитать А.ascx, и создать всё, что там положено - соответственно не читает и не создает, и когда подходит очередь выполняться коду A.ascx.cs (в PageLoad, например) - ни один из компонентов A.ascx еще не создан.

SpaceSpace, а ты не можешь так просто создать объект класса A и жить себе спокойно. Тебе нужно будет загрузить контрол
К примеру вот так вот -->>

потом преобразовать  привести его к твоему классу и тогда уже обращаться к своему классу. А иначе ты просто создаешь класс... а так тебе нужно еще с ascx надо связатся...
Ну и естественно после этого засунуть этот UserControl в смою страницу.

Добавлено через 5 минут и 51 секунду
Вообще, как я понимаю asp.net. Так ты вообще создаешь объект страницы (aspx/ascx) а этот класс в свою очередь наследуется от behind-code. Ну конечно сказать, что xml унаследован от C# кода    это круто. Но это если так, просто, ну представить что такое было б возможным :о).
А класс который находится в behind-code попросту обычный класс... Сам по себе он бесполезен. Ну и доступа к элементам что находятся на страницы соответственно не имеет.

P.S. а если тебе нужно просто загрузить контрол. То либо как я выше написал загрузить в объект и выгрузить на страницу. Либо можно через 

Это сообщение отредактировал(а) Mymik - 11.5.2007, 14:19

2Mymik, спасибо за понимание.

<-- Ну конечно сказать, что xml унаследован от C# кода    это круто. Но это если так, просто, ну представить что такое было б возможным :о).-->
А так хотелось 

Вообще задача следующая, теперь как я понимаю вообще не реализуемая 

Нужно в GridView или Repeater или еще что нибудь, динамически засунуть шаблон вывода, т.е. уже созданный контрол, которые я пытаюсь динамичеки засунуть в TemplateItem соответствующих GridView или Repeater.

Подскажите пожалуйста, может быть уже есть какое - нибудь решение для этой проблемы ?

покажи код.

Обращайтесь еще   

если очень сильно захотеть... то можно и ITemplate подсовывать свой   
Это немного муторно. Но при большом и чистом желании конечно же можно сделать.
Допустим у меня есть Repeater на моей странице (взял его, потому что он самый легкий).

А теперь чтобы задать динамически свой ItemTemplate к нему. Нам нужно создать отдельный класс, который будет реализовывать ITemplate.
Допустим это будет

Ну а в коде самой страницы мы напишем вот такой не хитрый код


Добавлено через 3 минуты и 2 секунды
Да, ну и естественно ты туда можешь засовывать не только LiteralControl Но и другие контролы...

Засада заключается в том, что непонятно как присвоить этому templat'y
Contaner.DataItem, чтобы этот шаблон получал от репитера или Грида ту строку, которую
он должен успешно отобразить

а т.к исходный DataSEt может быть любой, то задача поистине нетривиальна.

Нужно как-то умодриться давать шаблону ссылку на DataItem , который нужно будет привести к GridViewRow

....  
делать это нужно будет через задницу

есть способ легче ?

И все же лучше использовать PlaceHolder и какой-нибудь флаг при бинди Repeater.
Т.е. у тебя будет какой-нибудь флаг в DataSource и по нему ты будешь определять показывать или скрывать данные.

А на кой нам нужен тогда ItemDataBound ???
Опять таки изменим несколько наш DefaultTemplate

Мы добавили сюда ID элемента.
Так же прикрепим к нашему Repeater к событию OnItemDataBound обработчик


А в behind-code мы поставим вот такой вот код

2Mymik
Насчет ItemDataBound -  я этот метот и имел в виду, когда говорил, что через задницу 
точнее не метод а событие,
дело в том, что "как-нибудь" можно реализовать,
а вот изящно, чтоб другие поняли - проблема,
я у себя в конторе предлагаю перекроить подход к разработке ASP(тема обсуждаемая в этом топе)
Соответственно и предлагаю мощно использовать шаблоны и вообще что только можно сделать custom
Одно дело - я один такой умный, другое - заразить еще человек 10 этим подходом,
Поэтому тема и обсуждается, я щас покорплю над ней, подытожу на чем мы остановились.
Затем надеюсь на дальнейшее плодотворное сотрудничество, может удасться сделать легче....

Это сообщение отредактировал(а) SpaceSpace - 15.5.2007, 07:36

2Mymik

Не подскажеш, как проделать теже манипуляции с GridView?

Добавлено через 5 минут и 20 секунд
Единственное что приходит в голову - делать через задницу 

            System.Web.UI.WebControls.TemplateField tf = new TemplateField();
            tf.ItemTemplate=...
есть другой путь?

если следовать логике данного высказывания, то можно подумать, что метод Page_Load тоже решение через задницу. А использование InvokeMember тоже плохой тон,- зачем описывать метод, давайте лучше как-то по другому будем определять. Или возьмем Type и будем вызывать все методы класса, пока не достигнем нужного результата. 
это мое ИМХО. Пока что мне кажется, что твое решение притянуто за уши. Сколько раз ты встречал такие таски, где у тебя нет существующего tamplate (за исключением когда ты пишешь свой контрол. Да и то, там люди используют классы реализующий INamingContainer и тем самым возлагают проблемы написания template на пользователя). Я не говорю, что твое решение это плохо -- исследовать возможности языка это очень похвальная миссия, тем более такой платформы как .NET Framework. Но целесообразно ли это ??? Т.е. зачем тебе это (написание такого контрола, а не исследование языка) ??? Приведи какой-нибудь надуманный, но при этом конкретный пример, когда твое творение может быть использовано ???
Перед тем как писать код, нужно всегда думать о его целесообразности. Можно написать обычный цикл, а можно пойти рекурсивным методом. На тогда надо представлять, сколько памяти занимает один виток твое рекурсии, и умножить на примерное количество ветков и еще раз умножить на примерное количество посещаемости страницы. И тогда ты сможешь понять, целесообразно ли писать рекурсивный метод работы над 10 объектами сразу при xml данных размером в 3Mb (у меня была такая ситуация. До того как я подхватил проект, реализовывалась рекурсивная работа над xml данными при обходе их и просчете всех возможных вариантов и поиска следующей ячейки, но это было когда xml максимум 60 node'ов имел. А когда он расширился до 15к ячеек при нагрузке на сервер где-то 30 запросов в секунду... Та даже при 3 запросах он уже умирал. Просто вылетал StackOverflow).
вот и в твоем случаи. целесообразно ли будет выполнять столь громоздкие вычисления по просчету количества колонок, созданию объектов классов для template... А если колонок будет "ой как много"...



У каждого метода всегда есть конкретные задачи, которые он должен выполнять. Шаг влево, шаг вправо -- расстрел.


э-э-э.. Когда ты создаешь GridView, ты описываешь колонки, так ???
Ты описываешь template для каждой колонки что тебе нужно, так ???
Вот собственно и ответ.

2Mymik

Спасибо за критику.

Таск следующего вида:
Есть сайт.
Много страниц.
На каждой странице - репитер гридвью и тд.
на одну строку - один Template/
До тех пор, пока не изобрели мониторы с высотой в километр, я думаю
можно не боятся оверфлова из-за перегрузки, мы имеем дело всего лишь с визуализацией текстовых данных из БД, посредством Вью или репитера

Как происходит процесс разработки(абстактно):
берем тз, делаем Бд, делаем Слои(БД и тд)
делаем слой web.
Потом для каждой более менее сложной задачи дизайним Контролы (много контров).

В чем мысль(жду критики):
Делаем 2 контрола(репитер и гридвью)
Делаем шаблоны вывода(что обсуждаем так рьяно)
Далее этим custom репитерам или грид вью указываем какой шаблон использовать.
Сам шаблон содержит весь дизайн и логику работы с БД(не доступа, а именно работы(constriants например))
ВсЁ!

Смысл в том, чтобы унифицировать использование репитеров или гридвью,
и абстагироваться от слоя доступа к данным.
Templates работают через DataItem,
Биндится весь сорс к вью, например,
отсюда экономия времени на  рутинную настройку(пара-тройка методов c каждого Template)

жду ответа 

а ты знаешь разницу между Server Side и Client Side ??? AFAIK, браузеры не держат в памяти весь документ.
А я говорил о Server Side. Компьютеры на хостинге тоже не всемогущие ;о)


Тогда за тебя уже все придумали. Эта штука называется Skin или Themes. 


Прямого доступа к СУБД у тебя никогда не будет. Всегда используются провайдеры для доступа к базе. Точнее для коннекта к базе. Констрейнты хранятся в СУБД и являются ее внутренней архитектурой.
А что касается логики работы или доступа. Ну-у-у-у. Вобщем-то уже давным-давно благодаря тому что asp.net может использовать бинарный код. Они хранятся с отдельных сборках... 
И вообще можно использовать ObjectDataSource для связи данных. 

  Repeater или DataList, или GridView/DataList они что, они не унифицированные ???   Ты к ним можешь прикрутить любой контейнер с данными.

2 Mymik

Полемика интересная получается  
К сожалению, самый большой недостаток людей заключается в том, что у каждого , абстрактно конечно, своя терминология и взгляд на мир вогкруг.
С твоей стороны, не очень красиво выглядит, что в своей аргументации используешь понятия, на правомерность которыйх я не посигал.  
Во- первых, что такое сайд и бесайд я в курсе, что такое AFAIK я в душе не представляю  
Во-вторых, шаблоны, ака templates используются по-умолчанию, т.к при выводе любой дата-строки существует шаблон вывода и вообще у каждого асп контрола есть шаблон вывода.
В третьих эти встроенные шаблоны меня есессно не устраивают
В четвертых, речь идет, опять же абстрактно,( боюсь задеть кого нить- своей кривой манипуляцией терминов)
о своего рода PageFactory, ControlFactory/
В пятых, повсеместен подход в разработке - ват я си ват ю гет, я имею в виду рапид средсва и методы, в которых пропагандируются разложение сложного на простое, но за счет этого дико увеличивается количество контента - исходных страниц и контролов, хотя можно было бы обойтись без некоторых ( экономия всего-лиш 20-30 %, ни на что большее не претендую, к тому же повышается требование к разработчику, так как maintanance таких проектов может усложниться)
В шестых, пробежимся по критике:
Skin или Themes - ни чего путного не скажу, признаю, не знаком, обязательно в ближайшее время ознакомлюсь
В седьмых нащет логики работы, не правильно выразился, - я имел всего-лишь то, что шаблон сам должен расставлять значения в свои поля(это самое узкое место), а не из-вне, ниже приведу пример.
В восьмых,

ясен пень, что унифицированные
Но множество методов всегда приходится дописывать ручками - листать\не листать, видеть\не видеть, PageSize... РАЗ
Для каждого контента внутри листателя- своя логика работы - два
я сам всегда использовал репитеры, но ведь придумали же вью - три - это я к тому, что листателей несколько видов, несовместимых, а контент - шаблон- template - может быть один
Отсюда - унификация, как я говорил - есть способ абстрагироваться от типа листателя и вообще(если запись одна)
Есть такое понятие TemplateView- Мартин Фаулер - Архитектура корпоративных приложений,
А что есть паттерны? Уж точно не движение в сторону упрощения понимания.

Чтобы не показаться голословным, приведу пример того что получается, надеюсь услышать критику по примеру, а не по мне  

Вот у нас есть страничка, в ней контрол

Вот у нас шаблон вывода, в нем Лэйбл

А вот бихайнд код для этого шаблона вывода


Далее Контрол - листатель
Причем заметьте, что в             <ItemTemplate /> пусто                       



Ну и код для него


ну пока вот так вот, теперь можно и поговорить конкретнее  

В жизни не подумал бы, что это недостаток :о)   
Но не будем философствовать на тему сотворения мира.

As Far As I Know

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


Мне кажется предыдущие два высказывания противоречат друг другу. Как твое решение, так и паттерны, это очень узкоспециализированное направление. Просто паттерны упрощают работы с большим количеством классов. А твое решение будет упрощать работу с большим количеством листателей. Это действительно нужно при очень большом и громоздком портале. Где нужно изменить шаблон в одном месте и чтобы он опосля поменялся во многих местах. 


Твое подход узкоспециализированный и может с большим успехом применяться в огромных проектах. Где по какой-то лени разработчики не пошли решением создания отдельных UserWebControl'ов (в которых будет прикрепляться к листателю DataSource). А решили усложнить себе задачу и клепать Template программно. 
Это твое решение :о). Паттерны тоже для маленький проектов нецелесообразны.

Кстати. Ты говорил, что при разбиении на простые вещи, код увеличивается... В том примере что привел ты, кода пока что больше чем если пойти обычным решением.

Mymik, спасибо за понимание.



Это не плохо. Я не говорил, что это плохо. Я лишь указываю на тот факт, что если предложить разработчику способ А, который заметно проще способа Б (имею ввиду переход например от ASP к ASP.NET, использование MasterPage и другие новшества вообще),
то у разработчика "выключается" думалка, что естественно, у всех так(не будем вдаваться в философию).

Рассмотрим текущую ситуацию:
Известен факт, что раньше было Write("<html>"), в некоторых случаях до сих пор в респонсе так и генерируется страница, потом был предложен подход Jsp, php, asp - шаблонный, 
все бы хорошо, но эти представления начали засирать кодом скриптлетов(и до сих пор засирают),
на это было придумано вспомогательные объекты - Behind код, имеется в виду,
все бы хорошо,  
но теперь ВСЁ делается (я не говорю категорично, а лишь привожу пример) по этому шаблону

В чем смысл идеи(может быть уже давно придуманной до меня, я не претендую на патенты  )
в том чтобы чуть чуть отойти от методологии разработки веб, не делать всё в лоб,
(страница, -> вней контрол)

таких страниц, составных контролов накапливается куча ( в относительно больших проектах, согласен с тобой,Mymik)
Напрашивается идея освободиться от дублирующих друг друга страниц и контролов
Каким образом? программным by usage паттернов построителя и фабрики,
Которые какбы должны собирать контролы из множества других поменьше,
и ,соответственно, страницы из контролов
Вот это - проблема, надо думать
И уместен вопрос - а надо ли это, и где сдесь явная выгода?
Я интуитивно чувствую, что польза есть (согласен, могу ошибаться)
В чем сдесь подвох, по моему мнению?
В том, что девелоперы привыкли использовать построители и фабрики для невизуальных объектов,
а я в свою очередь оперирую как раз такими(в сущности xml-разметкой контролов),
которые отягощены behind кодом, своего рода такие "умные" картинки получаются

Есть смысл жить этой идее?
Или ну её и начать уже работать?