Written by Vaughn Vernon
Solution Pattern
Dynamic Web Page
Allows data to by served dynamically from a server-based Web application to consumers as a whole view or as a view fragment.
Background
A consumer requests a named resource from a Web site in order to receive a view of pertinent live data. The business Web site must reply to the request with a well-formatted response that contains the data the consumer expects to see. The developers use best practices since it will reduce complexity and promote reuse and maintainability, thereby lowering time to deployment and cost of ownership.
Value and Benefits
Dynamic Web pages are an invaluable business asset. They are matchless in their ability to deliver business information with relative ease and in a timely manner.
Putting It to Work
When a user resource request reaches the Web server it is in the form of a URL. The URL contains a logical path and possibly other directives that specify how the Web server will fulfill the request. A basic request will have a URL that references a static Web resource such as an HTML document, graphic file, or other kind of file that can be served directly by the Web server. This is a basic URL:
http://www.somedomain.com/index.html
This URL requests a static HTML document resource, which is commonly called a Web page. Nested references inside the HTML document to graphics files are also in the form of URLs. As well as this works, there are no dynamic aspects to this request. If Web sites were limited to static content they would provide very limited value to enterprise businesses.
Custom Components
Web servers must, therefore, also handle requests for dynamic data. Using configuration or convention and a server-side framework we can instruct the Web server to interpret URL patterns as a command set that dispatched to framework managed components. Thus, even the above URL that seemingly references a static resource in the root of the web server's logical file system (index.html) could be interpreted by the server to dispatch to a component instead of responding with the contents of a physical file. Of course it could be considered poor design to do so. Hence, a server-side component framework will generally use a more deliberate form of URL encoding:
http://www.somedomain.com/dyna-container/dyna-service?param1=x
Again, using configuration or convention the text pattern /dyna-container/dyna-service is interpreted as a command set that tells the Web server to dispatch to the mapped request handler component. In this example dyna-container hypothetically represents a request processing engine, and dyna-service is a named logical custom component managed by the engine that handles the request.
Because some request processing engines manage custom components privately, including their deployment and runtime execution, they may be called containers. Containers will many times provide other custom facilities, and resource access mechanisms, as well as a standard API for the components to use. This pattern assumes the existence of a web component container.
The container further parses the request URL and determines which of its custom components to dispatch the request to (dyna-service). It may also find parameters on the URL, such as param1=x above. The request handler must factor the parameters into a format or data structure suitable as input to the target component. Finally the request is dispatched to the custom component along with parameters.
The custom component receives control (e.g. invoked) and performs its tasks. It may find and read data from one or more data sources, or delegate such responsibilities to one or more other components. The results of their processing is written to an output stream to form a response. The response output must be appropriately formatted for the requester. For a Web application that serves dynamic responses to a Web browser, this means formatting the response with an HTTP header followed by an HTML or XHTML (well-formed HTML that adheres to a standard XML document type definition or schema).
Components managed inside the Web component container may use an API to dispatch requests to collaborating components. Dispatching takes the form of redirecting and forwarding. Redirecting changes the URL, and requires that the response go back to the browser (or other request sender) and then back to the Web server to be processed. Forwarding does not require that the request make a round-trip to the browser and back. Rather, the work-in-progress response is directly dispatched to a collaborating component. This invoke-augment-dispatch processing may continue for as many times as is necessary to complete the appropriate response output.
Note the difference between redirecting and forwarding as illustrated in the next two diagrams:
Web Component A redirects request handling to Web Component B. This requires the URL redirection to make a round-trip to the Browser and back to the Web Component Container before Web Component B receives the request. Essentially Web Component A forces the Browser to make an entirely new request to the Web Server and tells the Browser what URL to request.
Here Web Component A forwards the request handling to Web Component B. The major difference here is that the Web Component Container simply re-dispatches the request to Web Component B directly. No Browser round-trip is necessary. While this is a more optimal approach, the Browser’s address text box will contain the URL of the original request to Web Component A, rather than Web Component B. But an identical request to Web Component A may result in an identical or near-identical response in the future; that is, as long as the component logic and backing data driving the request remain unchanged.
It is not within the scope of this pattern to define the use of components that reside outside the Web component container. But suffice it to say that this may be managed using the native API of the consumed component container (such as COM or EJB).
Template Pages and Scriptlets
In all of the above cases one or more custom component must generate the response output that gets served back to the requester. While that does fulfill the definition of a Dynamic Web Page, it is certainly not the most convenient to use. If you want to alter the presentation of the response, you must modify and redeploy the custom component, which is likely implemented in some sort of modern programming language. The output itself is difficult to produce because any HTML or XML output produced must be formatted by the component as output to the file stream. It’s much more convenient to use an HTML or XML editor to create the page layout and then merge in runtime data on the fly as needed.
So another important aspect of the Dynamic Web Page is the use of template pages interspersed with programming logic hosted by a scripting syntax to produce the live data. The URL that requests a template page is generally different from those used to request custom components. In fact a template page is generally requested in much the same way that static HTML pages are requested:
http://www.somedomain.com/page.type
The filename suffix is important to the Web server’s ability to interpret and dispatch the template page request. In the same fashion that a Web server can interpret a URL that identifies the use of a custom component, the server can interpret a URL that identifies a template page. In many cases the .type filename suffix is used to instruct the Web server to direct the request to the template page’s request handler.
Here is what the markup in a template page might look like:
<html>
<head>
<title>Acme, Inc.</title>
</head>
<body>
. . .
<table>
<tr>
<td>Info 1</td>
<td><%= info1.getInfo() %></td>
</tr>
<tr>
<td>Info 2</td>
<td><%= info2.getInfo() %></td>
</tr>
</table>
</body>
</html>
Without getting too deep into the meaning of the embedded scripting language (yet), note how concerns are divided. The HTML markup and standard presentation text is provided as natural, static HTML. Dynamic, live data, on the other hand, is brought into the page by executing the logic in the scriptlets. The scriptlet is the programming logic surrounded by the <%= and %> directives. So your page design, including graphics and layout, can be performed using an HTML editor (textual or WYSIWYG), and programming logic can be inserted later (or the other way around, depending on how your development is planned).
Depending on the framework that you use, the template pages may be generated as first-class custom components that are native to the Web component container, or they may be interpreted at runtime. If they are generated into native custom components, expect better performance than those that are interpreted.
A container that turns a template page into a native custom component will compare the date and time stamp of the template page file with that of its corresponding generated custom component, if the generated component exists yet at all. If the template page is newer than the generated component, or if no corresponding generated component exists, then one is generated. From that point forward the generated component is executed in place of requests for the template page.
Custom Tag Libraries
A third important aspect of the Dynamic Web Page is the ability to extend or augment the tag-based markup language used by the template page. Basically the Web component container allows developers to define their own set of tags, housing them in a set of custom tag libraries. A class or other programming implementation mechanism backs the custom tags. The programming logic in the mechanism is executed at runtime when the page is requested and logical location of the tag is reached. The tags are used in place of most of the scriptlets, although scriptlets may be necessary to provide runtime information to the custom tags, as can be seen here:
<html>
<head>
<title>Acme, Inc.</title>
</head>
<body>
. . .
<table>
<tr>
<td>Info 1</td>
<td><info:show-info id=”<%= info1.getId() %>”></td>
</tr>
<tr>
<td>Info 2</td>
<td><info:show-info id=”<%= info2.getId() %>”></td>
</tr>
</table>
</body>
</html>
The tags may provide the ability to use namespaces, such as can be seen above where info is the namespace and show-info is the name of the custom tag. The tag’s id attribute is used to locate the actual information being displayed live. Here a scriptlet is used to get the identification of the specific “info” object to display. In essence the Web component container, when generating a representative native custom control, reads the custom tags and replaces the tag with an invocation of the programming logic provided by the backing implementation mechanism. By using a combination of custom components, template pages with scriptlets, and custom tag libraries, we have a good foundation on which to build out an enterprise-strength Dynamic Web Site.
Some Web frameworks now support expression languages, which altogether replace the need for scriptlets. In the above example, the scriptlet code would be replaced by expression language statements, such as the following:
...
<tr>
<td>Info 1</td>
<td><info:show-info id=”${info1.id}”></td>
</tr>
...
In this example the expression ${info1.id} is functionally equivalent to <%= info1.getId()%> but is a preferred approach since it is at least one level removed from programming in the application implementation language.
Page Fragments
When using the AJAX and COMET patterns it is essential to support page fragments. Consider a page that is divided into several logical regions, each containing a specific kind of data. For example, an invoicing application would have an region to select or enter new line items, customer region including ship-to and bill-to addresses, a summary of line items in a details region, and a region that contains the grand total of the invoice.
With that in mind, think of what you want to see when you enter a new line item. You want the new line item to appear in the details region, and you want a new totals region with a subtotal, applicable taxes, shipping changes, and grand total to appear in the totals region. Of course there is considerable activity on the server to manage creating the new line item and calculating new totals, and then delivering the newly create data back to the client. Nonetheless, you don't want your entire client view to redisplay regardless of how much server activity occurred. You just want the new data to show up suddenly in the proper regions. Page fragments support this desired capability.
The regions on your invoicing client view can be thought of as fragments; one fragment for each region. The dynamic region updating is accomplished when the client-side AJAX implementation detects an available update to a specific region (fragment) and it replaces the existing fragment with the newly available fragment. Of course you have to give careful consideration to the regions that you want to completely replace and those that you simply want to update. For example, you don't want to deliver all invoice line items and replace the entire details fragment each time you enter a new line item. You really just want to insert the new line item into the details grid control. But for the totals fragment it makes sense to do a complete replacement since the subtotal, taxes, shipping, and grand total are all impacted by the single line item change.
To support page fragments and dynamic fragment replacement, the source Dynamic Web Page (whole view) must be divided into the logical region fragments. Further, corresponding AJAX (with or without COMET ) responses must be fragments. You may use a tiling component (such as Apache Tiles) to achieve the fragmented page regions as page layouts.
Regardless of the use of a tiling framework or not, the rich client side code must be able to find the page fragment and replace it. One convenient way to do this is to surround each fragment that can be replaced with a uniquely identified HTML div element:
<div id=”invoice_totals”>
. . .
</div>
The client-side code, after receiving updated data for the invoice_totals fragment, finds the div element in the browser document (DOM) and replaces its contents. The following client-side JavaScript would accomplish the fragment replacement:
var updatedInvoiceTotalsFragment = . . . // AJAX results
. . .
var invoiceTotalsElem = document.getElementById(“invoice_totals”);
invoiceTotalsElem.innerHTML = updatedInvoiceTotalsFragment;
As desired, the new totals region of the invoicing client is updated with the totals fragment instantly.
Implementations and Examples
A somewhat antiquated means of supporting dynamic page generation is called cgi-bin. CGI stands for Common Gateway Interface, which represents a standard way to access live data via a Web request. The bin part of cgi-bin stands for binary, and is representative of the Unix environment where executable files are located. Recall that the /bin and /usr/bin directories, for example, are traditional locations where executable program files reside on a Unix system. So cgi-bin is the directory in which executable programs and utilities reside that allow a Web site to produce dynamic pages upon request. When the Web URL contains the text /cgi-bin/executable-file, the Web server knows to run the specific executable-file that follows the /cgi-bin/ directory reference.
There are many issues with using traditional cgi-bin. It is usually slow because an executable file must be loaded and run each time a cgi-bin request is made. Loading an executable file on most operating systems is one of the most expensive system-level services that can be employed. Also each request may require loading its own dedicated executable, putting even greater load on the system.
There are other issues, such as those concerning caching and security that I will not describe here (as they are generally well known). Because of the various issues around cgi-bin, its use today is rare. Other technologies such a Java Servlets, JavaServer Pages (JSP), Active Server Pages (ASP and ASP.NET), PHP, and others have largely replaced the use of cgi-bin.
The basic idea behind more modern solutions to the dynamic Web page problem domain is the use of a scripting language inside static pages. When the consumer requests a page containing a scriptlet, its logic is executed. The scriptlet logic produces dynamic data that gets inserted into key areas of the output stream. The end result is that the page response contains a snapshot of live data at the time of the request. The scripting helps to separate programming logic from presentation. Here’s an example using JSP:
<tr>
<td>Wholesale Price:</td> <td><%= productDataChannel.getWholesalePrice() %></td>
</tr>
<tr>
<td>Retail Price:</td> <td><%= productDataChannel.getRetailPrice() %></td>
</tr>
This is a portion of a JSP, which is essentially an HTML document with embedded Java. This example shows a portion of an HTML table definition. The definition of two table rows is shown (surrounded by <tr></tr> tags), and each row has two columns (surrounded by <td></td> tags). The first row contains the wholesale price of a particular product, and the second row contains the same product’s retail price. The first column of each row is the description text in plain HTML. The second column is filled with live data, using the following scriptlet notation:
<%= object.method () %>
This particular JSP syntax (<%=expression %>) directs that the String results of the expression should be inserted into the page at the given location. The object in both example expressions is productDataChannel. The method binding of the first expression is getWholesalePrice(), and that of the second expression is getRetailPrice().
Well, this is very useful. But unless other advantages are realized the improvements over using cgi-bin may be somewhat marginal. For example, what about addressing performance concerns, data formatting, and design best practices?
Another advantage of using ASP.NET, JSP, and the like, is that pages are pre-compiled into native components, and therefore optimized (not so with original ASP). When the scripted page is requested the generated, pre-compiled native component is executed, which means that live data is accessed at the speed of the underlying implementation language. Depending on the selected technology, the speed is determined by compiled C# or VisualBasic, or by Java and its virtual machine, for example. In the case of JSP, the page definition is compiled into a Java Servlet class. This is accomplished by virtually inverting the JSP page. The scripting logic becomes the body of the servlet’s doService() method, while the text of the HTML portion of the page becomes the core of the servlet’s output to the response stream.
Many dynamic Web containers, such as a Java Servlet container, typically load only one instance of the scripted executable. This reduces memory and load-time overhead by reusing a single copy of the Java Servlet, which is actually an executable class object. However, to keep the servlet reusable by any number of simultaneous requests the servlet instance must contain no volatile instance state.
When ASP, JSP, and Java Servlets were first used, some problems were encountered because core business logic tended to creep into presentation logic (an even by design!). Efforts have been made to reduce this problem. Some of the solutions have simply been provide through education, such as with patterns. Other solutions have come in the form of technologies, such as tag libraries and frameworks.
Tag libraries allow software developers to create their own custom tags that can be inserted into pages. This is done much like inserting standard HTML tags. Using JSP tag libraries, page developers must import the tag library into the page so it can be referenced. Next the tag must be used:
<%@ taglib uri="netui-tags-html.tld" prefix="netui"%>
. . .
<netui:button value="Sign On" type="submit" style="font-family:verdana;font-size:7pt;"/>
The above example uses the custom tag library provided by BEA and its WebLogic platform. This example deals specifically with HTML syntax such as forms and their input fields. Here an HTML button is defined. The face of the button will have the text “Sign On,” and if clicked will cause the form to be submitted to the Web site. Rather than using the scripting method to produce product-pricing information, as follows:
<tr>
<td>Wholesale Price:</td> <td><%= productDataChannel.getWholesalePrice() %></td>
</tr>
What if you use a custom tag library instead?
<%@ taglib uri="channel-product-tags.tld" prefix="channel"%>
. . .
<tr>
<td>
<channel:product-wholesale-price-title/>
</td>
<td>
<channel:product-wholesale-price
style=”font-family:verdana;font-size:7pt;”
format=”$999,999.99”
product-id="<%= product.getId() %>”/>
</td>
</tr>
Note in the above tag (<channel:product-wholesale-price/>) that display formatting is supported, whereas in the scriptlet implementation it was not considered. Of course formatting could have been supported in the scriptlet example, but it would have been more complex to accomplish. The strength of the custom tag approach is that you can easily manage both data access and presentation concerns in a page-centric manner, removing both from page layout concerns. The JSP custom tags are implemented using Java classes. Thus, the implementations of both access and formatting may be changed without impacting the pages themselves.
You also have the versatility to change the tag parameters. For example, instead of hard coding the style and format attributes, you may decide to use symbolic names:
<td>
<channel:product-wholesale-price
style=”Std_Style”
format=”Locale_Currency”
product-id="<%= product.getId() %>”/>
</td>
Now you simply leave it to dynamically executed presentation logic to map the actual display styles and formats used. In the previous example the Std_Style may be changed by the business whenever appropriate, or even mapped to a user preference. Further, the Locale_Currency parameter allows the business to present prices according to the locale of the consumer, making your Dynamic Web Site dynamically internationalized. Presentation and business logic is not only separated, but a more powerful presentation engine can be facilitated more easily as well.
Consequences
You will find tradeoffs among the following competing forces within the Dynamic Web Page solution pattern.
-
Separation of Concerns and Programming Power: An indispensable advantage of having a strong backing technology for Web development is the power it provides. When you can separate page design and layout from dynamic data access and formatting, your site will be more maintainable. When your selected technology allows you to embed dynamic data access into the page, you have the power to provide the kinds of solutions needed by consumers.
-
Natural Page Development: The closer you can get to a fully tag-based page implementation to more responsibility that can be delegated to less technical developers. It will “feel” natural to developers who are already strong in HTML skills.
-
Ease of Use Versus Underlying Complexity: The easier that you make development of pages, the more complexity that resides below the surface. Providing a set of custom tab libraries puts more power into the hands of less technical developers (see Natural Page Development above). However, designing a complete and highly reusable set of dynamically functioning tags will cost your technical development staff in terms of complexity and, therefore, effort.
Related Patterns
See the other solution patterns within the Dynamic Web Site EBP. Since most or all of the patterns in this catalog may be implemented as Web-based solutions, this pattern is a foundation to the entire catalog. In addition, the following patterns make use of the Dynamic Web Page solution pattern.
Frameworks and Tools