Atenção: por essa edição ser muito antiga não há arquivo PDF para download. Os artigos dessa edição estão disponíveis somente através do formato HTML.
XMLBroker - Parte Final
Trate os erros no lado servidor
Antes de adentrarmos no último tópico sobre a palheta Internet Express, gostaria de agradecer a todos que acompanharam a matéria e enviaram emails com dúvidas e sugestões. Esse tipo de interação é muito importante, em todas as matérias, pois direciona o autor para as reais necessidades de quem está lendo o artigo.
Vamos começar relembrando: construímos uma página de cadastro de usuários, através dos objetos XMLBroker e MidasPageProducer. Vimos que é possível automatizar bastante a construção, já que estes objetos cuidam de toda a manipulação e exibição dos dados. Isto gera um ganho considerável de tempo no desenvolvimento, pois não precisamos nos preocupar em ler os dados da tabela, substituí-los em tags transparentes, pegar o resultado e gravar novamente no banco.
Na edição anterior inserimos, na página cadcli.html, um código javascript para validação do conteúdo dos objetos de edição. Com isso, fica faltando um detalhe para que nossa aplicação esteja pronta para ir ao ar – a validação do lado servidor. Haverá casos onde o JavaScript não será suficiente, pois somente no servidor teremos a capacidade de validar os dados. No nosso exemplo, temos que impedir a existência de emails duplicados, pois ele é o login e identificador do usuário. Não temos como saber isso dentro do browser.
Podemos fazer a validação de duas formas: indicar dentro do banco de dados que o campo EMAIL será único (unique) ou criar uma rotina de validação no próprio Delphi. Neste exemplo, a crítica será feita no Delphi, pois desse modo você poderá aproveitar a idéia e substituir a rotina por qualquer outra validação server-sided.
O funcionamento será parecido com o de qualquer site profissional: o usuário irá digitar o email e as demais informações. Após submeter o formulário, a cgi irá pesquisar o email no banco para saber se já foi cadastrado. Se já existir, a cgi retornará um erro, preenchendo novamente o formulário com os dados já digitados pelo usuário. Repare que iremos retornar os dados que o usuário digitou manualmente, visto que os mesmos não serão escritos no banco até que o usuário informe um email válido. Veremos a seguir como isso funciona na prática.
O primeiro passo é codificar a validação do email duplicado. Isso já estamos cansados de fazer, vamos dar um select e pegar o resultado. O problema é saber onde criar o código, pois nosso webmodule já possui uma infinidade de objetos - query, datasetprovider, midaspageproducer e xmlbroker. Se conhecermos exatamente o papel de cada componente, será fácil identificar o lugar correto para inserir uma determinada rotina. Veja o gráfico abaixo:
Ora, repare que os componentes estão divididos em dois grupos. A Tquery e o TDataSetProvider são responsáveis por ler e disponibilizar os dados do banco. Já o MidasPageProducer e o XMLBroker são responsáveis em pegar os dados e formatá-los para o browser. O XMLBroker é o responsável em ler os dados e transformá-los em XML e o MidasPageProducer é o responsável por montar a página, concatenando o pacote XML recebido pelo XMLBroker com o código HTML e JavaScript. E o DataSetProvider? Qual o seu papel verdadeiro? Como vimos na primeira parte do artigo, o DataSetProvider não está adicionando nenhuma funcionalidade no exemplo. Ele está presente somente para evitar a criação de um servidor MIDAS de dados, permitindo que o objeto XMLBroker se conecte com a query dentro do mesmo WebModule. O objeto XMLBroker utiliza a tecnologia MIDAS, e por default, deveria se conectar a um servidor MIDAS. Se tivéssemos criado este servidor, nossa conexão seria conforme o gráfico abaixo:
A presença de um servidor MIDAS traz algumas vantagens, pois permite a aplicação estar mais preparada para receber uma quantidade muito grande de acessos. A manutenção do site também se torna uma tarefa menos desgastante, pois a lógica pode residir dentro da aplicação servidora. Por exemplo, ao invés de trabalharmos com comandos SQL dentro da cgi, podemos criar procedures e funções na aplicação servidora “mascarando” os comandos SQL. Se alguém decidir trocar o banco de dados, somente as procedures e funções terão de ser reescritas, e não toda a aplicação (lembre-se que os SGBDs possuem pequenas diferenças na sintaxe SQL).
