[Zope] Alternative Rendering (was Re: [Zope] Messing with the namespaces stack)

[Chris Withers]

Jim Hebert wrote:
> Uh oh, careful, I'm encouragable and you'll really have a monster on your
> hands. ;-)

<ego stroke>
I like the way you think, lots of good will come of it.. ;-)
</ego stroke>

> I am bucking a trend, I am starting to realize. Big time! The assumption
> seems to be that any given page will build itself, it will suck in
> standard_html_header and standard_html_footer, and compose itself of
> whatever else in between those things. DTML Document is the base unit of a
> page.

I think it's a trend worth bucking, as you point out, this trend can be
out of line with the whole acquisition - inheritence objecty thing that
Zope does so well...

> front end for our system, I wanted people to be able to upload simple,
> stupid chunks of "content" html and not have to do things like put
> <dtml-var standard_html_header> at the top and ..._footer at the bottom.
> Any lame wysiwyg editor that had save-to-ftp could then push up a 'body
> file' into the right folder, and I could get writers writing without
> learning zope.

Totally agree with this :-)))

[snip excellent possible solution]

> And, I can also come up with different renderers, I suppose. Untested
> might be the idea that I could put /alt_renderer as a DTML Method at the
> top level, then visit /about/alt_renderer and invoke that method in the
> /about context. So by separating content from presentation, I can plug my
> content into lots of things simultaneously. Presumably.

This would be really useful for things like WAP and AvantGo...

[snip sucky products]

Well, you either have to re-develop the products or live with them :/

> I don't honestly expect that what I invented in the middle of the night 7
> days before the VistaSource launch to revolutionize how everyone builds
> pages 

With any luck, you may be surprised ;-)

> perhaps someone will have suggestions on how I can make my style "play
> nicer" with all these products, too.

I have a slightly different take on the problem from back when I used to
use mason. Autohandlers solve parts of this...

An autohandler is a bit of code which would get executed during URL
traversal. it's main use is to render a wrapper around a page, for
example:

...do stuff...
process and render the rest of the URL (called mc_auto_next in Mason)
...do mroe stuff...

So your standard_ stuff apears in the autohandler and is _automatically_
wrapped around the eventual object.

How far would this go to doing what you were talking about?

Not far enough might be the answer... I'm really interested in the stuff
you talked about so please email more of it to me directly if you don't
think it's list-related enough....

hope to hear from you soon,

Chris