Jim Hebert wrote:
> I'll go ahead and embarrass myself now, and explain what I did. Other
> people can chime in with "wow, that was dumb, here's the right way to do
> that" as needed (I'd really welcome that, actually!).

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

> ...
> <dtml-with images>
> <dtml-with "PARENTS[0]">
> ...
> </dtml-with>
> </dtml-with>
> The reason for the inner dtml-with is that my pages are DTML Methods, not
> DTML Documents, and the Folders are the "context." If all my content had
> "images" shoved on top of the namespaces stack, they'd get even simple
> things like <dtml-var title> wrong, because that's supposed to come from
> the Folder that method lives in... So, I push images onto the namespaces
> stack, then push "the parent" (as opposed to grandparent) up on top of the
> stack redundantly. This way the acquisition picks up the things like title
> from the current folder, and even lets the current folder override some of
> the "common" elements, but then falls back to this arbitrarily chosen
> folder to go find the other peices next, and then finally goes through the
> normal acquisition dance of going up the parents list.
> This actually worked out pretty well (boy, was I shocked ;->).

If we could find some way to effectively communicate the way Zope works
(and what goes on in Jim Fulton's head), the fact that this works
wouldn't be so surprising.  Achieving this is not just about documenting
interfaces, however.  It's also about new design patterns that are made
available through the concept of acquisition.  I hope that the books
being written about Zope go into depth on the new concepts.

Good work!


Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-dev )

Reply via email to