Re: [Zope-dev] [ZOPE 2.6 B1] Unicode/locale problems withOFS/dtml/properties.dtml
On Saturday 28 Sep 2002 4:38 pm, Florent Guillaume wrote: (yes, this sucks. The problem is that browsers dont specify the character encoding used in form submissions. At some point we need to discuss the way forward on this issue) Just to be clear, this is an HTML attribute of the form tag. For instance: form action=foo ... accept-charset=UTF-8 ... /form This instructs the browser it should send the content of the form in the accepted charset. Yes, accept-charset could be part of a full solution to this problem, but I dont think it is a whole solution Are you suggesting that a method could assume its form submissions would always be made in utf-8? That would cause problems if a submission was made from: * some other form that didnt have an accept-charset * some non-browser code that synthesizes http requests A further problem is that we want this decoding to be performed in ZPublisher, but that that point in the publishing process it doent know which method is going to be called. That means the utf8 assumption cant be made independantly for each method. One answer to this problem is when browsers include the charset attribute in multipart/form-data POST requests. ZPublisher knows unambiguously what encoding was used by the browser. Sadly I cant see a nice way to do the same for GET requests ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] REQUEST object enlightenment needed
Colin Leath wrote: I think this is a problem with the plain StructuredTextDocument lacking it's own request object. The REQUEST object is an object representing the HTTP REQUEST as is usually acquired, so STD's (nice ;-) obviously aren't managing to acquire the REQUEST in the context you're using them. Bear in mind that the way some of the TreeMaker stuff works will strip acquisition and may be causing the REQUEST to be lost from the acquisition chain if your STD usage also does something interesting with acquisition. cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] KeywordIndex errors: This should not happen.
Hi all Our app has been hitting these errors for months: 2002-09-30T11:06:27 ERROR(200) KeywordIndex unindex_object could not remove documentId -444153566 from index ComponentVersions. This should not happen. Traceback (innermost last): File /usr/local/zope/2-5-1/lib/python/Products/PluginIndexes/common/UnIndex.py, line 168, in removeForwardIndexEntry (Object: ComponentVersions) KeyError: -444153566 Here is the relevant piece Zope code:: def removeForwardIndexEntry(self, entry, documentId): Take the entry provided and remove any reference to documentId in its entry in the index. global _marker indexRow = self._index.get(entry, _marker) if indexRow is not _marker: try: indexRow.remove(documentId) if not indexRow: del self._index[entry] try: self.__len__.change(-1) except AttributeError: pass # pre-BTrees-module instance except AttributeError: # index row is an int del self._index[entry] try: self.__len__.change(-1) except AttributeError: pass # pre-BTrees-module instance except: import pdb; pdb.set_trace() #DBG I inserted that 'set_trace' just before the error is logged. At this point, the app state looks like this:: (Pdb) self KeywordIndex instance at 9544940 (Pdb) p self.id 'ComponentVersions' (Pdb) entry '44.131' (Pdb) p indexRow IITreeSet object at 0x1355a3d0 (Pdb) len(indexRow.keys()) 566 (Pdb) indexRow.remove(documentId) *** KeyError: -444153566 (Pdb) [self._index.keys()[n] for n in range(0,69)] ['', ' 2.13', '1', '1.14', '1.22', '1.25', '1.3', '1.6', '1.8.7', '1.9.8', '17.9', '2.0.6', '2.1', '2.15', '2.2.1', '2.2.3m', '2.2.7', '2.2.7m', '2.3.4m', '2.4', '2.4.2m', '2.4.3m', '2.4.4m', '2.4.5', '2.5', '2.6.6m', '2.7.7m', '2.8.5m', '2.8.6m', '2.8.7m', '2.9', '20.13-37', '22.13-42', '22.42-47', '22.5-42', '24.12-49', '24.13-49', '24.19-49', '4.4', '4.9', '40.54e', '41.184', '42.95', '43.11', '43.96', '43.96 ', '44.120', '44.131', '45.11', '7.3', '7.7', '8.0', '8.1', '8.2', '8.4', '8.4.1', '8.5.9', '8.7.2m', '8.7.6m', '8.8.9m', '8.9.6m', '8.9.7m', '9.0', '9.12', '9.2', '9.3', '9.4 ', '9.8', 'x'] (Pdb) [indexRow.keys()[n] for n in range(0, len(indexRow.keys()))] [-1948802264, -1018656130, -444153568, -111852827, -32258423, -32258421, -32258398, -32258397, -32258396, 226891955, (and so on) (Pdb) catalog = self.restrictedTraverse('Catalog') (Pdb) catalog.getpath(-444153566) '/Licenses/LicenseDocs/License_377' (Pdb) catalog.getIndexDataForRID(-444153566)['ComponentVersions'] ['2.4', '8.9.7m', '44.131', '44.131', '2.4.3m', '4.9', '9.12', '24.13-49', '1.25', '2.15', '9.3', '2.8.6m'] Rephrasing that, I'd say: we're trying to remove the RID -444153566 from the list returned by: indexRow.keys()['44.131'] That RID is absent from that list, which raises a KeyError that should not happen. There *is* an entry in the Catalog for that RID, which *has* '44.131' in the list under the 'ComponentVersions' key in the dict returned by getIndexDataForRID. Did the RID get removed from the KeywordIndex list of RIDs prematurely? Or did it never get inserted? Can anyone shed any enlightenment? Where else should I be looking? -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Problem with security context when calling DTML Method
Hi! I'm writing a proprietary set of python classes for my product. As part of this product, there is a base class with redefined index_html method. This method looks for some object (practically, DTML Method) in it's context with predefined id and tries to call it. The problem is that my object loses security context, and DTML Method is called under Anonymous User priveleges: security.declareProtected(View, 'index_html') def index_html(self, client=None, REQUEST={}, RESPONSE=None, **kw): if client is None: client=self index=getattr(client, self._template_id, None) if index is None: if RESPONSE: RESPONSE.notFoundError(self.absolute_url()) else: raise security=getSecurityManager() security.addContext(index) return apply(index.__call__, (client, REQUEST, RESPONSE), kw) Is anybody can to point out my mistake? Best regards, Vlad Mozhaev ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [ZOPE 2.6 B1] Unicode/locale problemswithOFS/dtml/properties.dtml
On Mon, 2002-09-30 at 09:17, Toby Dickenson wrote: On Saturday 28 Sep 2002 4:38 pm, Florent Guillaume wrote: form action=foo ... accept-charset=UTF-8 ... /form This instructs the browser it should send the content of the form in the accepted charset. Yes, accept-charset could be part of a full solution to this problem, but I dont think it is a whole solution Are you suggesting that a method could assume its form submissions would always be made in utf-8? That would cause problems if a submission was made from: * some other form that didnt have an accept-charset * some non-browser code that synthesizes http requests Yes, there is no good way. A further problem is that we want this decoding to be performed in ZPublisher, but that that point in the publishing process it doent know which method is going to be called. That means the utf8 assumption cant be made independantly for each method. One answer to this problem is when browsers include the charset attribute in multipart/form-data POST requests. ZPublisher knows unambiguously what encoding was used by the browser. This really sucks, you'd think that by 2002 all recent browsers would send a content-type:text/plain;charset=foobar in multipart/form-data, as the spec (from 1998) recommends... But even Mozilla 1.1 doesn't do it. Sadly I cant see a nice way to do the same for GET requests As an aside, one interesting tidbit about Mozilla: if you paste Unicode into a field of a form without an explicit encoding (accept-charset or document-charset), it encodes Unicode characters into #; and sends that on the wire. Anyway, in the near future I see no alternative to putting :utf8: into field names, and using accept-charset=UTF-8 or an utf-8 encoding for the document. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeywordIndex errors: This should not happen.
Don't know if this will help but these errors specifically occur with 'lines' properties with Keyword Indexes on them. What is also significant is that there are legitimate duplicates in the lines properties and that they are duplicated on the index data as well. This doesn't feel right. I would have thought that only unique values should be stored in the index data. -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za On Mon, 30 Sep 2002 14:17:17 +0200 Jean Jordaan [EMAIL PROTECTED] wrote: Hi all Our app has been hitting these errors for months: 2002-09-30T11:06:27 ERROR(200) KeywordIndex unindex_object could not remove documentId -444153566 from index ComponentVersions. This should not happen. Traceback (innermost last): File /usr/local/zope/2-5-1/lib/python/Products/PluginIndexes/common/UnIndex.py, line 168, in removeForwardIndexEntry (Object: ComponentVersions) KeyError: -444153566 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeywordIndex errors: This should not happen.
On Monday 30 Sep 2002 1:17 pm, Jean Jordaan wrote: Hi all Our app has been hitting these errors for months: Have you tried it in 2.6? A couple of bug in this area have been fixed since 2.5.x ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeywordIndex errors: This should not happen.
On Monday 30 September 2002 08:36 am, Roché Compaan wrote: Don't know if this will help but these errors specifically occur with 'lines' properties with Keyword Indexes on them. What is also significant is that there are legitimate duplicates in the lines properties and that they are duplicated on the index data as well. This doesn't feel right. I would have thought that only unique values should be stored in the index data. If you feel this is a bug, you should file a collector issue for it. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeywordIndex errors: This should not happen.
If you feel this is a bug, you should file a collector issue for it. We don't have a deep enough understanding of the Catalog to diagnose :/ We're not sure if it's a Catalog issue, or something we're doing wrong; i.e. we don't know how the Catalog gets into that state. -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Only anonymous in an Access Rule?
Hi, How come getSecurityManager().getUser() returns the Anonymous User in access rules? Surely some checks must have been done to see whether the folder containing the access rule can be traversed to? If so, then why is the anonymous user still being returned? If not, then huh? I'm confused :-( Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeywordIndex errors: This should not happen.
Toby Dickenson wrote: Our app has been hitting these errors for months: Have you tried it in 2.6? A couple of bug in this area have been fixed since 2.5.x Yeah, this'd be my suggestion having suffered more terminally from exactly these bugs :-S cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Problems using Z SQL Method result
Help!! I am trying to write a product that will encapsulate a SQL query and render the results in a table. But I'm having a terrible time getting at the data in the SQL results. This works in DTML: dtml-in expr=sql_method() prefix=row pdtml-var expr=row_item['name']/p /dtml-in But if I try this in my product's code directly: result = apply(sql_method, (), {}) for i in result: foo = i['name'] I get the following exception: Error Type: UnpickleableError Error Value: Cannot pickle extension class Acquisition.ImplicitAcquirerWrapper at 5e8140 objects Traceback (innermost last): File /Users/zope/zope2/lib/python/ZPublisher/Publish.py, line 150, in publish_module File /Users/zope/zope2/lib/python/ZPublisher/Publish.py, line 114, in publish File /Users/zope/zope2/lib/python/Zope/__init__.py, line 159, in zpublisher_exception_hook (Object: dv) File /Users/zope/zope2/lib/python/ZPublisher/Publish.py, line 102, in publish File /Users/zope/zope2/lib/python/Zope/__init__.py, line 173, in commit File /Users/zope/zope2/lib/python/ZODB/Transaction.py, line 234, in commit File /Users/zope/zope2/lib/python/ZODB/Connection.py, line 346, in commit (Info: (('Products.DataView.DataView', 'DataView'), '\x00\x00\x00\x00\x00\x00A', '')) UnpickleableError: (see above) Alternately, if I try to return the result from my product to DTML and then use that in a dtml-in, I get the same error. What is going wrong? Aparajita Victory-Heart Productions [EMAIL PROTECTED] www.aparajitaworld.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Only anonymous in an Access Rule?
Chris Withers wrote: How come getSecurityManager().getUser() returns the Anonymous User in access rules? Surely some checks must have been done to see whether the folder containing the access rule can be traversed to? If not, then huh? I'm confused :-( Access Rules trigger during publishing traversal, and authentication isn't performed until publishing traversal is complete. Until traversal is complete, Zope can't know which containers to check for User Folders. Also, publishing traversal only checks __roles__ on the last object in the traversal. This is very different than unrestrictedTraverse(), for instance, which checks permissions at every traversal step. This means that you can set security in a way that allows a user to access an object via ZPublisher that they could not access programmatically. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )