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, 20 Sep 2004 07:44:07 GMT
Very interesting draft.   Looking at the spec, the decisions are based
on presentation items and the conditions are embedded in the mark-up.
The mark-up part of each condition is also embedded and, if I am not
mistaken, the spec assumes all mark-up is executed on the presentation
device, i.e. the browser.

My original thoughts on the implementation of conditional areas were to
have tests based on application model state.  Areas would reference
content for inclusion, rather than embedding directly, leading to
greater content reuse and reduced size of content sent to the browser.
We have used this approach with a proprietary framework for the last 4
years and it works very well.

I see the cselection spec. providing conditional processing in the
presentation layer on presentational items.  However, I also see another
mechanism, something along the lines of what I have mentioned
previously, in the application layer to process and compose pages of
more coarse grained elements, i.e. larger blocks of mark-up.

Concerning this area of interest and Beehive, I have seen nothing
further from my original thoughts and I am unsure of what the next steps
are to specify, design and introduce this new feature to Beehive.    Can
one of the BEA guys please comment????

Richard Tomlinson.

-----Original Message-----
From: Rotan Hanrahan [] 
Sent: 17 September 2004 17:24
To: Beehive Users
Subject: RE: Complex page composition with netui

Just responding to a snippit (attached below my response):

Please look at a recent W3C proposal in which I was involved. This
is attempting to address the notion of conditional content.
The editors (Rhys and Roland) will be delighted to receive valuable
comments from anyone likely to consider implementing this.

If Beehive is going to consider conditional content, then please
consider doing it in a standard way. Preferably along the lines of
DISelect (as per above link). This is not a tiles/layout solution,
but could become part of one. If anyone has comments on this W3C
proposal, the W3C-DIWG has a public mailing list for the purpose.
Alternatively, just say so here or email me directly and I'll convey
your thoughts to my W3C colleagues directly. If someone from the
javax.rules site of the fence wants to contribute thoughts on this,
be my guest!

The W3C public mailing list for DI stuff:


Original message from Richard: ======================================

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'.



View raw message