In server-side control architectures such as Java ServerFaces (JSF) or Struts, a majority of the control events must be handled on the server side to update the state of the control. For every user event, the entire page data is sent back to the server as part of the form submission. Even data that has not changed or is not affected by the user event is sent to (and back from) the server. It is obvious that handhelds, overburdened Web servers, and possibly wireless networks would benefit from the avoidance of redundant data processing in these instances; the question is how to implement a solution.
The problem for the developer distributing a server-side control component is that he or she does not know the kind of environment the component will be used in. The component might run on a page that contains a lot of other components; on a page that exists within deeply nested frames; or as part of a composite control component, such as a drop-down list and text box. While every environment poses its own particular challenges, the composite control component is a particularly strong candidate for data-processing redundancy. It is possible that the majority of internal events generated by one of the composite controls results in an update of the other controls within the portlet.
In this article, I'll consider a conceptual solution for the problem of data-processing redundancy in a composite control component.
For a working example, consider a much simplified portlet consisting of a drop-down list and a text box. The text box is updated based on the selection in the drop-down list. In a sever-side event model such as MVC (Model View Controller), all of the control data is sent to the server every time a user makes a selection in the drop-down list. Keep in mind that the user selection is an event internal to the portlet. If the component is contained on a page with other controls, however, the entire page is sent back and forth to the server for every event affecting only the two controls in the portlet.
It seems obvious that you should be able to simply refresh the single component instead of the whole page -- but how to do it?
<activeContainers> to the rescue
One possible solution to the problem would be to designate certain areas of the Web page as separate containers. In the case of an event, only the container would be refreshed without affecting the other containers or supercontainers on the page.
For the purpose of this article, I call these containers
<activeContainers>. The first point of concern in
implementing the described solution is how to differentiate
between events that refresh only within the confines of the <activeContainer> and those that require a whole page refresh. For example, while one link in the drop-down list might lead only to the text box, requiring an update of just the container state, another might navigate to a new Web page altogether, which requires a whole page submission or refresh.
Using attributes to designate type
To differentiate between the two types of event, you must designate the events that result only in an update of the container state. For this, you might use an attribute specifying either an internal or an external event, as shown below.
<a href='/doUpdate' type='internal'/> |
For an input component with its type declared as internal, the browser would know to refresh only the
<activeContainer> and not the entire page data.
In Figure 1, below, you see a slightly more advanced working example, with two <activeContainer>s within one Web page. It should be possible to submit the data of one
<activeContainer> rather than the whole page,
including the second <activeContainer>. For this, a browser needs to treat the data within an <activeContainer> tag in a special manner. For example, a browser might use a separate user-interface Panel to draw the components in a given <activeContainer>. In this case, only the Panel that drew the components within the <activeContainer> tags is refreshed.
Figure 1. A more advanced activeContainers solution
In this example, a variation on selective refresh, the user still experiences the page as a whole; only the browser knows to differentiate one <activeContainer> from another.
In another advanced implementation of the
<activeContainer>s solution, a container could
specify dependents -- that is, other <activeContainers> to be refreshed whenever the main <activeContainer> is refreshed.
The <activeContainer>s solution isn't the only
possibility for resolving data-processing redundancy in server-side architectures. IFrame is another possible solution that comes to mind. Unlike <activeContainer>s, however, an IFrame implementation requires previous planning and design, making it not so distributable. In addition, IFrame requires that data be stored in a separate document, creating a dependency on that separate document.
In fact, an <activeContainer> can be considered a way of generating IFrames or Frames on the fly. Unlike IFrames or Frames content, however, an <activeContainer> is still a part of the main page; it is simply a dynamic way to inform the browser of the existence of self-contained data.
The purpose of an <activeContainer> is to isolate (scope) refreshable data for improved performance. Like Frames and IFrames, the <activeContainer> solution is dependent on browser support. A browser must be aware of the
<activeContainer> tag and render or refresh tagged data in a special manner based on their internal events.
While currently only a conceptual solution,
<activeContainer>s are an idea that could make life much
easier for developers. For wireless networks it means less
redundant data on the network and less probability of bit errors, and, hence, less retransmission at the transport level. In the long run, the <activeContainer>s solution has the potential to contribute to a longer battery life for handhelds. The bottom line is less work for overburdened servers on any type of network.
- The new IFrame API has many other exciting applications in addition to its next-best solution for the problem posed in this article. Find out all about this spankin' new application window architecture, with Michael Abernethy's "Go state-of-the-art with iFrame" (developerWorks, March 2004).
- Learn more about state-of-the-art control architecture implementations, with Malcolm Davis' forward-thinking "Struts, an open-source MVC implementation" (developerWorks, February 2002).
- Discover how to integrate the features of three leading server-side UI technologies in "Integrating Struts, Tiles, and JavaServer Faces" by Srikanth Shenoy and Nithin Mallya (developerWorks, September 2003).
- Get a little closer to the heart of the matter, with a look at the challenge of displaying Web information on mobile devices in Anne Zieger's "Microbrowser architectures" (developerWorks, August 2001).
- Want to learn more about Java ServerFaces? Download the JSF component catalog from the
developerWorks Web Architectures zone!
- Visit developerWorks Web Architecture zone for articles covering varous Web-based solutions.
- Browse for books on these and other technical topics.
- Also, for a complete listing of free tutorials that focus on Web and wireless topics, see the Web architecture zone tutorials page and the Wireless zone tutorials page from developerWorks.
Aashish completes his MS in Computer Science (Computer Networks) from the University of Southern California (USC) this Fall. You can contact him at aashishpatil@acm.org.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
