- Zope-Dev - Zope lists

IE and Zope MIME type handling
by Casey Duncan 22 Oct '01

22 Oct '01

Problem: Getting Zope to properly detect MIME types of posted files The current solution is to try the following methods: 1. See if the browser specified a type and if so, use it. 2. See if the file extension can be recognized and derive a mime-type from it 3. Do some inspection of the file data (limited to text files at present) Obviously #1 is preferred, and anytime the browser supplies the mime type, method #2 and #3 are never used. However, I have found a problem with this. Sometimes, IE reports a mime-type of "application/octet-stream" on files that is doesn't know better about. This specifically happens on WordPerfect files. Now, I am as shocked as you are that a competitor's file format would not be recognized by IE, however, difficult as this may be to believe, it appears to be true. My proposed solution and change in behavior is to ignore the browser supplied type if it is "application/octet-stream" and use #2 and perhaps #3 in that case to delve in further. Obviously this may pose a problem for applications that rely on the mime-type for files with extensions that might otherwise indicate something else. But since this behavior seems restricted to IE (amongst the browsers I tested), I doubt it would cause harm or breakage. Thoughts? I will supply the necessary patches if there is no objection. /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan(a)nlada.org \---------------------------------------------------/

3 2

Anyone know how to add a property to a Zope Product (not its instances)?
by Craeg K. Strong 22 Oct '01

22 Oct '01

I am developing a new Zope product in python. Normally one adds properties to a product like so: class newProduct(SimpleItem, etc): meta_type 'NewProduct' _properties = ( {'id': 'title', 'type':'string'}, { 'id':'description', 'type':'string'}, {'id':'foobar' , 'type':'string'"}, ) . . . This defines properties for instances of the new Product. But I want to add properties for the product itself. These properties would show up in the property sheet of the PRODUCT, not its instances-- ie in Root Folder/Control_Panel/Products/NewProduct on the Properties tab. By default, Zope adds the title and version properties, for which it gets the value from version.txt and meta_type, but does anyone know a way to add more? Thanks in advance, --Craeg

3 2

Re: International Objects
by Tim McLaughlin 22 Oct '01

22 Oct '01

Roger, I've identified a serious weirdness that causes InternationalObjects not to work. It's this... InternationalObjects - works on 2.4.0 and 2.4.0 upgraded to 2.4.1 but does not work on clean 2.4.1 install. This indicates an disconnect between the upgrade and clean install paths (at least that's my first thought). Zope-devers, any ideas? Anybody know of any __getattr__ changes in the 2.4.0 to 2.4.1 transition? Cheers, Tim Roger Espinosa wrote: > > On Wed, 17 Oct 2001, Tim McLaughlin wrote: > > > > > If so, let me know what you think after you toy with it a bit. Note > > that it also works with ZClass props :) > > > > Still persisting, as the more I dwell on it, the more I like this approach > --- one of the reasons I'm using Zope is the ease of mixing complicated > code with simpler code (handy for the education environment), and this > approach fits that ideal. > > At any rate --- I continue to fail if I try the monkeypatch; oddly, if I > do this bit of code: > > x = Item() > print Item.__getattr__(x, 'DEBUG') > > it'll correctly work, but > > x.DEBUG > > seems to skip it altogether; I even assigned the InternationalObjects > __getattr__ to an unrelated method (e.g. Item.fetchValueForKey = > __getattr__) and *that* works, which sure looks like something else is > hijacking __getattr__. > > Except when I just go patch the code into OFS.SimpleItem (I'm already > hacking get_request, so what the heck :)...it works as hoped. (Which would > tend to discount the hijacked __getattr__ business.) > > Anyway, neat idea :) > > Roger -- Tim McLaughlin iterationZERO - www.iterationzero.com 703.481.2233

1 0

ComputedAttribute, Persitent and "too many datafull base classes"
by Godefroid Chapelle 21 Oct '01

21 Oct '01

Hi, In a product I am writing, I am trying to add a ComputedAttribute to an instance of a Folder descendant class. This is the code I use: def addComputedAttribute(self, attributeName, sourceCode): methodName = '_ca_get%s' % attributeName self.addMethod(methodName, sourceCode) setattr(self, attributeName, ContextComputedAttribute(self.__class__.__dict__[methodName])) where at first I defined ContextComputed Attribute like this: import ComputedAttribute _ComputedAttribute = ComputedAttribute.ComputedAttribute del ComputedAttribute class ContextComputedAttribute(_ComputedAttribute): pass This put the Folder in a bad state : when I access it later, the Zope instance crashes. So I supposed I needed to use a persistent Attribute and I tried with ContextComputedAttribute class defined like this: class ContextComputedAttribute(Persistent): def __init__(self, test): pass In this case, the Folder stays in a good state but it does not fullfill the requirements as ContextComputedAttribute does not descend from the real Zope ComputedAttribute class. My problem is the following : I cannot define a class like this: import ComputedAttribute _ComputedAttribute = ComputedAttribute.ComputedAttribute del ComputedAttribute class ContextComputedAttribute(_ComputedAttribute, Persistent): pass In this case, I get the following error TypeError: too many datafull base classes which has to do with too many ExtensionClass derivation... Can someone tell me how to define a class with both ComputedAttribute and Persistent behaviours ? Thanks a lot. -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 30 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 457490 Mob + 32 (477) 363942 TVA 467 093 008 RC Niv 49849

2 1

RE: [Zope-dev] Zope 2.4.2 Error
by E. Seifert 20 Oct '01

20 Oct '01

Hi Andreas, thanks again for your answer. > Why do you say it is an error. It is a deprecation warning. > This warning framework is also used in Python to warn > about the usage of deprecated features that will change or > go away in a later release. But it is not an error and does > not limit your functionality. I'm not talking about the deprecation warning but about the error message I received after installing the update (it was in the citation - I should have mentioned it more explicitly): Traceback (innermost last): File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/zope/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook (Object: de) File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/zope/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: index_html) File /usr/local/zope/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: index_html) File /usr/local/zope/lib/python/OFS/DTMLDocument.py, line 199, in __call__ (Object: index_html) File /usr/local/zope/lib/python/DocumentTemplate/DT_String.py, line 546, in __call__ (Object: index_html) File /usr/local/zope/lib/python/OFS/DTMLMethod.py, line 188, in __call__ (Object: standard_html_header) File /usr/local/zope/lib/python/DocumentTemplate/DT_String.py, line 546, in __call__ (Object: standard_html_header) File /usr/local/zope/lib/python/Products/Renderable/Renderable.py, line 17, in __str__ (Object: standard_site_menue) File /usr/local/zope/lib/python/OFS/DTMLMethod.py, line 195, in __call__ (Object: render) File /usr/local/zope/lib/python/DocumentTemplate/DT_String.py, line 546, in __call__ (Object: render) File /usr/local/zope/lib/python/DocumentTemplate/DT_In.py, line 770, in renderwob (Object: objectValues(['SimpleNav Element'])) File /usr/local/zope/lib/python/Products/Renderable/Renderable.py, line 17, in __str__ (Object: ab) File /usr/local/zope/lib/python/OFS/DTMLMethod.py, line 203, in __call__ (Object: render) KeyError: validate Bye Erich

1 0

Python 2.2a1
by Andy McKay 20 Oct '01

20 Oct '01

Is out and: "Large file support is now enabled on Win32 and Win64 platforms, and automatically configured (at least on Linux and Solaris)." Cool, that will mean there will be less worries about Zope users hitting the 2 gig limit. Cheers. -- Andy McKay.

5 4

zope redistibution
by Lukas Maag 20 Oct '01

20 Oct '01

hi, i use zope 2.4.1 and the redistribution fuction works not. i can not distribute a product under allowance of redistribution. if i want to distrbute on another zope installation it says, that this is not redistributable, although i marked explicitely 'allow redistribution' on the other distribution! it's now a problem for me, because i relied on this. i can not reuse my improved product! can anyone help me, please. thanx lukas

4 3

Small ZMI enhancement
by Casey Duncan 20 Oct '01

20 Oct '01

When working in versions, it is currently a pain to get to the current version you are working in. Since the ZMI displays the path to the current version at the top, I thought, why now make this a link to the version so that you can get there in one click and manage it? Here is the patch to lib/python/App/dtml/manage_tabs.dtml: *** manage_tabs.dtml~ Fri Oct 19 11:34:11 2001 --- manage_tabs.dtml Fri Oct 19 11:37:48 2001 *************** *** 161,167 **** <dtml-if Zope-Version> <div class="system-msg"> ! <em>You are currently working in version <dtml-var Zope-Version html_quote></em> </div> </dtml-if> </dtml-unless> --- 161,167 ---- <dtml-if Zope-Version> <div class="system-msg"> ! <em>You are currently working in version <a href="&dtml-SERVER_URL;&dtml-Zope-Version;/manage_main"><dtml-var Zope-Version html_quote></a></em> </div> </dtml-if> </dtml-unless> Anyone object to putting this in the core? Enjoy. /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan(a)nlada.org \---------------------------------------------------/

3 2

standard_error_message and displaying non-html content.
by Noel Duffy 19 Oct '01

19 Oct '01

I have a zope site where users can access content using either html browsers and non-html devices, wap/wml, voicexml etc. I want to customize the standard_error_message dtml document to display errors in the appropriate format for each user. For example, if a user tries to access a non-existent url from a wml browser, they should get a nice wml page back saying that the page was not found. Heres the problem. Although I have customized standard_error_message to display a page in the right format, the code in ZPublisher/HTTPResponse.py (exception method of HTTPResponse class) checks the error page I generate and, if it doesn't see "<html>" or "<!doctype html" at the start of the page, it wraps my page in some html by calling _error_html. Thus I get a small wml page wrapped in html :-( It makes no difference what the content-type header is set to - I'm setting that correctly for the users browser. Is there any clean way I can alter this behaviour short of changing the code in ZPublisher/HTTPResponse.py? I say clean because I did find a rather ugly hack that will work - it involves replacing a method of the RESPONSE object at run-time. Not nice! Thanks in advance Noel Duffy. -- Noel Duffy Senior Software Engineer www.propylon.com Tel: +353 96 36038 Fax: +353 96 36353

6 7

Proposal: have install_product detect __init__.pyo too
by Richard Jones 19 Oct '01

19 Oct '01

I'd like to run python in its optimised mode (to try to squeeze that extra 1-5% of performance out of it ;). The only real barrier to doing this is that install_product doesn't check for __init__.pyo (just .py and .pyc). Would there be serious problems if it was modified to detect the .pyo as well? Richard

3 2