Seguindo a linha do artigo anterior, podemos ligar alguns controle diretamente à elementos de um data island XML. Mas quem disse que esses elementos precisam ser read-only ?
No artigo anterior, colocamos um exemplo de uma hipotética listagem de nomes e telefones, indicando uma possível alternativa à criação de cada linha da tebla individualmente. Se você ainda não leu, leia antes de continuar este.
Caso precisássemos alterar os dados da tal lista, fatalmente cairíamos em um código como o abaixo:
<%
'...
response.write "<form method=""post"">"
response.write "<table>"
do while not rs.eof
response.write " <tr><td>"
'Criar um campo hidden com o ID, e dois campos: um para o nome e outro para o telefone
response.write "<input name=""id_" & rs("id") & """ type=""hidden"" value=""" & rs("id") & """ />"
response.write "<input name=""nome_" & rs("id") & """ type=""text"" value=""" & rs("nome") & """ />"
response.write "</td><td>"
response.write "<input name=""tel_" & rs("id") & """ type=""text"" value=""" & rs("telefone") & """ />"
response.write "</td></tr>"
rs.MoveNext
loop
response.write " <tr><td colspan=""2""><input type=""submit"" /></td></tr>"
response.write "</table>"
response.write "</form>"
%>
Como ficaria o código de leitura dos campos, quando este FORM fosse enviado ? Provavelmente teríamos um loop entre todos os itens da collection Request.Form. Se tivéssemos o azar de ter diversos campos, com características diferentes, seria um pouco mais problemático. Mas, como seria com data binding ?
Tomando como base a mesma rotina de criação de XML do artigo anterior, só precisariámos do seguinte:
<%
'... conexão do banco de dados e construção do documento XML
%>
<xml id="dsoLista"><%= oXMLDoc.xml %></xml>
<table datasrc="#dsoLista">
<tr>
<td><input type="text" datafld="nome" /></td>
<td><input type="text" datafld="tel" /></td>
</tr>
</table>
<xmp id="listagemXML"></xmp>
Tão logo um elemento seja alterado, o valor correspondente reflete tal alteração. Duvida ? Então acrescente o código:
<SCRIPT FOR="dsoLista" EVENT="oncellchange">
// Precisamos da pausa, pois quando este evento é disparado, a fonte de dados ainda não foi alterada
setTimeout( "listagemXML.innerText = dsoLista.xml", 50 )
</SCRIPT>
Caso você monte um documento pequeno, verá as mudanças acontecendo.
"Mas, e o ID ?"
Calma, para entender o por quê não colocamos referências ao ID, devemos entender o que está acontecendo. Estamos ligando controles a elementos de um data island (ou seja, fazendo um "data binding"). Quando alteramos um elemento, essa alteração automaticamente se reflete no data island. Então, da forma como estruturamos o XML, é desnecessário saber qual o ID. Eventualmente, poderíamos criar um elemento que representasse o estado de um registro, se ele foi alterado ou não. Aí as coisas ficam mais claras no ASP.
"Quais os elementos que suportam data binding ?" (Ctrl-C, Ctrl-V so site da MS)
| Element | Updatable | Renders HTML | Bound Property |
|---|---|---|---|
| A | False | False | href |
| APPLET | True | False | property value via PARAM |
| BUTTON | False | True | innerText, innerHTML |
| DIV | False | True | innerText, innerHTML |
| FRAME | False | False | src |
| IFRAME | False | False | src |
| IMG | False | False | src |
| INPUT TYPE=BUTTON | False | True | innerText, innerHTML |
| INPUT TYPE=CHECKBOX | True | False | checked |
| INPUT TYPE=HIDDEN | True | False | value |
| INPUT TYPE=PASSWORD | True | False | value |
| INPUT TYPE=RADIO | True | False | checked |
| INPUT TYPE=TEXT | True | False | value |
| LABEL | False | True | innerText, innerHTML |
| LEGEND | False | True | innerText, innerHTML |
| MARQUEE | False | True | innerText, innerHTML |
| SELECT | True | False | obj.options(obj.selectedIndex).text |
| SPAN | False | True | innerText, innerHTML |
| TEXTAREA | True | False | value |
"Que vantagem Maria leva ?"
Bom, tendo um documento XML, as coisas são mais simples de pesquisar. Vamos supor que você precise consistir os dados entrados novamente no servidor (e sabemos o quanto isso é frequente). Você poderia pesquisar relacionamentos entre os dados do documento XML, ou caso queira sofisticar, criar um documento XML Schema que contenha as regras de como validar os dados e, com uma linha de código, eles seriam verificados, poupando código e deixando o mesmo mais simples de sofrer alterações (essas seriam feitas em apenas um lugar).
"Mas, eu vou precisar gerar um documento XML sempre ?"
Hummmm, mais ou menos. Quando pensamos em aplicações em n-tiers, há uma ampla gama de possibilidades retornadas pelo middle-tier para o ASP (o componente retorna informações que são tratadas no ASP). Por que não retornar as informações como uma string XML ? Pelo fato de estarmos utilizando um tipo de dado simples, a própria comunicação com o componente seria mais rápida e evitaríamos os problemas de tipagem de dados. Criando um middle-tier que retorna dados em formato XML, tornamos possível a reutilização deste código, uma vez que a base de aplicações que suporta XML não pára de crescer. Assim, em última análise, sempre deveríamos ter a transmissão de dados em um formato padrão, e, mais padrão que XML é difícil.. :)
"Ok, engraçadinho! E como fazer a aleteração dos dados ?"
Há duas possibilidades: a primeira é, no evento onsubmit do formulário que será retornado ao servidor, alimentarmos um elemento TEXTAREA com os dados do Data Island e reconstruirmos o objeto no servidor. Uma segunda, envolve os conceitos discutidos no artigo "Transferência de dados com XML + ASP", quando usamos o XMLHTTP para fazer a transferência do próprio objeto. A segunda é mais comum nas aplicações que desenvolvi recentemente, pois contamos com uma vantagem: a ausência de refresh. Podemos, desta forma, postar um conteúdo para o servidor, deixar que ele processe e aguardar uma resposta, indicando o status da operação, sem sair da página. Interessante, não ?
Por hoje é só pe-pessoal. Divirtam-se :)
0 comentários:
Postar um comentário