You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Christian Kesselheim <ck...@infeurope.lu> on 2004/12/23 19:15:41 UTC
Fast access bar vs. render()
Hello!
Dunno if its because of my perhaps simple-hearted approach or just due
to a lack of knowledge about the bells and whistles of tapestry's
internals, but I recently bumped into some kind of problem with
implementing one scenario at my project:
<html jwcid="@PageBorder" title="Small demo">
... more html & components...
<span jwcid="@SectionNavigator"/>
<span jwcid="@BasicInfoSection"/>
... more html & components...
<span jwcid="@AnnotationSection"/>
... more html & components...
</html>
The idea seems simple: the @SectionNavigator component should render
the title of each section within the page (including a link to it) at
the top of the current page (similar to a fast access bar).
I've tried to let each Section (all sections page classes extend a
common base class) register itself to the surrounding @PageBorder
component via e.g. finishLoad(), prepareRendering() or by implementing
the PageRenderListener so the @SectionNavigator could assemble the list
at final rendering time - with no success.
After digging into the source of tapestry, It occured to me that the
current implementation of BaseComponent does only invoke
IComponent.render() on each child component, with having
BaseComponent.render() itself dispatching the call to the corresponding
prepareRendering(), renderComponent() and cleanupAfterRender() methods
afterwards. Of course, this would not live up with my requirements.
I had a look at the implementation of the standard @Body component,
recognising similarities between this component and the one I was
supposed to design (since @Body allowed its child components to
register client side javascript snippets as part of their evaluation).
@Body seems to simply invert the order in which the ordinary
BaseComponent (via @RenderBody) caries out the rendering process:
First, the body is rendered and stored in a temporary writer object.
Afterwards, the actual (@Body) component (with its javascript snippets,
etc.) is rendered. This is what did the trick for the body component.
So now I wonder if there is really no more convenient and standard way
of addressing this probably common scenario (e.g. via a seperation of
the rewinding/IRender tree construction and the actual rendering
process). Frankly speaking, I consider myself quite a newbie to
tapestry, so input of any form is very welcome (except for RTFM,
because this is something I already did! Twice :)! Even the "in action"
book! Still no f***ing clue!)
Best regards,
Chris
-------------------------
infeurope S.A.
62, rue Charles Martel
L-2134 Luxembourg
Luxembourg
Tel: (+352) 25.22.33.1
Fax: (+352) 25.22.33.222
Web: www.infeurope.lu
-------------------------
Any views expressed are purely those of the writer and may not in any
circumstances be regarded as stating an official position of infeurope
S.A.!
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org