Controles dinâmicos com base no postback do usuário

Question

Suponha que eu tenha um TreeView, onde cada Treenode contém um ID para um conjunto diferente de controles do usuário. Quando o usuário clica em um nó, esses controles devem ser carregados na página. Pelo que entendi o ciclo de vida da página do ASP, os controles dinâmicos devem ser adicionados no estágio de inicialização e os eventos de postback serão lançados mais tarde.

Portanto, se o evento TreeView Click acontecer depois de precisar adicionar meus controles, como adicionar controles dinâmicos com base nos eventos de postback do usuário?

---

EDIT: Eu tentei a sugestão de Arronls:

O que fiz foi adicionar o valor do nó à matriz da sessão e usá -la quando faço o init para escolher quais elementos do formulário carregarem os controles de um controle de espaço reservado. No evento TreeView Click, atualizo o nó na matriz da sessão, limpo os elementos antigos do formulário no espaço reservado e adiciono os novos elementos de formulário aos controles. Quando a página é carregada novamente, agora deve encontrar o nó no horário init, para que os problemas do ViewState sejam contornados.

Agora ainda não testei totalmente isso, mas havia outro postagem semelhante Isso fala sobre os problemas que podem resultar com o ViewState. Eles sugerem uma solução que pesquise a solicitação [] parte do contexto (no caso deles, o Dropbox) dentro do controle init, lidando manualmente em algumas das funcionalidades de postback.

Minha nova pergunta é Como acessar o nó selecionado no TreeView usando a matriz de solicitação?

Answer 1

A conseqüência de não carregar os controles no init é que, se houver alterações nas propriedades no estado de exibição, elas não serão persistidas nos controles. Por exemplo, se, na primeira solicitação da página, você criará controles dinamicamente no init e, na postagem, você os criará novamente no init, depois depois do init, quaisquer valores de propriedade no ViewState são aplicados ao controle.

Portanto, se você criou o controle inicialmente em um evento de clique em TreeView, acho que isso deve ficar bem, porque ainda não há nenhum ViewState acumulado para aplicar ao controle, pois acabou de ser criado. No entanto, não tenho certeza se isso fará com que o controle não salve o ViewState. Você teria que experimentar com isso.

Nos postagens subsequentes após o primeiro, agora você precisará criar o controle no init para que o Viestate acumulado seja aplicado a ele, para que você precise de algum mecanismo para "lembrar" de que você criou o controle uma vez antes, inicialmente em resposta ao Clique em Evento e, em seguida, em postagens subsequentes, crie o controle novamente no init. Você precisa recriar o controle de cada solicitação, se não soubesse disso.

Portanto, a questão se torna o quão importante é o ViewState para o controle.

EDIT: Também acrescentarei que não tenho certeza se haveria outras conseqüências além de como isso afeta o ViewState.

Answer 2

Isso pode não ser uma resposta para sua pergunta direta, mas como nunca encontrei uma resposta, aqui está a solução alternativa que usei.

A abordagem que sempre usei ao trabalhar com um TreeView é declarar os controles na página ASPX uma vez e, em seguida, no evento de cliques, vincule os controles dos dados com base no ID. Se necessário, você pode definir inicialmente a visibilidade para visível = "false" e alterá -lo quando vinculado. Essa abordagem funciona bem porque evita apenas o enigma que você está descrevendo.

Se você não se opõe a desistir de visualizações de árvores, um repetidor aninhado A abordagem também funciona bem.

Answer 3

Apenas jogando outro pensamento, na esperança de obter mais feedback ...

Eu poderia usar o evento de postback para definir o valor selecionado na matriz da sessão e, em seguida, forçar a página a redirecionar para si mesma. Então, o init que o usuário vê será efetivamente feito após o manipulador de eventos ter disparado.

Parece uma má ideia, então espero por outra coisa.

Answer 4

Se eu entendi corretamente, você deseja um conteúdo diferente mostrado para cada nó da árvore. Estou assumindo que há o TreeView à esquerda e alguma área de conteúdo no meio.

Do ponto de vista da interface do usuário, eu normalmente resolvo isso usando uma visualização múltipla, onde cada visualização individual é um usercontrol separado com o conteúdo necessário. O evento Treenode Click simplesmente altera o Multiview ActiveIndex contido na propriedade Valor do nó (o ID é armazenado no datAitem) e você simplesmente alterna a área de conteúdo.

Geralmente, mesmo que os nós da árvore sejam gerados dinamicamente, a partir de dados, por exemplo, haverá apenas uma quantidade finita de "visualização do nó" UserControls que você precisa definir.

Observação. Cuidado ao usar o controle multiview, pois todas as visualizações contidas são carregadas durante o ciclo de vida da página, para que não coloque nenhum "levantamento pesado" em page_load etc.

Answer 5

Pode ajudar a lembrar que o id do nó selecionado é passado como um valor de formulário, que é sempre acessível a partir do Request.Form Coleção, mesmo durante o evento init. A chave seria algo como ctl00_Content1_TreeView1_SelectedNode. No entanto, esse ID sozinho provavelmente não teria o valor de que você precisa, então você gostaria de olhar Request.Form["__EVENTARGUMENT"] e também use Request.Form["__EVENTTARGET"] Para verificar se foi de fato o TreeView que causou o postback.

Mais do que provável, as informações necessárias podem ser retiradas da coleção de formulários. É apenas uma questão de definir um ponto de interrupção e examinar os valores. Esse tipo de código sempre parece terrivelmente hacky, mas, neste caso, você simplesmente não pode esperar que o evento do TreeView Control seja tratado quando precisar usar os valores enviados no formulário para fazer algo durante o Page_init. Apenas não tenha medo de olhar para os valores do formulário, em vez de aguardar o .NET para empacotar tudo bem com propriedades fortemente ticadas. Até então, será tarde demais.