Structured Web Technologies

Structured Web Technologies

Results for:

segment

Prev Topic Next

One of the facilities provided by dynamic web platforms is the ability to divide pages into sections or segments. These segments could then be dynamically arranges, selectively shown or hidden, enabled or disabled. There are also the issue of re-use of segment; one copy used in many places. There is also some form of inheritance; adding to a base segment, or enhancements based on runtime parameters.

With AJAX comes the possibility of segments being targets for re-rending, partial refresh, etc.

All these activities are captured by the segment descriptor.

Page Segmentation

Segments could be of two flavors. 1) Component based: on some platforms all elements are part of component tree. As such, a segment, which is a component itself, would be a container component. On such platform, a segment could have identity or server side representation.

2) Character stream based: on such platforms, we are simply generating character streams, of HTML or xHTML syntax. For these we could arbitrarily demarcate the page any way desired, as long as the active tags used to render the page remain valid XML. When such demarcations are done, it is possible for the dynamically assembled page to become invalid HTML/xHTML.? For example, with starting <div> tag, and no ending </div> tag. This would be a concern during the demarcation exercise, but there are no restrictions that preclude this. This is less likely for component based architecture, because of the component hierarchy.

Segment Reuse

Apart from the breaking of page into segments, there is another issue of pages that are made up of other pages. This allows the reuse of common fragments by multiple pages. This feature could vary from simple inclusion of segments, to full templates whereby a common theme or page is defined, which part of it could be replace or customized in the composition of pages.

dWebSpec provides the scheme for capturing the reuse of segments as provided in the state of the art frameworks and template utilities. The full implications of this aspect could be realized from the descriptor attributes, also a full discussion on page reuse is provided in the Introduction and Guide.

As an overview, the following facilities are provided for. 1) The include facilities, which allows inclusion of fragments from other pages. 2) The template facilities, that allows the use of a template or master page in composing pages.

Seam

This

Basic JSF Features Expand

Page Segmentation

Example of segment entry is shown below.

SEGMENT DESCRIPTORS
id	type	visible	enable	valuue	base-page-id	extends	event-id	description
header	dynamic-include			{bakingBean. headSource}

Unlike character stream based platform that arbitrary demarcations could be placed on the page, the division of a page to segment is more streamlined on the component based platform.

The division of the page would be along the lines of panels, containers, includes, etc.l. This is a common concept behind components, and having components that are containers, that could contain one or more other components.

There is no restriction on mixing layout tags like table, row <tr> or cell <td> in demarcating a page. What is in question is the demarcation of page for the purpose of dynamic behavior applications.

dWebSpec defines some segment types. For these to be relevant for usage with JSF, for behavior application, they must have equivalent components. These correspondences are shown below. The last three segment types are called the include type; they are the subject of discussion of the next section.

dWebSpec segment	type	JSF
<table>	inline	h:gridPanel
<theader>	inline	f:facet name="header"
<tbody>	inline	The portion of the table between header and footer, and organized into rows of columns
<tfooter>	inline	f:facet name="footer"
<frame>	dynamic-include
<iframe>	dynamic-include
<div>	inline
<row>	inline
<td>	inline
<layer>	inline
aws - inline		h:groupPanel
aws - static-include	static-include	<@include file= ""/>
aws - dynamic-include	dynamic-include	<jsp:include page="included.html" /> <f:subview>
aws - insert-include	insert-include

From the table above, it could be seen that there are two main containers provided, namely PanelGroup and PanelGrid.

The other relevant segments are <theader>,<tbody> and <tfooter>. However, these are not really container components, they are called facets. By definition, a facet represents a named section within a container component. As such, although they could participate in segmentation, behaviors could not be applied to them; they actually have ?name? as the single property. Any of the defined facet, remember <tbody> is not explicitly defined, would accept a single component, and would need another container within, to hold multiple components.

For the purpose of behavior application, segments have the following attributes.

Segment Attribute	JSF Container Attribute
visible	rendered
enabled	There is no enabled equivalent. This must be recursively applied to the input elements within the container.

Segment Reuse

Segment reuse has two forms. 1) The master or template page that has segment defined within that could be overridden or replaced. Pages would use these templates and override them as appropriate. Any page could be a template, it is the segments of the ?insert? type that would delineate a segment as override-able. The insert type is defined in the segment descriptor, and it is within the page descriptor that a page could indicate what page it is using as a template.

2) Another means of re-use is to include dynamically or statically other pages. For specification of segment to include, dWebSpec provides two attributes a) the base-page-id that indicate the page the segment reside, and b) extends that carries the segment-id to include.

Standard JSF does not include segment re-use or templates; this has been one of the driving forces for the shift towards the use of Facelet, instead of the JSP used by the reference implementation. Facelet is comprehensive in its inclusion of such features; the dictionary provides information on this in the discussions for the Seam Platform.

Whatever facilities that are available for segment re-use, or segment of the include type, are available from the JSP/Servlet platform.

AJAX

All the segmentation and segment reuse discussed above, have to do with initial rendering or re-rendering on post-back, for the page. There is another type of re-rendering involving AJAX. This has gained popularity these days, in making web application appear highly interactive, on the level of desktop applications.

To mark a segment for re-rendering, all that is needed is to include an event-id entry for the segment. This id would belong to the AJAX event descriptor entry.

JSF does not come bundled with AJAX components; the Seam platform however does, for which discussion is explored for this subject.

More details are available in the attributes descriptions id type value event-id visible enabled base-page-id extends description

SEAM Enhancements

Seam provides 2 additional dynamic component equivalents to standard HTML based segments (div and span).

dWebSpec segment	type	Seam
<div>	inline	<s:div>
<span>	inline	<s:span>
aws - static-include	static-include	n/a
aws - dynamic-include	dynamic-include	<ui:include src="included.html" />
aws - insert-include	insert-include	<ui:insert >
<!--aws:segment visible="false"		<ui:remove>

There is no equivalent to static include; Facelet provides for dynamic include and insert. There is more discussion on this under the subject of segment types.

One last component provided is the <ui:remove>. Whenever some of the mock-up code end up in the implementation page, it is normal to surround the segment involved with the segment annotation with visible attribute equals false, as shown below

  <!-- aws:segment visible="false" -->
	Mock-up text that should not be included
  <!-- /aws:segment -->

There are reasons to explicitly disable such regions. For example, some of the contents could be interpretable as expressions. Facelet has the ui:remove tag that could surround this segment, which ensure that it could not participate in the dynamic assemble of the page.

  <ui:remove>
	Mock-up text that should not be included
  </ui:remove>