Hi, I've run into a really annoying bug and was wondering if it is fixed in the CVS version (I don't have direct internet access to check). Create a new Product containing a Zclass subclassing from the DTML Document or Method. Add a Python or DTML Method which does: This document is <dtml-var id> Then, add an instance of this Zclass. When you VIEW it you get: This document is <cstring ...> AND when you edit it the ID is empty. All references to the ID and related internal variables return CSTRING or cause tracebacks. How do i get the REAL id? Also, I can get the unprocessed content via self.read() but how do I get the processed data? repr, `..` and index_html all give weird tracebacks. This is stopping me from finishing a JavaScript XMLWidget for XMLWidgets release 2 so any help would be greatly appreiated. Just a thought - what about adding a Storage/Zclass mixin class for people doing combo Product / ZClass systems. Hence, the ZClass gets stored within a ZODB in the appropiate Product directory hence reducing installation hassles. This also means we can just zip up the Product directory to automatically include ZClasses [looks at the ZODB experts on Zope-dev]. Cheers, Anthony Pfrunder
Anthony Pfrunder wrote:
Hi,
I've run into a really annoying bug and was wondering if it is fixed in the CVS version (I don't have direct internet access to check).
Create a new Product containing a Zclass subclassing from the DTML Document or Method. Add a Python or DTML Method which does:
This document is <dtml-var id>
Then, add an instance of this Zclass. When you VIEW it you get:
This document is <cstring ...>
AND when you edit it the ID is empty. All references to the ID and related internal variables return CSTRING or cause tracebacks. How do i get the REAL id?
Did you try <dtml-var document_id>?
Also, I can get the unprocessed content via self.read() but how do I get the processed data? repr, `..` and index_html all give weird tracebacks.
You have to call yourself with a context or mapping: rendered = self(self) would be an interesting combination if self could satisfy it's own DTML needs.
Just a thought - what about adding a Storage/Zclass mixin class for people doing combo Product / ZClass systems. Hence, the ZClass gets stored within a ZODB in the appropiate Product directory hence reducing installation hassles. This also means we can just zip up the Product directory to automatically include ZClasses [looks at the ZODB experts on Zope-dev].
My brain hurts when I even try to think about it. Without a good model, I have no idea. Give it a whack if you think it can happen. -Michel
On Sun, 17 Oct 1999, Michel Pelletier wrote:
Anthony Pfrunder wrote: [snip] Did you try <dtml-var document_id>?
Yes and every other thing I could think of <dtml-var title_or_id>... Remember, the ID field within the View / Edit property sheet (aquired from DTML doc) has an empty ID field which shouldn't happen. [snip - will try self(self) when I get home]
Just a thought - what about adding a Storage/Zclass mixin class for people doing combo Product / ZClass systems. Hence, the ZClass gets stored within a ZODB in the appropiate Product directory hence reducing installation hassles. This also means we can just zip up the Product directory to automatically include ZClasses [looks at the ZODB experts on Zope-dev].
I had a brief look but I couldn't see how ZClasses actually triggers a transation to store the stuff you create. I am thinking of something like: class My_Product(mixin1, Folder, Zclasses_mixin): def __init__(self, ...): self.storage_thingo = FileStorage(Product_Base + '/ZClasses.zexp') Zclasses_mixin.__init__(self.storage_thingo, cool stuff) So for starters: * How does ZClasses trigger / manage transations * There is a DBStorage example in Zope/ZODB but how do you "mount" it such that all operations on objects within a certain folder are redirected to this Storage without ANY transations stored in the host?
My brain hurts when I even try to think about it. Without a good model, I have no idea. Give it a whack if you think it can happen. Panadol is an esstential part of the Zope Developers toolkit ;) BTW: the comments and function names within the DTML source code are REALLY funny.
Cheers, Anthony Pfrunder
participants (2)
-
Anthony Pfrunder -
Michel Pelletier