[ZPatterns] ZPatterns and...CMF???

[Steve Spicklemire]

Hmm.. What is it about CMF that requires "ZODB stubs"? (and what the 
heck is a "ZODB stub" anyway?) Is this all "well understood" terminology 
over on the ZODB mailing list? I don't see it mentioned much by the CMF 
folks.

thanks,
-steve

On Saturday, November 10, 2001, at 09:19 PM, Phillip J. Eby wrote:

> At 07:25 PM 11/10/01 -0500, Gary Poster wrote:
>> Hello all.  So, I've become somewhat enamored of CMF.  Integrating my 
>> RDBMS
>> with my CMF via ZPatterns suddenly seemed like a fantastic idea in 
>> theory,
>> so I've been looking around to see what the Zope world has been doing 
>> in
>> this general direction before I, in a fit of enthusiasm, wasted days of
>> thought and work that people smarter than me have already done and 
>> perhaps
>> discarded.  It seemed all I would have to do is make the ZPatterns 
>> ZClasses
>> have the correct CMF mix-in classes and build the mapping to view, 
>> edit, and
>> metadata forms.
>>
>> But nobody has said a darn thing I can find about doing ZPatterns with 
>> CMF,
>> except ...
>> http://zope.nipltd.com/public/lists/dev-
>> archive.nsf/ByKey/E6526C76DA28C391
>> ... Shane:
>> > Let's say you want CMF objects to be stored in an RDBMS.  You don't 
>> want
>> > to use ZODB stubs and you want a tree of persistent objects.  
>> ZPatterns
>> > can't help you.  Can SmartObjects?
>>
>> (no answer I can see to the final SmartObjects question, btw).  Why 
>> does
>> Shane write off the ZPatterns solution?  I suppose I could ask him,
>> but...I'm asking here first. :-)
>
> Because ZPatterns as it exists today would require ZODB stubs to do 
> what is described, at least based on what you've quoted above.
>
> Actually, it's not 100% true that ZPatterns can't help.  You *could* do 
> it, but you'd need to hack the base classes (primarily ObjectManager or 
> the equivalent).  It's messy.  At one point I contemplated providing 
> the necessary machinery for this in DataSkins, but it's just continuing 
> the direction of kludging and hacking things that I feel has made 
> ZPatterns an evolutionary dead-end.   I've had enough trouble keeping 
> ZPatterns' hacks current to the ever-more-frequent Zope releases, 
> without trying to add any new capabilities.
>
> The new Zope component architecture is supposed to fix all this; in 
> practice it will not address something like storing CMF objects in an 
> RDBMS for a long while if ever, so long as the issue is one of 
> supporting all the possible third-party classes deriving from CMF 
> bases.  To fix a problem like this requires aspect-weaving or other 
> "open implementation" approaches, such as TransWarp provides.  (Which 
> is another reason I gave up some time ago on doing any extensive 
> improvements to ZPatterns.)
>
>
> _______________________________________________
> ZPatterns mailing list
> ZPatterns@eby-sarna.com
> http://www.eby-sarna.com/mailman/listinfo/zpatterns