Alternative approach for rendering page headers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Alternative approach for rendering page headers

keith1y
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.
           
PageWithHeader - Uses the above to render a "header document" *for more
interesting headers)

Hooks for providing custom subclasses of all renderers


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: Alternative approach for rendering page headers

keith1y
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





_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki