This tutorial unit demonstrates how to create project files in the IDE, and introduces you to some of the facilities available for HTML and CSS development. After creating necessary project files, you begin organizing the front-end of the application. That is, you’ll place JSP files in their proper locations within the project structure, create a header and footer which will be applied to all views, and set up the controller servlet to handle incoming requests.

In this unit, you also create a web deployment descriptor (web.xml file) for the application. You can use the deployment descriptor to specify configuration information which is read by the server during deployment. Although the Servlet 3.0 Specification, included in Java EE 6, enables you to use class annotations in place of XML, you may still require the deployment descriptor to configure certain elements of your application. Specifically, in this unit you add directives for the header and footer and specify which files they will be applied to.

One of the goals of this tutorial unit is to create JSP pages that correspond to the views specified in the application design. Referring back to the page mockups and process flow diagram, you begin implementing page layouts according to the mockups by creating placeholders for all visual and functional components. This unit provides a guide for implementing the layout of the welcome page. You can apply the outlined steps to create the other pages on your own, or download project snapshot 1, which provides completed layouts for all pages.

You can view a live demo of the application that you build in this tutorial: NetBeans E-commerce Tutorial Demo Application.

Notes:

To create new files for your project, access the IDE’s File wizard. You can click the New File ( ) button, press Ctrl-N (⌘-N on Mac), or in the Projects window, right-click the folder node that will contain the new file, and choose New > [file-type]. In the following sub-sections, create JSP pages and a stylesheet for the project.

The purpose of this section is to design the page views so that they begin to mirror the provided page mockups. As such, they’ll serve as a scaffolding which you can use to insert dynamic content during later stages of project development. To do so, you’ll utilize the IDE’s HTML and CSS editors, along with several CSS support windows.

Browser compatibility note: This tutorial uses Firefox 3 and does not guarantee that page view markup is compatible with other modern browsers. Naturally, when working with front-end web technologies (HTML, CSS, JavaScript) you would need take measures to ensure that your web pages render properly in the browsers and browser versions that you expect visitors to your site will be using (typically Internet Explorer, Firefox, Safari, Chrome, and Opera). When working in the IDE, you can set the browser you want your application to open in. Choose Tools > Options (NetBeans > Preferences on Mac), and under the General tab in the Options window, select the browser you want to use from the Web Browser drop-down. The IDE detects browsers installed to their default locations. If a browser installed on your computer is not displayed, click the Edit button and register the browser manually.

Preparing the display of your web pages is usually an iterative process which you would fine-tune with regular feedback from the customer. The following steps are designed to introduce you to the facilities provided by the IDE, and demonstrate how to get started using the welcome page mockup as an example.

In the above code, you use a <div id="widgetBar"> element to contain the the language toggle and shopping cart widget.

Looking back at the page mockups that were created, you can see that the welcome page should look the same whenever it is requested, for whomever requests it. That is, the content that displays on the welcome page is not determined by a user’s session. (Sessions are discussed in Unit 8, Managing Sessions.) Notice however that all other pages do need some form of user-specific information to display properly. For example, the category page requires that the user select a category in order to display, and the cart page needs to know all items currently held in a shopper’s cart. These pages will not render properly if the server isn’t able to associate user-specific information with an incoming request. Therefore, we do not want these pages to be accessed directly from a browser’s address bar. The project’s WEB-INF folder can be used for this purpose: any resources contained in the WEB-INF folder are not directly accessible from a browser.

Create a new folder named view, and place it in the WEB-INF folder. Then move all JSP pages other than the welcome page into this new folder.

You can do this by clicking on cart.jsp to select it, then Shift-clicking on confirmation.jsp. This selects the four files. Then, with the four files selected, click and drag them into the WEB-INF/view folder.

To demonstrate that these pages are no longer accessible from a browser, click the Run Project ( ) button to run the project. When the application displays in your browser, enter the full path to any of these files in the address bar. For example, type in:

You receive an HTTP Status 404 message, indicating that the resource is not available.

Looking at the page mockups, it is easy to see that all of the five views share identical content; at the top, they contain the company logo, a language toggle, and other widgets associated with shopping cart functionality. At the bottom, they contain some text with Privacy Policy and Contact links. Rather than including this code in each page source file, we can factor it out into two JSP fragments: a header and a footer. We’ll then include the fragment files into page views whenever they need to be rendered.

For these fragments, let’s create a new folder named jspf, and place it within WEB-INF.

Menu items provided by the IDE are often context-sensitive. For example, because you right-clicked the WEB-INF node, when the New Folder wizard displayed, web/WEB-INF was automatically entered in the Parent Folder field. Likewise, when you right-click a node in the Projects window and choose New, the list of file types is partially determined by your previous selections.

When you finish, you’ll see header.jspf and footer.jspf displayed in your Projects window:

Now, you can copy the header code from any of the JSP pages and paste it into the header.jspf file. Likewise, you can copy the footer code from any of the JSP pages and paste it into the footer.jspf file. When you finish this task, you can remove the header and footer code from all of the JSP pages.

So far, you’ve placed views in their proper location and have factored out common header and footer code into the header.jspf and footer.jspf files. The application still needs to know which pages the header and footer files will be applied to. You could add <jsp:include> tags to each of the page views. Doing so however would just reintroduce the code repetition which we’ve just made efforts to eliminate. An alternative solution would be to create a web.xml deployment descriptor, and add a JSP Property Group directive to specify which page views the header and footer fragments should apply to.

The interface is categorized by the areas that can be configured in a web application. These areas are displayed as tabs in the editor toolbar, and include topics such as Servlets, Filters, References, and Security. The XML tab displays the entire source code for the file. Any changes you make in the graphical interface will cause immediate updates to the deployment descriptor’s source code, which you can verify by switching to the XML tab. This is demonstrated in the following steps.

Note: You may need to add carriage returns to the code so that it displays on multiple lines. You can right-click in the editor and choose Format (Alt-Shift-F; Ctrl-Shift-F on Mac) to have the code properly indented.

The above directive specifies that for all files found within the given url-pattern`s, the `header.jspf file will be prepended, and the footer.jspf file appended.

To view the definitions of the above tags, as well as all tags available to you in the web deployment descriptor, consult the Servlet Specification.

You will see that the welcome page displays as it did previously, with header and footer content included.

The controller servlet handles incoming requests by initiating any actions needed to generate the model for the request, then forwarding the request to the appropriate view. For a visual representation, refer back to the MVC diagram for the AffableBean project.

The IDE provides a Servlet wizard that enables you to define the servlet component in a web application either by including the @WebServlet annotation in the generated class, or by adding the necessary directives to the deployment descriptor. In the following steps, you create the ControllerServlet and define it in the application context using the `@WebServlet` annotation.

The URL patterns should correspond to the views and actions that a user can initiate. Looking at the welcome page mockup, a user should be able to select a category. We can therefore associate the /category URL with the action of clicking on a category image. Likewise, in the category page, users should be able to add an item to the shopping cart. We can therefore specify /addToCart.

In the previous step, if you had chosen the ‘Add information to deployment descriptor (web.xml)’ option in the wizard, the following markup would have been generated in the application’s web.xml file instead.

As previously stated, the controller servlet handles incoming requests by initiating any actions needed to generate the model for the request, then forwarding the request to the appropriate view. For a visual representation, refer back to the MVC diagram for the AffableBean project.

Looking at the generated code for the new ControllerServlet, you can see that the IDE’s servlet template employs a processRequest method which is called by both doGet and doPost methods. (You may need to expand the code fold by clicking the plus icon ( ) in the editor’s left margin to view these methods.) Because this application differentiates between doGet and doPost, you’ll add code directly to these methods and remove the processRequest method altogether.