Na seção anterior, concluímos a operação básica do carrinho de compras, mas há um problema: quando o usuário clica para liquidar, devemos fazer um julgamento de login para determinar se o usuário está conectado. Se ele não estiver conectado, ele deve primeiro deixar o usuário fazer login. Isso usa a tecnologia de filtros. O filtro intercepta especificamente solicitações de página. É semelhante ao princípio de um interceptador. O interceptador intercepta especificamente as solicitações de ação, portanto cada um tem seus próprios usos. Se for um salto de página diretamente sem passar por uma ação, só precisamos escrever um interceptador. Se precisarmos pular para uma ação para o processamento, precisamos escrever um interceptador.
1. O princípio do Login Jump <r /> Deixe -me primeiro falar sobre o princípio da implementação: escreva um filtro e configure o URL que precisa ser interceptado no web.xml. Dessa forma, quando o URL de solicitação do usuário atender à configuração, o filtro que escrevemos será executado. No filtro, primeiro verificamos se há um usuário registrado na sessão. Se não houver indicação de que não houver login, obtenha o URL da página e os parâmetros que o usuário deseja acessar, re-poste-o no URL e coloque-o na sessão e depois redirecionasse para a página de login, faça login e pule para o processamento de ação e, após o processamento, pule para a URL salva na sessão, ou seja, onde o usuário desejava ir originalmente. Isso completa o salto de login.
2. Implementação de salto de login
Quando a página real do carrinho de compras for usada, clicamos na compra e ela automaticamente pulará para a página de confirmação do pedido, como segue:
No entanto, se o usuário não estiver conectado neste momento, definitivamente não iremos para a página de confirmação do pedido diretamente, por isso precisamos usar um filtro para bloqueá -lo e fazer um julgamento. Vamos escrever o filtro abaixo:
2.1 Implementação de filtros
A implementação do filtro precisa implementar a interface do filtro e substituir três métodos. De fato, precisamos principalmente substituir um deles. do seguinte modo:
public class Userfilter implementa filtro {@Override public void Destroy () {// TODO Método Geral Goletom} @Override public void Dofilter (Solicitação de servletRequest, resposta servletResponse, cadeia de filtro) lança IoException, serviceCception {hTTTELTRETRE-FESTEMT; HttpServletResponse res = (httpServletResponse); // Determine se a sessão atual possui informações do usuário se (req.getSession (). GetAttribute ("user") == null) {// salve o endereço da URL que o cliente atual deseja ir para a string gourl = req.getServletPath (); // Obtenha o endereço que o usuário deseja ir para string parames = re -req.getquerystring (); // obtenha os parâmetros no endereço se (param! = Null) {gourl = gourl + "?" + param; // re-estith o endereço de solicitação + parâmetros} // salve o endereço que o cliente atual deseja acessar na sessão req.getSession (). SetAttribute ("gourl", gourl); // Solicitação ilegal, pule para a página de login req.getSession (). SetAttribute ("Erro", "Solicitação ilegal, faça login!"); Res.sendRedirect (req.getContextPath () + "/ulogin.jsp"); } else {// Se houver o próximo filtro, pule, caso contrário, vá diretamente para a cadeia de páginas de destino.Dofilter (solicitação, resposta); }} @Override public void init (filterConfig Config) lança servletexception {// TODO Method Auto-Generated Stub}} A julgar pelo código de implementação, o método Dofilter é principalmente diarréia. No método, primeiro determine se há informações do usuário na sessão atual. Caso contrário, significa que não há login. Em seguida, você deve primeiro salvar o endereço e os parâmetros do URL no endereço que o usuário deseja ir, soletre -o em um novo URL e salvá -lo na sessão e depois redirecioná -lo para a página de login para permitir que o usuário faça login. Se houver informações do usuário na sessão, isso significa que você está conectado e diretamente o lançar para a página que o usuário desejar.
Depois de escrever o filtro, não se esqueça de configurar o URL para filtrar no web.xml, como segue:
Portanto, o $ {shop} /User/confirm.jsp será filtrado. Em seguida, vamos dar uma olhada na página de login. Na verdade, ele tem duas caixas, nome de usuário e senha, que depende principalmente de qual ação ele salta:
Vemos que ele salta para o método de login no UserAction para executar a lógica. Aqui implementamos o userAction:
2.2 Implementação de ação
Na UserAction, primeiro fazemos um julgamento de login, ou seja, procure usuários com o nome de usuário e a senha no banco de dados. Se for bem -sucedido, salve o usuário na sessão e retorne um resultado e entregue -o ao Struts2 para processamento. O código é o seguinte:
@Controller ("UserAction") @Scope ("prototype") public class UserAction estende Baseaction <suser> {public String Login () {// Julgamento do Login Model = UserService.Login (Model); if (modelo == null) {session.put ("error", "login falhou"); retornar "login"; } else {// Login com sucesso, primeiro armazene o usuário na sessão session.put ("user", modelo); // Defenda o salto da página com base no fato de o gourl na sessão ter um valor se (session.get ("gourl") == null) {return "index"; // Pule para a página inicial} else {return "gourl"; }}}}Vamos dar uma olhada na configuração em struts.xml:
Como temos o GOURL em sessão, mas no Struts.xml, não podemos obter a sessão e, em seguida, os parâmetros no código Java, mas podemos retirá -la da pilha de valores. O acima é o método de obter dados da pilha de valor.
2.3 Julgamento de login da camada de serviço
A camada de serviço é principalmente o método de login usado na ação acima, e a implementação é relativamente simples, como segue:
// interface de usuários da interface pública UserService Extende BaseService <suário> {// O usuário efetua login e retorna o usuário do usuário do usuário Login (usuário do usuário); } // UserServiceImpl implementations @service ("UserService") Public class UserServiceImpl estende o BaseServiceImpl <suser> implementa UserService {@Override public User Login (usuário do usuário) {String hql = "do usuário u where U.Login =: Login e U.Pass =: Pass"; return (usuário) getSession (). createEquery (hQL) // .SetString ("Login", user.getLogin ()) // .SetString ("pass", user.getpass ()) // .unikeResult (); }}OK, então usamos filtros para realizar o julgamento e o salto do login de usuários. Após o login, podemos pular para a página de confirmação do pedido. O efeito é o seguinte:
Todo o teste do processo foi concluído e a função é normal. Na verdade, podemos melhorá -lo um pouco mais. Deveríamos realmente fazer um julgamento de login antes de adicioná -lo ao carrinho de compras. Ou seja, a página do carrinho de compras já está no estado de login e aqui está a página de confirmação do pedido para determinar o login. No entanto, se fizermos julgamentos antes da página do carrinho de compras, será difícil usar o filtro. Temos que usar o interceptador, porque a solicitação de ação não é uma página comum ao pular para a página do carrinho de compras. Ao solicitar ações, precisamos usar o interceptador para interceptar. Vamos melhorar isso mais tarde. Agora, basicamente, implementaremos as funções aqui. Ok, o julgamento e o salto de login estão feitos.
Endereço original: http://blog.csdn.net/eson_15/article/details/51425010
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.