-----Original Message----- From: Amos Latteier [mailto:amos@aracnet.com] Sent: Thursday, March 04, 1999 1:28 PM To: Pavlos Christoforou Cc: zope-dev@zope.org Subject: Re: [Zope-dev] FAQ Submission
At 12:32 PM 3/4/99 -0500, you wrote:
I think Skip provided a better way to deal with this, but I
am not sure if
it has made it in the official DocumentTemplate release.
Michel's use of a debug flag is cool. Only, are you aware of Z_DEBUG_MODE (aka BOBO_DEBUG_MODE, aka __bobo_debug_mode__)? It's purpose is exactly things like this. It gives more informative errors, and should make all objects that care operate in debug mode.
For example, I believe that HTMLFiles should check for this and reload it's content if it is set.
Check out this snippet of code from Main.py
for n in 'Z', 'BOBO': if os.environ.has_key('%s_DEBUG_MODE' % n): n=string.lower(os.environ['%s_DEBUG_MODE' % n]) if n=='no' or n=='off': continue try: n=string.atoi(n) except: pass if n: Globals.DevelopmentMode=1
Now you know how to check for debug mode in your own objects, check for 'DevelopmentMode'
-Amos
I think we're talking about two different methods. In my code... def defaultDocFile(self, id, title, file): f=open('%s/Products/Notmail/%s.dtml') % (SOFTWARE_HOME, file)) file=f.read() f.close() self.manage_addDocument(id, title, file) (which BTW Amos, YOU contributed to NotMail months and months ago before the Great Open Sourcing ;) ...how does the Document object know, after the fact (remember this method is called from __init__) where it's content came from? The path and file pointer are discared after this function returns. Unless the Document instance added by manage_addDocument is telepathic, I can see how it would know where it came from. I can see where in the case where DTML is called like so: amethod = HTMLFile('filename', globals()) The Z_DEBUG_MODE comes in handy, but the manager is never given the option to edit the contents of the Document after the object is created without changing the file on disk, which would change the return values of *all* the returned methods (like 'amethod' above) and effectively change the look of ever instance of the Product in Zope. Different instances of the NotMail Product (the one where my code snips came from) can all edit their own interfaces, because defaultDocFile loads the documents off of disk and puts them into the NotMail Folder. At this point they are unrelated to the files on disk. I think? If this is the case (I think it is) then my original post was a correct method (altough my original post was probably nowhere near clear enough about it). If the Product author wants to return a document loaded at __init__ time into a folder with defaultDocFile she can just: def amethod(blah, bler, REQUEST=None) ... return self.id_of_document(self, REQUEST) With this method, if a Product is a folder it can contain it's own UI, independent of any other instance of the object's UI, and independent of the contents of the DTML in the Products directory on disk. Because this Document object is independent of the contents of the file on disk, the reload_docs method in my original post is used to delete each Document, and reload it from disk, without having to delete/recreate the NotMail object, which gets REALLY old quick when I'm changing my DTML alot. All of this aside, I should not have my own 'debug' attribute but should sniff for Z_DEBUG_MODE instead. I'll try and wrassle up a clearer post for the list. (BTW, both of these methods, the common way and the Product-containing-it's-own-UI way, are detailed extensively in The Zen of Zope). For a hands on example of this method, check out NotMail sources. Confera also does a similar thing (but doesn't offer the ability to reload it's interface) -Michel
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://www.zope.org/mailman/listinfo/zope-dev