Quick access: The NWS Web page Model Implementation of a WAR (Web ARchive) The associated page class Deployment of the application on the server First tests
The NWS framework will allow you to build a Web application. This application will consist of a set of web pages. Each web page will be divided into two distinct parts:
This approach allows you to separate the display from the code of your page. As we shall see, the NWS framework focuses on the programming event. Therefore, the event handlers will be located in the page class. The technology of data link will allow guaranteeing that the web page will not contain any line of code.
CONTRARY TO JSP, NWS DOESN’T ALLOW TO INJECT THE CODE DIRECTLY INTO THE WEB PAGE, USING A SEQUENCE <%= %> OR EQUIVALENT.
The web page will be link up with the class page, but it will not be a legacy link. The web page is an XML document, it is charged through a DOM (Document Object Model). It is not used to produce a class of Java code that could inherit of anything. Some may insist on the fact that to not compile the web page can induced performance less interesting, although it confers other possibilities in terms of generation of dynamic tag. We will return to this subject later.
NWS relies on a servlet engine. As such, it can be deployed on any J2EE Application Server (JBoss, ...). It is therefore necessary that your application complies with the concept of WAR (Web ARchive) defined in J2EE (Java 2 Enterprise Edition).
A WAR is a Java archive, which contains a set of directories and specific files. Rely us on the VirtualCaddy demonstration implementation. The diagram presented shows the directory structure used by this application.
The NWS web pages (recognizable by the extension .wp) must be placed directly in the VirtualCaddy directory. If your application uses pictures, it is possible for you to place these pictures in a subdirectory called Images, but it is not a requirement. You could have put your pictures at the same level as the Web pages.
The WEB-INF directory is very important. It must be spelled in capital letters. It contains all the compiled Java classes (filed or not). The Java libraries will be located in the lib subdirectory: it will not be necessary to force the CLASSPATH environment variable, because all the jar (Java ARchive) placed in this directory are implicitly accessible. The not archived files .class, will be placed in the classes subdirectory. It is not necessary to deploy the source code, of the application over the WAR, to works! However, I provided you in an educational context.
The WEB-INF directory also contains a configuration file for your Web application: the famous web.xml. This file is also called "deployment descriptor". The use of a XML deployment descriptor is also required by J2EE. Here is an example of content for the VirtualCaddy/WEB-INF/web.xml file.
01 <?xml version="1.0" encoding="UTF-8"?> 02 <!DOCTYPE web-app PUBLIC 03 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" 04 "http://java.sun.com/dtd/web-app_2_3.dtd"> 05 06 07 <web-app> 08 09 <display-name>Virtual Caddy - NWS Sample</display-name> 10 <description>NWS Sample</description> 11 12 <context-param> 13 <param-name>TRACE_ENABLED</param-name> 14 <param-value>true</param-value> 15 </context-param> 16 <context-param> 17 <param-name>TRACE_LOCALHOST_ONLY</param-name> 18 <param-value>true</param-value> 19 </context-param> 20 <context-param> 21 <param-name>TRACE_URI</param-name> 22 <param-value>Trace.wp</param-value> 23 </context-param> 24 25 26 <servlet> 27 <servlet-name>NWS Servlet</servlet-name> 28 <servlet-class>corelib.services.web.server.ControllerServlet</servlet-class> 29 </servlet> 30 31 <servlet-mapping> 32 <servlet-name>NWS Servlet</servlet-name> 33 <url-pattern>*.wp</url-pattern> 34 </servlet-mapping> 35 36 </web-app>
Some explanations! We can say that this file is made up of three distinct parts. The first part gives some general information on the Web application (the name and the description).
The second part is used to configure the module (pas sur) of the NWS integrated trace. The trace module is a tool of resolution very powerful that can allow recording all the details of the complaints (sessions, settings, etc.) issued to the server. This module can be activated or not. It is that conclude the TRACE_ENABLED parameter. The third parameter specifies the ending of the URL for invoking the historical traces. You will need to enter the URL http://localhost:8080/VirtualCaddy/Trace.wp in your browser to get this history. The screenshot below shows an example of the historical traces obtained.
Finally, the third part allow you to putt the servlet (a web component), which will respond to all queries ending with .wp. This servlet is proposed by the NWS framework. Note that the class of the servlet is mapped to the url-pattern through a name: it must be the same in both blocks (servlet and servlet-mapping).
In conclusion, to transform a WAR into a NWS Web application, it is necessary to move the file nws.jar in the directory WEB-INF/lib/. It is also necessary to edit the web.xml file properly, in order to mount in memory the servlet which have to respond to the NWS Web pages requests.
We will now look the coding of a web page itself. To do this you need, as we have seen earlier in this document, to edit two files. We talk about a class of Java code and the Web page. These two files will allow the page to properly respond to the HTTP requests. We will start to examine the content of the NWS page. Here is a example.
01 <?xml version="1.0" encoding="ISO-8859-1" ?> 02 <web:Html xmlns:web="corelib.services.web.components" 03 codeBehind="corelib.services.web.samples.virtualcaddy.webpages.Login"> 04 <head> 05 <title>Logon screen</title> 06 <link rel="stylesheet" type="text/css" href="CssStyles.css" /> 07 </head> 08 <body> 09 <h1>Logon screen</h1> <br /> 10 11 <web:Form focus="txtLogin" method="post"> 12 <div align="center"> 13 Login : <web:TextBox id="txtLogin" value="Malone" /> 14 <web:RequiredValidator componentToValidate="txtLogin" 15 errorMessage="Value is required" cssClass="Validator" /> 16 <br/> 17 18 Password : 19 <web:TextBox id="txtPassword" value="P@ssw0rd" type="password" /> 20 <web:RequiredValidator componentToValidate="txtPassword" 21 errorMessage="Value is required" cssClass="Validator" /> 22 <br /> <br/> 23 24 <web:Button id="btnConnect" value="Connect" /> <br /> 25 <web:OutputText id="lblResult" /> <hr /> 26 27 <div id="divTime" runAt="server"></div> 28 </div> 29 </web:Form> 30 </body> 31 </web:Html>
As you can see, we are dealing with an XML file that contains nevertheless a set of HTML tags to define the page structure. But if you look more closely, there are also other tags.
These tags can be used to create NWS components on the server side, which after the processing of the page, will generate HTML. This approach can create reusable Web components, which will accept events and a sample data link for example (we will return later). But it is necessary that the NWS framework can make the link between the Java class component and the equivalent tag in the web page. To do this, two method are possible.
First Method: you use the concept of XML namespace for storing the package containing the considered class. The tag <corelib.services.web.components:Button /> will allow you to instantiate a component of type corelib.services.web.components.Button.
Second Method: this is the one which is shown in the previous web page example. The XML language allows you to define aliases on the namespaces used. This is done traditionally on the root tag of your XML document through the construction xmlns:alias="URI". The NWS framework uses again this method to define aliases on the used packages. Thus, if we consider the Web page before, the tag <web:TextBox id="txtLogin" value="Malone" /> is based on web alias which is put together (on the tag <web:Html>) with the package corelib.services.web.components. Of course, this package will provide a TextBox class.
Whatever the method used, you do not have the choice on the name tag. If you want to create an object of type Button, the part after the character must be necessary of type Button. Then you can write that a class exposes properties: methods of access to the attributes of the class. In Java, the attributes accessors comply with the JavaBeans model. NWS respects this standard. Thus, <web:Button value="Hello" /> will create in memory, at the Web server, an object of type corelib.services.web.components.Button where the method setValue will be invoked to remember the "Hello" value.
In contrary to the implementation of a simple Web page, the NWS framework is very strict. If a NWS Web component does not match exactly to a class or if one of the attributes of the tag does not match to one of the properties of the considered class, an error will be returned.
In absolute, a NWS Web page is not obligated to be associated with a class of NWS page. If you do not want to associate code with it, you must use the attribute codeBehind="corelib.services.web.server.WebPage" on the tag <web:Html>. BE CARREFULL: if you do not use a top class, you will be unable to define an event handlers on your NWS Web components!
If you want to provide a page class, start first by coding it. A NWS page has a particular life cycle induced by the internal functioning of the framework. We will return later on the details of the life cycle of a NWS page. Nevertheless, in responding to various stages of this life cycle, you need to redefine certain methods. These methods are defined on the class corelib.services.web.server.WebPage: your Java class must inherit of WebPage and redefine some key methods. Here is an example of the NWS page class.
01 package corelib.services.web.samples.virtualcaddy.webpages; 02 03 import corelib.services.web.components.Button; 04 import corelib.services.web.components.OutputText; 05 import corelib.services.web.components.TextBox; 06 import corelib.services.web.components.events.ActionEvent; 07 import corelib.services.web.components.events.ActionListener; 08 import corelib.services.web.samples.virtualcaddy.business.UserHome; 09 import corelib.services.web.server.WebPage; 10 import corelib.services.web.server.events.WebPageEvent; 11 12 public class Login extends WebPage { 13 14 private TextBox txtLogin = null; 15 private TextBox txtPassword = null; 16 private Button btnConnect = null; 17 private OutputText lblResult = null; 18 19 20 public void page_load( WebPageEvent webPageEvent ) { 21 this.traceLogger.info( "Virtual Caddy", "page_load" ); 22 this.btnConnect.addActionListener( new ActionListener() { 23 public void actionPerformed( ActionEvent event ) { 24 btnConnect_actionPerformed( event ); 25 } 26 }); 27 } 28 29 public void btnConnect_actionPerformed( ActionEvent event ) { 30 String login = txtLogin.getValue(); 31 String password = txtPassword.getValue(); 32 33 if ( UserHome.findByConnectInformations( login, password ) != null ) { 35 this.redirect( "SelectArticle.wp" ); 39 } else { 40 lblResult.setText( "Bad connection for user : " + login ); 41 this.traceLogger.warning( "Virtual Caddy", "Bad connection" ); 42 this.traceLogger.error( "Virtual Caddy", "Bad connection" ); 43 } 44 } 45 }
So, as we say, the Line 12 declares the class being derived from the WebPage class. Then, some attributes are defined: do not seek to instantiate these attributes (do not place any new), it would serve no purpose because the NWS framework will do it automatically. However, note that the names of these attributes and their types must correspond exactly to what is stated in the associated Web page. The data which are entered (on the browser) from these components will be transferred in the HTTP request, recovered by the NWS framework and stored in the bodies of Web components which we are talking. Unlike some framework of Web development (including servlet and JSP), it is not necessary to extract data from the HTTP request: it is done automatically.
In these four attributes, we can find two areas of text entry (line 14 and 15), a button for submission of the form and a label allowing, from the server response (to the browser), to refer a message following a bad submission of the form. Note that these three types of components NWS are part of the corelib.services.web.components package.
Then, on line 20, we have the page_load method: it has been redefined and is part of the life cycle of a NWS page. It will be called by the framework as soon as the page is completely built in the Web server, but before the return of the HTML response. This method realizes two things: in line 21, a record is added (you can display it by asking the traces display - http://localhost:8080/VirtualCaddy/Trace.wp) and on line 22 a button click handler is added.
Be careful, we are talking here about an event handler of server type. If the reader clicks the form button (in the used browser), the data entered into the form is sent to the server, and the method btnConnect_actionPerformed will then be invoked. Note that the management of the events following the emphasized method (always by the JavaBeans model) by Java: the famous listeners (or écouteurs in french).
Finally, from line 29, we find the code of our event handler on the server side. This one will get the data entered for the login and the password (line 30 and 31) and verifies if the connection of this user is allowed or not. Here is a valid login/password couple: Login=Malone and Password=P@ssw0rd (these are the default values entered in the form). The more curious of you can see the code of the UserHome class: it is intended to simulate a database containing a table of authorized users which are allowed to connect from our demonstration application.
As we have already seen in the previous chapter, to deploy your application in a Tomcat server, you simply need to copy your WAR in the webapps directory. Nevertheless, this step can be performed manually or automatically through an ANT script .
If Tomcat is not already started, be sure to do it now. You already have to launch an Internet browser, and sear in the address bar the following URL : http://localhost:8080/VirtualCaddy/Logon.wp.
If all goes well, an authentication screen should appear. Test this screen with any identity, and then test the login and the expected password and you should go to the next screen. Then, you could also try to show the trace using the following address: http://localhost:8080/VirtualCaddy/Trace.wp. You should find in the report traces the information that have been recorded during the authentication tests.
Dominique LIARD - © 2007 SARL Infini Software - All rights reserved Other brands and product names in these documents are the property of their respective owners.