[Zope] ZClass container acquisition

[John D. Rowell]

On Tue, Apr 25, 2000 at 12:37:55AM -0400, Kapil Thangavelu wrote:
> i feel bad for posting this, and i can't even say if it will work, and
> it might hose your ZODB, and curdle your milk, and lots of other
> unspeakable nasties, in other words use at your own risk and beware. 
> 
> http://www.zope.org/Members/AlexR/ChangingBaseClasses

Will try it out, thanks :)

> > Also, I'm having problems with acquisition that may be related to forcing
> > the client when rendering ZClasses:
> > 
> >         - ZBox is a ZClass that renders fancy boxes
> >         - standard_html_header in the root folder uses ZBox (using the
> >           <dtml-var "zclass.method(zclass, _)"> syntax)
> >         - ZLeaf is a folder-aware DTML Document that creates links to
> >           other documents in that folder as part of a toolbar. It uses
> >           the standard_html_header in that folder, which calls the root
> >           standard_html_header (thru PARENT)
> 
> yikes, nested/looping acquisition contexts are a mess. folder-aware
> document?

Uhmm, I wouldn't say so. The idea is to keep site globals (headers,
footers, boxes, etc) in DTML Methods in the root folder. These are
acquired by the subfolders, which optimally only contain ZClasses (I
tend to change my mind about design and functionality, and want maximum
flexibility). The only thing I'm really trying to acomplish here is to
acquire a DTML Method that calls ZClasses, and use that inside another
ZClass. This seems to fail most (all) of the time. The fact that an
acquisition path is not trivial should not break the model, since things
tend to get complicated when you build a large site anyway.

The "folder-aware document" is the name I give to my documents that have
knowledge of their parent folder and its items, and uses that to
generate content inside itself (through lookup or iteration, not direct
reference).

> > Trying to access the URL "http://server/f" gives exactly the same error.
> > This looks like if I acquire a DTML Document that contains a ZClass, it
> > will fail, while calling that document directly succeeds.
> 
> Dtml Document containing a ZClass??.. maybe the other way around.

It actually calls a ZClass, excuse my bad use of the term "contain".
Then call is contained inside the document ;)

> > The dump:
> > 
> > --------
> > 
> > Error Type: AttributeError
> > Error Value: __call__
> > 

> first make Zleaf a method, this is the clasic def. of a method, since
> its acting on its container. if its just looking for documents to link
> it could be as simple as.
>  <table><tr>
>  <dtml-in "objectItems(['DTML Document'])">
>  <dtml-with sequence-item>
> 	<td><a href="<dtml-var absolute_url>"><dtml-var title_or_id></a></td>
>  </dtml-with>
>  </dtml-in>
>  <tr></table>

I actually have this working in a similar way (the ZLeaf class is on
hold until I have a better grasp of the acquisition problem) , but my i
objective here is to take the opportunity of this site redesign to 
structure it in the best way possible and release some Zope Products along 
the way. For this to be successful, everything has to work as planned, and 
not as a workaround for what didn't work. I already have a finished product
(PathEater, name stolen from discussions on this list ;)) that solves
all of my __bobo_traverse__ problems in a neat way, which I just started
testing yesterday and should be releasing later this week if all goes
well. It contains a one-line patch to ZPublisher/BaseRequest.py, and I'd
like to determine if my other areas of trouble are Zope bugs or just
misunderstandings on my part before I submit additional patches.

> regarding zboxes and jdfetch:
> you might want to check out RSSChannel, instead of having an external
> perl script, plus it gives you Catalog indexin of the headlines.

Uhmm, the ZBox I'm talking about is something unreleased, maybe there is
another product by that name out there already. jdfetch is a really old
solution from the Zope 1.x days that I haven't had time to update
recently (it does work though ;)). I'll try RSSChannel when I revamp
jdrowell.com.

> www.moreover.com , and www.headlinewatch.com have thousands of RSS/XML
> feeds/

Yes, XML is the way to do it right. O'Reilly is making some significant
advances in wrapping something around these feeds with Meerkat
(http://oreillynet.com/meerkcat). They also have an ongoing discussion
about new RSS standards and use many of the moreover.com feeds. You
should get in touch with them about new standards in that area as they
already have some experience with this volume of feeds.

Cheers,
jdrowell

-- 
John Douglas Rowell            Home of jdfetch 0.4.0, jdresolve 0.5.2,
me@jdrowell.com                jdrinfo 0.2, jdtracker 0.11 and
http://www.jdrowell.com        jdwhatsnew 0.21
Member of the AppWatch staff - http://appwatch.com - staff@appwatch.com