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
components.
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
here:
Installer ss project:'Beach' install: 'Beach-Packages'.
Keith