Olá desenvolvedores, prosseguindo com as correções de bugs e implementações de melhorias em nosso sistema de cadastro de usuário. Agora iremos corrigir um bug no cadastro de telefone. Quando tentamos deletar um número de telefone, ele até exclui o registro, porém, nos mostra uma tela em branco e não retorna  a lista com os registros que não foram excluídos.

BUG LISTAR TELEFONE

Entenda, na tela de cadastro de usuários, logo abaixo do formulário de cadastro todos os registros estão sendo exibidos. Assim, independente da ação realizada, após finalizá-la a aplicação deve nos redirecionar de volta para a tela de cadastro, onde os registros estão sendo exibidos.

Assim, também deveria se comportar a tela de cadastro de telefones. A aplicação deve retornar também com o usuário cujo telefone está foi editado e/ou inserido. Mas não é o que está acontecendo.

Antes, porém, na servlet ServletsTelefone.java mova para fora da condição if as linhas de códigos referentes ao usuário escolhido. Sempre teremos que “setar” o user escolhido bem como a lista de telefones. E como o user em questão sempre será utilizado, melhor ampliar seu escopo de utilização.

E para corrigir o bug que está impedindo os telefones de serem carregados, no doGet para que possamos carregar a lista de telefones deveremos passar o ID do usuário e não o foneId como está implementado. A linha de código que faz a requisição da listagem dos telefones está dentro do bloco else if do bloco try.

Atente-se, quando alguma requisição é enviada da tela cadastroUsuario.jsp para, por exemplo, telefones.jsp, esta requisição é enviada pelo parâmetro de user. Assim, desse modo na tela de telefones.jsp será necessário alterar o id e o name do userEscohido.id para “user”.

Note que debugando o código podemos perceber que não temos dentro do doGet a ação do getParameter(“user”), que vem da ação de delete da página telefones.jsp. A solução passa pela criação de mais uma ação, onde passamos o user, e por parâmetro JSP o usuário do objeto fone.

BUG SALVANDO CAMPO VAZIO

Realizamos com sucesso a correção dos bugs para listar os telefones após a realização de alguma ação. Observe agora que o cadastro de telefone nos permite salvar campos vazios, isto é, consumindo poderosos recursos de processamento.

Então iremos ainda na servletsTelefone.jsp, no doPost responsável também pela ação de gravar o telefone implementar regras de validação. Assim se o campo estiver vazio, ou seja, se o número de telefone for igual a nulo ou diferente de nulo, porém sendo um campo vazio, a aplicação nos redirecionará para a mesma tela e solicitará ao usuário que informe o número de telefone.

Mas se não, se o campo não for nulo, se tiver algum número de telefone o fluxo seguirá, e as linhas de códigos serão executadas e o registrado será gravado no banco de dados.

E para que a mensagem “Informe o número de telefone!” seja exibida para o usuário, precisamos resgatá-la, por meio do atributo “msg” na tela telefones.jsp. Assim, logo acima da tag <form> insira a linha de código abaixo.

Se tentarmos salvar com o campo de telefone em branco a mensagem agora será exibida em destaque.

Mas eis que mais um bug nos é apresentado, tão logo acessamos a página de cadastro de telefone, a mensagem de “Salvo com sucesso” é carregada. E isso acontece porque a estamos carregando junto com a lista de exibir os telefones cadastrados. Parra corrigir este bug basta excluir a linha de código correspondente no doGet da ServeletsTelefone.java.

IMPLEMENTANDO MELHORIAS

E uma vez que já corrigimos os bugs da tela de telefones.jsp é hora de refinar ainda mais nossa aplicação e buscar por melhorias.

Então iremos implementar um botão para voltar a tela anterior, mas neste caso, teremos que submeter o formulário, porém, para voltar. Vamos ver na prática como podemos implementar esta ação.

Esta implementação será feita por Javascript, assim, quando o botão de voltar for clicado, o onclick vai receber a DOM – que é a árvore de elementos HTML, que por sua vez recuperará o id do formulário e invocará ação de salvarTelefones, porém recebendo como parâmetro a ação de voltar.

O próximo passo é a interceptação da ação na servlet servletsTelefone.java. A implementação será no doPost, visto que o botão de voltar está submetendo para a servlet. Assim, primeiramente iremos capturar a ação por meio do getParameter().

String acao = request.getParamenter(“acao”);

Neste cenário, se a ação for nula, ou seja, se não existir nenhuma ação ou se ela for diferente de nula e também diferente da ação de voltar, o fluxo salvar o registro de telefone será processado normalmente.

Mas se não, se ação for igual a ação de voltar, iremos redirecionar o usuário, passando o cadastro de todos os usuários.

MELHORIAS NAS ESTILIZAÇÕES

O campo referenciado pela tag <select> responsável pela seleção do tipo de telefone, está um pouco menor do que os outros. Assim na página telefones.jsp alteraremos manualmente a dimensão do campo, atribuindo um estilo a ele.

<select id=”tipo” name=”tipo” style=”width:173px;”>

E a mesma alteração do campo select poderá ser atribuida aos botões acrescentando a cada input um style=”width:173px;”. Abaixo veja como ficou a tela após estas estilizações.

E na tela cadastro de usuários poderemos mover o botão cancelar para uma célula própria e entre os botões Salvar e Cancelar inserir mais uma célula. E em ambos atribuir o estilo style=”width:173px;”.

Outra melhoria que podemos fazer é excluir da tela cadastro de usuário o campo de Telefone, visto que temos um cadastro somente para este fim. Desse modo na tela de cadastrouUsuario.jsp exclua com a célula que implementa este campo. Exclua também no banco de dados e na servlet usuario.java, exclua no doPost o campo que implementa a condição com a mensagem de que o telefone deve ser informado.

É possível também, e seria interessante limitar a quantidade de caracteres de alguns campos como o login e senha, basta apenas inserir na tag que os implementa o atributo maxlength informando a quantidade máxima permitida de caracteres. Veja abaixo um exemplo, depois basta que repita o procedimento nos campos desejados como bairro, rua, porém neste caso, o limite de caracteres pode e deve ser bem superior a 10.

EM POUCAS PALAVRAS

Então procedemos com a correção de bugs e implementamos algumas melhorias em nossa aplicação, especificamente na parte de cadastro de telefones. Espero que tenha compreendido e gostado, eu fico por aqui e nós nos vemos no próximo tutorial continuando com a correção de bugs do sistema de cadastro.