Experienced web developers, regardless of the language or environment, are used to writing a separate program for each web page. If you want to display five different dynamically generated pages, then you must write five different CGI programs, mod_perl handlers, servlets or JSP pages.
Enhydra allows developers to break away from this model, thinking in terms of applications rather than individual pages. The way to do this is with super servlets, as they are known, in which a single application object is associated with multiple presentation objects.
You can easily identify a presentation object in an Enhydra URL; the suffix .po tells Enhydra that it should invoke the object named in the URL. So requesting Abc.po will execute the run() method for the presentation object Abc. Unlike standard Java servlets, presentation objects are instantiated once for each HTTP request. This may be less efficient than using multiple threads on a single-servlet instance, but it does remove the headaches associated with writing threadsafe servlet code.
A simple Enhydra application will thus consist of at least one application object, plus at least one presentation object. These POs, as they are known, can then connect to the two other main types of Enhydra objects: business objects (which perform commonly needed functions) and data objects (which map persistent storage, such as a relational database, to a Java class). Each of these three types of objects—presentation, business and data—has its own directory within an application's src subdirectory, as we have already seen. Moreover, each of these objects constitutes one of the three standard tiers in a three-tier web application. So while it might take some time to get used to the separation between object types, this model is becoming increasingly prevalent in web applications.
Once again, we will use Enhydra's appwizard to create a skeleton application that we can change. Run appwizard again, but choose super servlet from the selection list on the first screen, rather than a simple web application. I chose to call the project myproject and to put it in the il.co.lerner package, which is what I use for internal projects at my company. appwizard then creates a skeleton application in ~/enhydraApps/myproject. The application has a similar structure to our servlet, with a similar directory structure. Under src/il/co/lerner, we have presentation, data and business directories. And once again, there is a top-level Makefile that will compile and create our super servlet.
Look at presentation/WelcomePresentation.java, the source code for the presentation object that will eventually be displayed. Indeed, if we type make at the top-level directory, run output/start4 to start our application and point our web browser to http://localhost:9000/, we will find that our browser is redirected to http://localhost:9000/WelcomePresentation.po. This page displays the same sample output that our skeleton servlet printed, with the Enhydra logo and the current time and date.
The po suffix, as we already know, tells Enhydra to invoke the run() method in WelcomePresentation. In the automatically created skeleton application, WelcomePresentation.run() looks like Listing 3.
The super servlet interface is similar to that of a regular servlet and does not take much time for a programmer familiar with servlets to learn. The run() method takes a single argument of type HttpPresentationComms, which provides our presentation object with all of its communication needs to the outside world, including the HTTP request and response objects.
The run() method displays output by creating an instance of WelcomeHTML, the Java class that XMLC created from the file Welcome.HTML. Following that, run() replaces the contents of the <span> tags with an ID of “time” with the current date and time. Then we write the contents of welcome, which contains a DOM tree, to the HTTP response object.
We can create our own presentation object, FooPresentation, as demonstrated in Listing 4. Remember to add the new object to the CLASSES line in the presentation directory's Makefile. When you rerun make from the top-level application directory, FooPresentation will be compiled and inserted into our Enhydra application.
It's very nice to be able to write our own presentation objects, but where is the application object that is controlling them? In the main source directory, at the same level as the presentation, data and business directories, there is a Java class file whose name is the same as the project—so in our case, there is a file at src/il/co/lerner/myproject.java.
Reuven M. Lerner, Linux Journal Senior Columnist, a longtime Web developer, consultant and trainer, is completing his PhD in learning sciences at Northwestern University.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Three More Lessons
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development