[Zope-dev] FAQ Submission

[Michel Pelletier]

> -----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
>