Alternative approach for rendering page headers
keith_hodges at yahoo.co.uk
Tue Apr 7 02:28:52 MEST 2009
Keith Hodges wrote:
> I have always found this to be a bit of a weakness of pier's.
> Name: Beach-Pier-kph.5
> Author: kph
> Time: 6 April 2009, 11:02 pm
> UUID: 554b045a-54d7-47e0-9f21-b94b06e381ac
> Ancestors: Beach-Pier-kph.4
> Finally the ViewRenderer (or custom subclass) can have complete control
> over the display of the content AND the header
> PRContentsWidget is knobbled so as to not display the header.
> PRViewRenderer now displays the "title", for standard Pages, or the
> more interesting PRPageWithHeader can override this behviour
> PageWithHeader - Uses the above to render a "header document" *for more
> interesting headers)
> Hooks for providing custom subclasses of all renderer
At present in "latest" viewing (not embedding) structures like files and
components is broken. The Pier-Beach implementation is looking like a
pretty good way of fixing this.
> Name: Beach-Pier-kph.6
> Author: kph
> Time: 6 April 2009, 11:58:10 pm
> UUID: be4afe0d-8f23-4b2b-b3b7-c7dfcff81ac7
> Ancestors: Beach-Pier-kph.5
> Double back structure rendering to the PREmbeddedRenderer since it
> knows how to render most things better than the PRViewRenderer anyway.
> Yay we have viewing of structures back at last.
But I think it can go further.
Having taken responsibility for rendering the header away from the
PRContentsWidget, this gives much more flexibility. It does mean that
there is no-one to render the heading for Commands and other basic
So by shovelling the rendering of ALL components through the visitor
PRViewRenderer, rather than just PRDefaultView. This allows
PRViewRenderer to wrap Headings, (divs and anything else you want) on to
Commands, and any other seaside components.
This is really cool because it then means you can use non root seaside
components!!!! All you have to do is to add an #accept: method to the
component you want to use, and implement the specific invocation that
that component needs in PRViewRenderer (or your custom subclass).
So a custom PRViewRenderer or a subclass of PRPage/Structure can
implement their own header rendering, AND html rendering for any
Component, be-it widget, structure, or Seaside component.
The one thing that is missing is to be able to control things from the
environment (I dont use an environment myself). So perhaps
+contents|renderer=PRMyRenderer+ will suffice. I added
descriptionRenderer to PRContentsWidget.
I think this is looking really cool.... perhaps even worth a Pier 1.2!
Please take a look at it. The thought if having to maintain this as a
fork is a bit worrying.
The implementation is in 'Pier-Beach' -- the dependencies are documented
Installer ss project:'Beach' install: 'Beach-Packages'.
More information about the smallwiki