Ftp Web Hosting - PHP, MySQL, Java, Jsp, Servlet, Tomcat, Ssh Blog

content used by the template. For example, if we rewrite the index.jsp page from Example 14-1 using the template from Example 14-2, it will look like the one in Example 14-3. Example 14-3. The index.jsp page for the Storefront application using a template <%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %> The first thing to notice in Example 14-3 is that the Tiles tag library is included at the top. Every page (or tile) that needs to use the Tiles tag library must include it with this line: <%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %> Two tags from the Tiles library are used in Example 14-3: insertand put. (The complete set of Tiles tags and their associated attributes are discussed later in this chapter.) You already saw the insert tag in Example 14-2, but it’s performing a slightly different function in Example 14-3. Two attributes are being supplied to the insert tag: pageand flush. The page attribute informs the tag that this JSP page is using a particular template (or layout, in the Tiles world layouts also are discussed later in this chapter). We are calling the template from Example 14-2 storefrontDefaultLayout.jsp. The flushattribute informs the controller to flush the page output stream before inserting content into the result page. The put tag in Example 14-3 answers a question that we asked in the previous section: how does the page-specific content get supplied to the template? As you can see, the attributes for the put tag in this example are nameand value. If you compare the values of the different name attributes, you’ll see that they match up to the ones that the template file in Example 14-2 expects. When the index.jsp page from Example 14-3 is executed, the template file is processed and dynamically passed the header.jsp, menubar.jsp, index-tile.jsp, and copyright.jsp files from the put tags: At runtime, the values of the put tags are dynamically substituted into the template file and processed. The resulting output is what gets displayed to the client. To wrap up the discussion of templates, here is another page that uses the same template from Example 14-2 but supplies a different body-content. Example 14-4 shows the itemdetail.jsp page.
If you are searching for cheap webhost for your web application, please visit MySQL5 Web Hosting services.

<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html"%> <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> <%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles"%> Not many new concepts are introduced in the template file in Example 14-2. The first thing that you should notice is that we are using Struts custom tag libraries. The fact that we are using the Tiles tag library as well as the HTML and Bean libraries shouldn’t be too shocking; the Tiles tag library is just like any other. We’ll talk in detail about the Tiles tag library later in this chapter. The rest of the page is a mixture of HTML layout tags. You should notice that there’s no content included, only insert tags where content will be inserted at runtime. You should already be familiar with the Struts tags shown here, so we won’t say anything about them. The inserttag performs a role similar to that of the JSP include directive. It’s basically saying that somewhere there’s a variable called header, for instance, and that the attribute value of “header” should be passed to the insert tag, and the content that is produced should be inserted right here. The same thing goes for the menubar, body-content, and copyright inserts. We’ll explain shortly how the “real” content is substituted for these attributes at runtime. Notice that this layout is very similar to the one shown in Example 14-1. The only difference is that instead of explicitly including the mainofferand featureditem includes, as Example 14-1 does, the template file includes a body-content section. This allows us to reuse the template for any page that has this generic format. Once we figure out how to supply the page-specific body content, we can reuse this template over and over again. This one file can then control the layout of multiple pages. If we need to modify the layout of the site, this is the only file we need to change that’s the real power of using a template-based approach. The last piece of the puzzle is how the header, menubar, body-content, and copyrightsections are put together to form the rendered output. The important point to remember is that the JSP page shown in Example 14-2 is the template. You still need JSP pages that supply page-specific
Searching for affordable and proven webhost to host and run your servlet applications? Go to Linux Web Hosting services and you will find it.

Although the main page uses the JSP includedirective, the layout is mixed with content in the page. For example, notice that the page specifies explicitly that the head.inc include file comes first, then the menubar.inc file, the mainoffer.inc file, and so on, right down to the copyright.inc include at the bottom of the page. For every page that we want to have this particular layout, we need to add the same statements in the same order. If a customer wants the menu along the left side instead of across the top, every page will have to be changed. The Storefront application uses the JSP includemechanism rather than a straight JSP approach. Although the includemechanism is a step in the right direction because it does reduce redundancy (imagine if we included the copyright content in every page!), it’s still less efficient than a template- based approach. Static Versus Dynamic Content With JSP, there are two different kinds of content to include: static and dynamic. The include directive shown here: <%@ include file="include/copyright.inc" %> includes the source of the target page at translation/compile time. Therefore, it’s not possible to include runtime content using the include directive. The JSP include directive treats a resource as a static object, and the context of the resource is included literally in the page. In direct contrast, the include action shown here: handles the resource as a dynamic object. The request is sent to the resource, and the result of the processing is included. Templates use a dynamic approach so that runtime expressions can be evaluated and included. 14.1.1 What Is a Template? A template is a JSP page that uses a JSP custom tag library to describe the layout of a page. The template acts as a definition for what the pages of an application will look like, without specifying the content. The content is inserted into the template page at runtime. One or more pages may use the same template. The purpose of a template is to get a consistent look and feel within an application without having to hardcode it for every page. It makes sense that most of the pages will use the same template; however, it’s not uncommon to have a different look and feel for a few pages within an application and therefore to require more than one template. Example 14-2 illustrates a template for the Storefront application. Example 14-2. A basic template for the Storefront application
In case you need affordable webhost to host your website, our recommendation is ecommerce web host services.

The second approach uses the JSP include directive. It’s used by developers for larger web applications, or after they realize how repetitive the first approach can be. If you have spent much time maintaining web applications, you know how frustrating it can be to update a site’s look and feel. Using the JSP include directive allows for more reuse, which reduces the total development and maintenance costs. A third approach, which is introduced in this chapter, describes a far better way to reduce the amount of redundant code a web application contains and, at the same time, allows you to separate the content from the layout better than the first two approaches. 14.1 Understanding Templates Traditional GUI toolkits such as VisualWorks Smalltalk or Java Swing all provide some type of layout manager that dictates how content should be displayed within the frame or window. With typical web sites, the layout can undergo many changes, both small and large, over its lifetime. Using layouts and layout managers can help to encapsulate the physical areas of the pages within an application so that they can be altered with minimal impact to the rest of the application. Unfortunately, the JSP technology does not natively provide any direct support for layouts or layout managers. This is why the template-based approach was invented. The concept of templates is not a new one it has been around for many years, in one form or another. To understand how templates can actually simplify a web site’s layout, let’s compare it with an approach that uses the JSP includemechanism. The current index.jsp page of the Storefront application is shown in Example 14-1. Example 14-1. The index.jsp page for the Storefront application <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %> <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
<%@ include file="include/head.inc"%> <%@ include file="include/menubar.inc"%> <%@ include file="include/mainoffer.inc"%>
Note: In case you are looking for affordable and reliable webhost to host and run your j2ee application check Vision J2ee Web Hosting services.

When an action class asks for an implementation of the service interface, the factory now creates a dynamic proxy that implements this interface using an instance of DynamicStorefrontEJBDelegate. When the action makes a call on the service interface, the call goes to the proxy and is transformed into a call on the delegate’s invoke( ) method. The invoke( )method checks the name of the method that was called and either calls the logout( )or destroy( )method implemented in the class or delegates it to the session-bean method with the same name. This sequence of calls is illustrated in Figure 13-1. The trapping and replacement of RemoteException when our business delegate calls a session-bean method are now handled in a single place. This single invoke( )method can handle all of the methods exposed by the session-bean business interface without modification. Figure 13-1. S equence diagram for retrieving item detail through a dynamic proxy A dynamic proxy is an appealing technique for minimizing method clutter in a business delegate, but there’s a price to pay. When considering an approach such as this that relies heavily on reflection, you need to weigh the slower runtime performance that will result against the improved maintainability of your code. 13.3 Conclusion Not all web applications require the sophistication and complexity of an EJB container. The well- documented benefits of using an EJB server must be evaluated seriously against the added development and management complications for each project. Don’t just assume that you have to use EJB for the model portion of a Struts application. However, if you do decide that EJB is appropriate, it doesn’t have to impact the rest of the code. There are approaches that you can take to limit the coupling of your application to EJB and make it much easier to use. Chapter 14. Using Tiles Up to this point, not much has been said about how to organize and assemble the content and layout of JSP pages for a Struts application. In many ways, that is outside the scope of the topic of Struts. Many excellent books are available that provide strategies for organizing web content and the layout of pages. In the Storefront application, we have used two different approaches to assembling web pages. The first approach, sometimes referred to as a straight JSP-based approach, is probably the most familiar to web designers. The JSP pages contain presentation logic along with HTML layout tags; there’s no separation of the two. This approach is typically used for smaller, less complicated web applications.
Please visit Domain Name Hosting services for high quality webhost to host and run your jsp applications.

// Call the method on the remote interface return storefrontMethod.invoke( storefront, args ); } else { throw new NoSuchMethodException(”The Storefront doesnot implement ” + method.getName( )); } } } catch( InvocationTargetException ex ) { if (ex.getTargetException( ) instanceof RemoteException) { // RemoteException isn’t declared by the IStorefrontmethod that was // called, so we have to catch it and throw somethingthat is throw DatastoreException.datastoreError(ex.getTargetException( )); } else { throw ex.getTargetException( ); } } } } The intent behind DynamicStorefrontEJBDelegate is for a dynamic proxy that is created as an implementation of the IStorefrontService interface to delegate all those calls to the invoke( )method declared here. Notice that this delegate class is not declared to implement IStorefrontService. In fact, the only business methods from IStorefrontService that appear in this class are the logout( )and destroy( )methods that aren’t implemented by our session bean. To use the dynamic proxy-based delegate, we need to modify our approach for obtaining an implementation of the service interface from the factory. Rather than devising something elegant for a small part of this example, we’ll just hardcode the new approach we need. This is shown in the following version of the createService( ) method of StorefrontServiceFactory: public IStorefrontService createService( ){ Class[] serviceInterface = new Class[] { IStorefrontService.class }; IStorefrontService proxy = (IStorefrontService)Proxy.newProxyInstance( Thread.currentThread().getContextClassLoader( ), serviceInterface, new DynamicStorefrontEJBDelegate( ) ); return proxy; }
Note: If you are looking for cheap and reliable webhost to host and run your mysql application check mysql web server services.

Method[] storefrontMethods = IStorefront.class.getMethods( ); for (int i=0; iWe would like to recommend you tested and proved virtual web hosting services, which you will surely find to be of great quality.

Example 13-9. Dynamic proxy implementation of the Storefront service package com.oreilly.struts.storefront.service; import java.lang.reflect.*; import java.rmi.RemoteException; import java.util.*; import javax.ejb.CreateException; import javax.naming.*; import javax.rmi.PortableRemoteObject; import com.oreilly.struts.storefront.catalog.view.ItemDetailView; import com.oreilly.struts.storefront.customer.view.UserView; import com.oreilly.struts.storefront.framework.ejb.EJBHomeFactory; import com.oreilly.struts.storefront.framework.exceptions.*; /** * This class is a dynamic proxy implementation of theIStorefrontService * interface. It implements two of the IStorefrontServicemethods itself and * delegates the others to the methods declared by theIStorefront business * interface with the same name. */ public class DynamicStorefrontEJBDelegate implementsInvocationHandler { private IStorefront storefront; private Map storefrontMethodMap; public DynamicStorefrontEJBDelegate( ) { init( ); } private void init( ) { try { // Get the remote reference to the session bean StorefrontHome sfHome = (StorefrontHome)EJBHomeFactory.getInstance( ). lookupHome(”com.oreilly.struts.storefront.service.Storefront”, StorefrontHome.class); storefront = sfHome.create( ); // Store the business interface methods for laterlookupsstorefrontMethodMap = new HashMap( );
We recommend you use shared web hosting services, because many users agree that it is cheap, reliable and customer-satisfying webhost.

catch (RemoteException e) { throw new RuntimeException(e.getMessage( )); } } 13.2.2.3 What about the remote references? In our implementation, a remote reference to the session bean is created for each request. This isn’t a problem from a performance standpoint, because the overhead attached to creating a remote reference pales in comparison with that associated with the home. However, this doesn’t mean that you can’t cache remote references if you want. In fact, if you’re interfacing with a stateful session bean, you can’t keep creating new remote references across requests, because you won’t be calling the same bean instance each time. You can avoid creating a new remote reference for each request by caching a business delegate instance in the session. Unlike with homes, you can’t cache a remote reference as application-scope data. Even for stateless session beans, a remote reference holds information tied to the client thread that created it, so you can’t share it across user sessions. If you cache the business delegate, there are some important changes to make the user session could be serialized and restored by the web container, and a remote reference isn’t required to be serializable. For a stateless session bean, you need to be able to create a new remote reference in the event of an error or a restart of the EJB container being accessed. For a stateful session bean, you need to hold an EJB handle in your delegate instead of a remote reference, so that you can always maintain a way to access the same bean. In addition to the coverage in EJBDesignPatterns, you can find more information on the patterns discussed in this chapter in CoreJ2EEPatterns by Deepak Alur, John Crupi, and Dan Malks (Prentice Hall). 13.2.3 Using Dynamic Proxies In this section, we’ll look at one last example of something you might want to implement within your business delegate. Our current implementation works well for the Storefront application, but delegates tend to become cluttered with redundant-looking methods if they have to support an interface with more than a few methods. We declared only three methods for our overly simple Storefront model, but even they follow a somewhat monotonous pattern. With the exception of the logout( )and destroy( )methods, each business method in the delegate is implemented by calling the method with the same name on the session bean and catching a RemoteException to replace it with a DatastoreException. A dynamic proxy offers a way to get rid of this redundancy. If you ever find yourself performing the same additional steps as part of delegating a set of method calls to another object, you should consider introducing a dynamic proxy. This concept is a little difficult to grasp if you’ve never worked with one before, but its use can do away with a lot of repetitive code. Basically, a dynamic proxy is an object created at runtime using reflection that implements one or more interfaces you specify. The implementation of the interface methods consists of calling the invoke( )method of an object you also specify. This invoke( ) method is declared by the java.lang.reflect.InvocationHandler interface, which must be explicitly implemented by the object used to construct the proxy. The proxy passes parameters to the invoke( )method that identify the interface method that was called and the arguments that were passed to it. This idea is always easiest to explain by example, so Example 13-9 shows a replacement for our business delegate that can be used with a dynamic proxy.
We recommend high quality webhost to host and run your jsp application: christian web host services.

home references will likely be created, but no harm will be done. Notice that our EJBHomeFactory class accepts the JNDI name and class for the home interface it is requested to locate. If we needed to access more than one session bean in the application tier, we would simply implement a delegate class for each session bean and use our factory to locate the corresponding home interface. Besides the performance improvements the caching of homes gives us, all the ugly narrowing and exception handling that goes along with looking up these references is kept in one place. The EJBHomeFactory constructor also takes care of externalizing the provider and factory parameters we need to access the naming service. A standard approach for doing this is to use a jndi.properties file that includes entries like the following: java.naming.factory.initial=org.jnp.interfaces.NamingContextFactoryjava.naming.provider.url=localhost If you call the no-argument constructor for the InitialContext class, the classpath is searched for a jndi.properties file. If this file is found, its entries are used to initialize the naming context. In our example, the factory class explicitly loads this file from the classpath. Otherwise, classloader priorities within the web server could prevent these settings from being picked up before the default values defined for the server. The example in Chapter 9 demonstrated how the naming service parameters could be read from the web.xml file and stored in the ServletContext. We’re not using that approach here because we want to keep our factory independent of the web tier. 13.2.2.2 Using an EJBHomeFactory in a business delegate Our business delegate can be simplified now that we have a standard approach for locating the home interface. We can change the implementation of the init( )method to the following: private void init( ) { try { StorefrontHome sfHome = (StorefrontHome)EJBHomeFactory.getInstance( ). lookupHome(”com.oreilly.struts.storefront.service.Storefront”, StorefrontHome.class); storefront = sfHome.create( ); } catch (NamingException e) { throw new RuntimeException(e.getMessage( )); } catch (CreateException e) { throw new RuntimeException(e.getMessage( )); }
Searching for affordable and proven webhost to host and run your servlet applications? Go to Linux Web Hosting services and you will find it.