beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Tomlinson" <>
Subject RE: Complex page composition with netui
Date Mon, 16 Aug 2004 08:09:31 GMT
>> I see there are netui:template tags that attempt to offer 
>> page creation
>> from component page areas but it appears that the design takes a very
>> simplistic approach that is not appropriate for complex page
>Love to hear a set of features that you would like to add.

OK, you asked for it ;-)

When looking at page composition nearly all frameworks assume:

O  Simple single content area layout such as: header, left nav, main
content area; header, nav, content, footer.
O  Content is embedded into pages containing the template.

The first point is a major issue on sites where complex page design is
used.  Templates with 9 areas are not unusual e.g. head, top menu, left
nav, footer, 4 central content areas, right side panel.

The second point is the greatest design flaw and usually it extends from
an 'includes' mind set.  The biggest problem with that the template
becomes embedded in every page.  Marketing folk like to change site
style a lot and with hundreds of pages containing embedded templates it
equates to a lot of maintenance work.

Tiles was different in that it allowed the creation of a template then
allows a page to reference the template and nominate content to be
embedded.   This works really well but comes at the price of performance
with the number of RequestDispatcher invocations.  In tests, Tiles was
consuming the majority of Request processing CPU time and looked to be a
major bottleneck for large site performance.

So, an ideal solution would be something like the Tiles solution of
externally referenced template and content areas but without the

When you look at page compositions there's usually a pattern of a page
consisting of mainly static HTML with one or more JSP content areas.  In
quite a lot of cases of large sites that contain a lot of brochure ware
style pages, the vast majority of pages contain only static HTML.  Using
a composite framework gives good design flexibility and area reuse but
with static content it leads to pages being repeatedly composed on every
request when there is no need.

The frameworks take a script like and not a compiled approach to page
gen.  What I mean by this is that the user describes the page with tags
and they get executed every request.  To optimise the page serving it
would be better to process the page on the first request and optimise
the content for subsequent requests.  There is also the need to change
html and jsp's so that the changed files can be used without having to
restart the server.

A concept of conditional areas is something that's usually missed too.
We use the concept of having areas which are conditional, based on some
rules the content that's deposited into the area is applicable for the
type of user.  We've used conditional processing for templates as well
as content areas.  An 'email this page' link would use a simplified
template compared with the regular, likewise an 'Intranet' view would be
trimmed version of the regular template.

Conditional processing could be debated as it should be a content area
containing a JSP that performs the logic and imports the relevant piece
of content.  However, that's maybe missing the point and while making
the framework simpler it just moves the problem elsewhere.   A long
while back I created some tags that linked to our test condition
processing to tiles to try and accomplish this but in the long term
would have liked JSR-94 support rather than a proprietary

<idg:area name="template" test="view">
<idg:area name="TemplateLayoutBrandStrapBottom" test="customerCategory">

<tiles:insert definition='<%=
(String)pageContext.getAttribute("template") %>'>
	... etc ...
	<tiles:put name="TemplateLayoutBrandStrapBottom" value='<%=
(String)pageContext.getAttribute("TemplateLayoutBrandStrapBottom") %>'
	... etc ...

I don't see this a great solution; it worked but wasn't well integrated
and it was 'non standard'.

A last point to note is that of tools support.   We tend to take a far
too programmatic approach to these sort of frameworks without thinking
of providing visual tool support.   WLW is quite like other tools in
that it provides visual editing of pages no tool supports the editing of
multi area composite pages.   A framework should build UI editing
support from the start providing the hooks for other tool vendors and
ideally providing a sample editor to show the possibilities.   In our
custom framework we created the ability to show and hide edit buttons on
all of the content areas, allowing the user to navigate to a page and
then choose the area to edit.   It also allowed them to manually choose
any page, display then choose an area to edit.   This CMS type
functionality has a big buy-in.

>> And finally, any thoughts on creating a more sophisticated 
>> solution that uses caching and reduced the RequestDispatcher
>This actually has been requested a few times and is a possibility.
>Right now there is no concrete proposal for adding it.

Lets cover this off.  From a request point of view, the inbound page
request would be looked up in a cache and served from there if
appropriate.  If the cache entry has expired, the cache is flushed or is
non-existent the page creation would occur. So, based on my comments
above, a 'pre process' phase could be used to take the format the user
has specified and create a cache entry by importing a template and
embedding areas into it that are purely static.

Typing this has made me wonder if it would be possible to create a JSP
where the empty JSP has the template embedded into it, each of the
content areas are iterated and <%@include tags embedded to refer to all
of the content areas, the JSP is then executed as usual and it results
in a monolith JSP that performs no further RequestDispatcher
interaction.  This would work well for pages that have dynamic JSP
content areas but its pure speculation.  An alternative approach is use
another form of aggregating static areas and executing only the JSP bits
that are required.  Whatever the method, cutting down on the number of
RequestDispatcher invocations and file accesses will give big benefits.

I really want to pursue all these points so let me know how I can help
steer functionality in the right direction.


View raw message