zk-framework: so laden zul Seiten aus dem WEB-INF-Verzeichnis unter zul

Bin ich mit dem zk framework 6.
Ich versuchte meine zul-Seiten /WEB-INF/zul-Verzeichnis.
Mein index.zul-Datei leitet die Anfrage nach /WEB-INF/zul/login.zul hat ein Komponist LoginComposer.
Aber wenn ich auf login-Seite möchte ich umleiten der Benutzer zu einer anderen Seite, z.B. nach Hause.zul. Aber ich bin immer 404-Fehler.

Beide anmelden.zul und zu Hause.zul sind in zul-Verzeichnis zusammen mit den jeweiligen Komponisten.

in loginComposer.java ich habe den folgenden code zur Weiterleitung auf die Homepage, die aufgerufen wird, auf eine Schaltfläche klicken.

 Execution exec = Executions.getCurrent();
                HttpServletResponse response = (HttpServletResponse)exec.getNativeResponse();
                response.sendRedirect(response.encodeRedirectURL("/WEB-INF/zul/home.zul")); //assume there is /login
                exec.setVoided(true); 

Erstellt habe ich das Projekt als zk-Projekt von eclipse und ich habe keine änderungen an web.xml.

bitte leite mich, wie kann ich von hier aus gehen.

Danke im Voraus.

web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
  <display-name>abc</display-name>
  <listener>
    <description>
    Used to cleanup when a session is destroyed</description>
    <display-name>ZK Session cleaner</display-name>
    <listener-class>org.zkoss.zk.ui.http.HttpSessionListener</listener-class>
  </listener>
  <servlet>
    <description>
    The ZK loader for ZUML pages</description>
    <servlet-name>zkLoader</servlet-name>
    <servlet-class>org.zkoss.zk.ui.http.DHtmlLayoutServlet</servlet-class>
    <init-param>
        <param-name>update-uri</param-name>
        <param-value>/zkau</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet>
    <description>
    The asynchronous update engine for ZK</description>
    <servlet-name>auEngine</servlet-name>
    <servlet-class>org.zkoss.zk.au.http.DHtmlUpdateServlet</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>zkLoader</servlet-name>
    <url-pattern>*.zul</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>zkLoader</servlet-name>
    <url-pattern>*.zhtml</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>auEngine</servlet-name>
    <url-pattern>/zkau/*</url-pattern>
  </servlet-mapping>
  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
    <welcome-file>default.html</welcome-file>
    <welcome-file>default.htm</welcome-file>
    <welcome-file>default.jsp</welcome-file>
    <welcome-file>index.zul</welcome-file>
  </welcome-file-list>
</web-app>

zk.xml

<?xml version="1.0" encoding="UTF-8"?>

<!--
    Created by ZK Studio
-->

<zk>

        <device-config>
            <device-type>ajax</device-type>
            <timeout-uri>/timeout.zul</timeout-uri><!-- An empty URL can cause the browser to reload the same URL -->
        </device-config>

    </zk>

LoginComposer.java

public class LoginComposer extends SelectorComposer<Component>{

    private static final long serialVersionUID = -1657004425904043268L;

    @Wire
    private Button buttontestButton;

    @Listen("onClick = #testButton")
    public void cancelButton(){


             Executions.sendRedirect("/WEB-INF/zul/home.zul");


    }
}
Ist dein login-Seite, Feder kontrolliert?
Nein, es ist einfach zk
warum wollen Sie, um Ihre zul-Verzeichnis unter WEB-INF anstelle von WebContent ?
denn es ist gängige Praxis in der java-web-Entwicklung. Es schützt die Seiten vor dem direkten Zugriff. Wir verwenden ähnliche Mechanismen für jsps auch. Deshalb möchte ich diese Praxis befolgen.
Wenn Sie wirklich über Sicherheit, ich denke, es ist besser, Feder für auth und Zuordnung/Sicherung von urls.

InformationsquelleAutor vicky | 2012-12-31

Schreibe einen Kommentar