[Zope] Messing with the namespaces stack [Was: (no subject)]

[Jim Hebert]

On Thu, 29 Jun 2000, Shane Hathaway wrote:

> Actually what you did is pretty clever, Jim.  It even relies on stable
> interfaces.

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

> > The reason for the inner dtml-with is that my pages are DTML Methods, not

OK, I am just going to go ahead and spill the rest of what swirled around
in my head about zope when I threw up this vistasource.com site, in the
hopes that I'll either get another ego stroke (*grin*) or some more
insights as to the reason why things are done the way they are (ie, not
the way I do 'em!). This is probably going to be long, please forgive me
for going from newly subscribed to thinks-he-can-write-a-howto overnight!
=)

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.

Partially because I was planning at the time to build an over-simplified
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.

I also started to really groove on the idea of Object Oriented precepts
for my pages, and having to explicitly "#include" peices like the common
stuff offended those sensibilities. I wanted "objects" that had both
"data" and "code" as its members, in a nice little bundle.

So, I made the decision that my atomic unit of what constitutes a "page"
on my server is a Folder object. This lets me collect everything
specific to a page, images that are only used there, methods that are
only used there, etc, in a tidy little bundle. So here's my scheme:

I think of /index_html, a DTML Method, as if it were a member function of
an object. It might as well be named "render_this_folder_as_a_page." So,
it looks like (oversimplifying:)

<dtml-with images>
<dtml-with "PARENTS[0]">
<dtml-var standard_html_header>
<table><tr><td>
<dtml-var menu>
</td><td>
<dtml-var body>
</td></tr></table>
<dtml-var stnadard_html_footer>
</dtml-with>
</dtml-with>

So, now, in each folder I just put a dtml method called body. When you
visit /about, index_html gets acquired, but since it's a dtml method, the
/about folder remains the first place to look for other stuff, so body
gets located in /about. If I want to override the menu code, I also stick
another object in there called menu, but by default my toplevel menu code
works for all the subfolders. In some perverse sense, sub-pages
conceptually are sub-classes of higher up pages, which inherit some things
(index_html for instance) things and override things (/body, nearly
always, and sometimes other things).

If I repeitively built $header + $menu + some content + footer over and
over again in page after page, I couldn't radically redesign my site (for
instance, pulling in body and sticking an advertisement between every 3rd
paragraph) without touching every page. But in the model that I use, the
one true index_html method is free to suck body in, do crazy
post-processing to it, and then send that out.

And, of course, index_html itself can be overridden for sub-trees of the
site, if need be.

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.

The only thing that has bummed me out about this strategy is that I feel
like that every time I use a 3rd party product I end up working up hill:
it usually expects to be able to write out a DTML Method or Document that
says

<dtml-var standard_html_header>
app-specific-logic-here
<dtml-var standard_html_footer> 

and have gotten it all. Adding a "Search Interface" is a typical example
of this. When I can, I hack around this and migrate
"app-specific-logic-here" into SomeFolderName/body. But for products which
manufacture pages on an ongoing basis, e.g. FlexFaq/Knowledgebase,
this is less of an option, and points more towards me hacking the package
code itself.

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 (like I said, I actually suspect that these hacks that I invented
have some major drawback that you guys will help clue me into, though,
hehehe, I haven't been dissauded by the search drawback..), but
perhaps someone will have suggestions on how I can make my style "play
nicer" with all these products, too.

Sorry so long. If this was illustrative to anyone for seeing how
unbelievably, scream it down the halls, wake your mom up in the middle of
the night to tell her, very very cool Zope is, then it was worth it. =)
Because Zope is quite simply the coolest damn thing I have ever worked on,
bar none. I would love to bump into Jim Fulton at a show sometime, because
I think I like the way his mind works!! =)

jim
hoping to git educated. =)

-- 
Jim Hebert                                       http://www.cosource.com/
jim@cosource.com          The cooperative market for open source software

"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox