Re: [Zope3-dev] Workflow doesn't trigger IObjectModifiedEvent
Ivo van der Wijk wrote at 2005-5-8 11:34 +0200: I'm currently playing with a Workflow/Catalog mix, trying to index workflow states (so I can simply search for published content - a common usecase in CMF). However, it appears that workflow statechanges do not trigger IObjectModifiedEvent, to which the catalog subscribes to track changes and reindex objects. This might be workflow specific, it might also apply for all IAnnotable data (not sure). I think the interaction between annotation changes (among them workflow state changes) and the catalog is not yet well understood. There was a discussion some months ago about this, mainly between Jim and me. I proposed something like a DependentObjectModifiedEvent(dependentObject, primaryObject), deriving from ObjectModifiedEvent, as an efficient way to communicate with the catalog. The catalog could use primaryObject to determine the document id but dependentObject to determine a more narrow set of indexes that need to be updated. Jim proposed a set of alternative approaches. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote at 2005-5-11 11:18 +0200: ... indexing performance ... I agree, but perhaps we can find a compromise that fits all needs. I propose to use pluggable modification utilities. The container related events are already fired by only two functions (setitem and uncontained). If we introduce a third one for object modification (e.g. update or modify and an additional annotate if needed), we can replace these functions with callable utilities, which are responsible for performing the changes and firing the events. It's then up these components which events are actually used. Sounds good, but I am nevertheless convinced that we want finer grain control -- almost as fine (but probably with other means) as the idxs argument to catalog_object (which controls precisely which indexes should be reindexed). We will probably replace the selection of affected indexes with some interface related concept. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: What is modification, and why do we care? (was Re: [Zope3-dev] Missing ObjectContentModifiedEvent)
Jim Fulton wrote at 2005-5-27 10:45 -0400: ... You cannot make text extraction cheap (as it handles potentially large data). You can't make it cheap in all applications. For most applications, text extraction and comparison is very cheap. I'm guessing that you are refering to indexing large (book size) documents. I would argue that this is pretty specialized. No, I am speaking about a repository with office documents (letters, reports, drafts, documentation, ...) which apparently is not too rare at least in a Plone like context. And it is usually not the case that text extraction is expensive. I analysed last year text extraction from office documents. WVware extraction for documents in the order of 1 MB size took time in the order of seconds; OpenOffice text extraction in the order of 10 seconds (after optimization; standard - twice as much). Definitely, I do not like this time for any change in a metadatum or a workflow change. While a user accepts some seconds delays when he uploads large documents, he feels it unacceptable to wait for seconds when he performs e.g. a workflow action on such a document. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
Jim Fulton wrote at 2005-5-30 08:42 -0400: ... I suggest we generalize this a bit. I suggest that the ObjectModified event could accept one or more modification descriptions (hints?). Some examples: ObjectModifiedEvent(obj, IObjectFile) This says that we modified the objects file data. Note that an interface is an acceptable description. In fact, we might allow pretty muich anything as a description. ObjectModifiedEvent(obj, IObjectFile, Attributes(IZopeDublinCore, 'title', 'description'), ) This says we modified the file data and the DC title and description. This information would be a hint that subscribers could use, or not use as appropriate. We could change the form machinery in an obvious way to generate attribute descriptions. Dieter, I'm pretty sure that this would provide enough information for you to do the kind of optimizations you want to do. Sounds good! -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Choose-a-name strategy and write conflicts
Jim Fulton wrote at 2005-6-17 18:43 -0400: ... If people don't actually care about ids, you could generate them randomly. And the ZCatalog uses a scheme (choose random starting point in a thread, then allocate sequentially until a conflict occurs), which is supposed to work very well with BTrees conflict resolution. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] possible bug in catalog code
Jim Fulton wrote at 2005-7-7 06:55 -0400: ... [Martijn] The following sequence I think leads to trouble: value = getattr(object, self.field_name, None) if value is None: return None as this means attributes that do exist and have the value None would never be indexed (as index_doc() is never reached). ... [Jim] I'm not sure if this is a bug. If it is, the fix might be worse. It makes no sense and could cause problems to use None as a BTree-bases index key. AFAICT, Python still makes no guarantee wrt comparison of of objects of different types over time: The current Python falls back to order by type name and than by id. I do not expect this to change again. However, there is an additional reason not to put None into a BTree. Its interface has a weekness in its keys, values, min and max methods. E.g. in keys(min,max), min=None or max=None mean: no restriction. Therefore, they cannot distinguish between a None stored in the BTree itself and the use of None as no restriction. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Encoding of the PageTemplateFile
Dmitry Vasiliev wrote at 2005-7-12 18:19 +0400: Some time ago there has been a discussion on Zope3-Users list about specifying an encoding of the PageTemplateFile like this: browser:page template=tempalte.pt encoding=utf-8 ... / The encoding of a page template is an intrinsic property of the template itself and not determined by its use. This property should therefore not be specified in a configuration file (there is just a single correct value which must not be configured but kept fix). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Debugging deadlocks in Zope3
Garrett Smith wrote at 2005-7-24 17:36 -0500:
Is there any info published on debugging Zope3 deadlocks? I'd like to see
tracebacks of a couple threads. Has anyone done this w/Zope3?
threadframe might help a bit.
Florent used it to debug deadlocks for Zope2 (-- see its DeadlockDebugger).
It builds on ZServer. But probably, it will not be too difficult to
make something equivalent for Zope3.
Beside this, I debug deadlocks with GDB: attach to the process,
use info threads to learn about all threads, use thread t to
switch threads and bt to analyse the call stack of a thread.
In eval_frame call frames, I use pfr (defined as follows) to
determine the corresponding Python code.
def ps
x/s ({PyStringObject}$arg0)-ob_sval
end
def pfr
ps f-f_code-co_filename
ps f-f_code-co_name
#p f-f_lineno
lineno
end
define lineno
set $__co = f-f_code
set $__lasti = f-f_lasti
set $__sz = ((PyStringObject *)$__co-co_lnotab)-ob_size/2
set $__p = (unsigned char *)((PyStringObject *)$__co-co_lnotab)-ob_sval
set $__li = $__co-co_firstlineno
set $__ad = 0
while ($__sz-1 = 0)
set $__sz = $__sz - 1
set $__ad = $__ad + *$__p
set $__p = $__p + 1
if ($__ad $__lasti)
# break -- interpreted as breakpoint
set $__sz = -1
end
if ($__sz = 0)
set $__li = $__li + *$__p
set $__p = $__p + 1
end
end
printf %d\n, $__li
end
--
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Catalog improvements
Martijn Faassen wrote at 2005-8-25 13:49 +0200: ... AdvancedQuery ... I need to figure out the lazy sorting concept too and how to port it to the Zope 3 catalog... I see elsewhere in the thread you also mention it supports a simple form of joins, which is also very interesting. No, AdvancedQuery does not support joins. But, Python is a very powerful gluing language which allows you to implement simple joins yourself. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Performance Testing
Stephan Richter wrote at 2005-10-13 08:08 -0400: On Thursday 13 October 2005 07:02, Tarek Ziadé wrote: sub part: For zodb objects, i was wondering if we could somehow size what's beeing pickled, since it's just a buffer. we could therefore measure the size of what's beeing serialized in a test. that's a measure, but i wonder if it can tell something. I cannot see a use case for this. I would ignore this for now; there are bigger fish to fry. I saw some bad persistence modelling (in Zope2 land) where the granularity of persistent objects was badly chosen (either too small or (more often) too large objects). Watching out for such design flaws may be worthful. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] test errors due to ascii defaultencoding assumption
Tim Peters wrote at 2005-10-21 15:27 -0400:
...
[Dieter Maurer]
Nowadays, life is hell without a sensible setdefaultencoding:
Many isolated modules intersperse unicode in an otherwise
string dominated world causing wide spread
UnicodeDecodingErrors.
[Tim]
And setdefaultencoding helps that? What, you set it to latin1 just to
squash the exceptions?
[Dieter]
No, because I know that I live in a latin-1 subworld and that
almost all strs containing text (rather than binary data)
*ARE* indeed latin-1 encoded.
[Tim]
Br, if so. I suppose that's got a
decent shot at working by accident, anyway.
[Dieter]
Up to now, I met a single non accident (you would add wink),
i.e. a single case where the defaultencoding = 'latin-1'
proved counter productive:
Python's xmlrpclib tried to check whether it should
convert the unicode data to an str with code like this:
try:
# try to return a simple 7bit string
return str(data)
except UnicodeError: return data
Of course, this code only works as expected
when defaultencoding == 'ascii'.
The XML-RPC called function would have correctly worked with Unicode
and with an UTF-8 encoded str -- but it failed for a
latin-1 encoded str.
This problem was easily fixed by fixing the xmlrpclib code
(return data.encode('ascii') rather than return str(data)).
On the other hand, my defaultencoding = 'latin-1' saved me
dozens (if not hundreds) of UnicodeDecodingErrors).
Thus, your accidents are appreciated incidents :-)
--
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] __init__.py interfaces.py guidelines?
Jim Fulton wrote at 2005-11-21 09:43 -0500: ... A Python convention is that a leading underscore indicates privateness. - what about import paths inside a same package: relative or absolute? from mypackage.interfaces import ISomeInterface or: from interfaces import ISomeInterface Absolute always. Until the Python import mechanism is fixed, *always* use absolute imports. But, this will make refactoring (moving modules around in the package hierarchy) more difficult. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.application.HTTPPublicationRequestFactory interprets text/xml requests as XML-RPC (was: [Zope] Hard-coded Content-type:text/xml as xmlrpc in Zope (2.8.1))
John Ziniti wrote at 2005-11-21 15:04 -0500:
...
Zope-2.8.1 now additionally has the zope.app.publication.
HTTPPublicationRequestFactory class, which also assumes
that text/xml means xmlrpc (in fact, it assumes that
anything that startswith('text/xml') is an xmlrpc call).
zope.app is part of Zope 3.
You should complain about this misfeature on zope3-dev@zope.org.
Definitely, there should not be a fixed (not configurable)
association between text/xml requests and XML-RPC
as text/xml can be interesting for the application and
for SOAP.
Not fixing old code which acts in strange hard-coded ways is
something I understand, but adding new code that also
acts that way seems like it is getting further away
from good :)
--
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.testbrowser and mechanize
Stephan Richter wrote at 2005-11-28 08:02 -0500: ... If people would use the mechanize objects, their test code could not be converted to tutorials. Then some test could not be converted to tutorials... Is that really worse than being unable to test quite interesting use cases (such as file uploads)? I have the opposite feeling... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: rdb: Disappearing Connection
Jim Washington wrote at 2005-12-13 21:40 -0500: ... Now, looking closer at the code, a ping like this might be not too bad, because isConnected() is only called when a connection is requested, not for every SQL statement executed. So, it might not be so onerous as originally thought. Still not ideal, though. Be careful what you do when you find that isConnected() returns false. Note, that, in general, it would be a bug to just reopen a new connection in this case: previous operations against the connection might have been lost without notice when you simply reopen a new connection and do as if nothing bad had happened. Instead, you should reopen the connection and then raise an exception similar to ZODB.POSException.ConflictError. Hopefully, the publisher will handle this kind of exception correctly (by retrying the complete request). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: rdb: Disappearing Connection
Jim Washington wrote at 2005-12-16 16:23 -0500: ... What seems to work for me now is the following as mysqldbda.adapter.MySQLdbAdapter.isConnected() def isConnected(self): try: self._v_connection.ping() except: # not connected or ping did not restore MySQL connection if self._v_connection is not None: self._v_connection.close() self._v_connection = None return False return True I am not well-versed in the intricacies of conflictError, so what else should happen here? I do not see how there would be unresolved transactions remaining, and the connection I need is now available or soon will be established. isConnected is fine as you cite it above. However, the action taken (by the caller) when isConnected returns False might be wrong. Reopening and then using the connection in this case is safe only when the connection was not yet used before in this same transaction. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] attr name space (was: RFC: abolishing python: expressions)
Alexander Limi wrote at 2005-12-30 11:22 +0100: ... One of the ugliest and most error-prone parts of TAL is its handling of multiple attributes: a tal:attributes=href some/url; title some/title; / Why is this more ugly or error prone as your proposal? ... This provides the following benefits: - Easier to parse for XML tools (no semicolons with any meaning) For the XML tools, the semicolons are just part of an attribute value. They do not have any problems with them... - More consistent syntax, no need to learn a special way to separate several attributes/defines Learning that ; separates assignments and that ;; escapes seems not to be a big burden. - It looks nice! :) For me, it does not look nicer than what you want to replace. What do y'all think? -1 -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Jim Fulton wrote at 2006-1-3 14:41 -0500: ... I think 12 months is a bit short. I don't think the backward-compatibility code is that burdonsome, once written. What do other folks think? If the backward compatibility period gets shorter, we will skip more and more releases because of the increased burden to get our applications running again... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Tim Peters wrote at 2006-1-4 14:51 -0500: [Dieter Maurer] If the backward compatibility period gets shorter, we will skip more and more releases because of the increased burden to get our applications running again... Well, every new release will remove features deprecated N releases ago, where N is presumably some constant whose value is being debated here. That will be so in steady state whether N is 1 or 10 (i.e., the value of N doesn't really matter to that): the pressure to recode (and your temptation to skip releases) is related more to the frequency of releases than to the length of the deprecation grace period. In fact, whether I upgrade or not depends on the merits of the new version (with respect to that currently used) and the effort necessary for the upgrade. You are right that the (long term) average number of features removed in a given release depends on the time between releases but not the length of the deprecation period. However, a long deprecation period allows to cluster the renewal work. If the deprecation period is e.g. 4 releases, then I can 3 times upgrade without to worry about deprecations if I am ready to resolve all deprecation problems in the 4 th one. This increased clustering gives more flexibility to do the renewal work at times when projects are not to heavily pressing. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Benji York wrote at 2006-1-4 14:22 -0500: Dieter Maurer wrote: Jim Fulton wrote at 2006-1-3 14:41 -0500: I think 12 months is a bit short. I don't think the backward-compatibility code is that burdonsome, once written. What do other folks think? If the backward compatibility period gets shorter, we will skip more and more releases because of the increased burden to get our applications running again... Does that mean that you think 12 months is too short, just right, or nearly too short? I answer here as a user (of the Zope[3] framework) not as a (framework) developper. As a user, I prefer the deprecation period to be as long as possible. I cannot dictate the developpers what deprecation period they choose but I can refrain to upgrade. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Zope 3 startup message
Rocky Burt wrote at 2006-1-18 23:13 -0330: Marius Gedminas wrote: * I can copy the URL and paste it directly into a browser * I can right-click on the URL, and choose Open in web browser from the popup menu that GNOME terminal gives me. What do you think about changing Zope 3 server startup messages to show URLs instead of separate hostname/port lines? +1 ... but can we have it in Zope 2 too? :) You are aware that Zope has lots of servers? The message should at least identify which server was started... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: ZConfig and other formats for ZCML
Paul Winkler wrote at 2006-1-20 10:26 -0500: ... Does this mean we could potentially change zconfig options at runtime? What do you mean by that? You can already now change zconfig options at runtime (you can modify the object returned by getConfiguration()). But usually, it will have little effect, because most configuration options are read just once -- during startup. For them, later modification will have no effect. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] December release post-mortem
Martijn Faassen wrote at 2006-1-19 19:37 +0100: ... I'm talking about a Zope 2 release including (most of) what's in a Zope 3 release, so that Five developers can work on exposing *that* in Zope 2 too (which can then be part of the next Zope 2 release as we integrate the newer Five in it). I very much like Jims idea: having a small core with the ability to add separately released extensions on demand. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: ZConfig and other formats for ZCML
Martijn Faassen wrote at 2006-1-23 18:27 +0100: ... For one, ZConfig is a syntax not very well known, even granting its similarity to the Apache configuration language, while XML is very well known. Come on: The only syntactic part of ZConfig is: there are keys with values and sections (which may contain subsections and keys with values). This is almost identical to the syntactic part of XML: the keys correspond to attributes and the sections to elements. In both cases, the difficult parts do *NOT* lie in *SYNTAX* (which is trivial in both cases). The difficult parts lie in the available sections/elements with their keys/attributes and subsections/subelements and what this all means (i.e. their semantics)... What I like with ZConfig is its schemas and especially the ability to define datatypes. I hope that similar things can be achieved with ZCML. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: ZConfig and other formats for ZCML
Fred Drake wrote at 2006-1-23 09:56 -0500: On 1/23/06, Chris Withers [EMAIL PROTECTED] wrote: As I said earlier, I think XML is wrong for configuration for exactly this kind of reason... element-based is right for this type of config, it's why Apache uses, it's why Zope 2 uses it, and it's why Zope 3 uses it for the .conf file... There are no elements in the ZConfig configuration language. Sections, yes, but as has been noted, those don't trivially map to XML elements. Really? What prevents you to map ZCML elements to ZConfig sections and their attributes to ZConfig keys? Only for #PCDATA, there is not equivalent in ZConfig. But, almost surely, ZCML does not use #PCDATA... I have the feeling that mapping ZCML syntax onto ZConfig syntax is easier than the other way round (as ZConfig supports multikeys but XML allows only a single attribute of a given name). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Deploying WSGI Apps with Zope 3.2+
Stephan Richter wrote at 2006-1-26 10:16 -0500: On Thursday 26 January 2006 10:04, Jim Fulton wrote: Every change I've ever been involved with has been extremely painful. I can't even explain well what made it painful because I didn't really understand what was going on and needed help from Fred. Maybe someone would make the same comment about ZCML, although I've had a lot of positive feedback on the ZCML extension mechanisms. shrug/ Extending ZConfig is tough Chris and me find it easy... but ZCML meta directives and schemas are so easy to use. I do not yet know ZCML... When I have read your book I was scared away from ZCML by the amount of namespaces and directives -- in addition that I do not like the XML hype (that part that seems to imply that as soon as something is XML it is also easy and well understood). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing environment and configuration
Jim Fulton wrote at 2006-1-25 17:26 -0500: Sidnei da Silva wrote: In Zope 2, we had excess of configuration options and environment variables. How did you have access to configuration options? from App.config import getConfiguration; config = getConfiguration(). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Deploying WSGI Apps with Zope 3.2+
Florent Guillaume wrote at 2006-1-26 12:57 +0100: ... I thought Tres had added to ZConfig the possibility to have arbitrary key/values for arbitrary additional products. Or was this only in the context of Zope 2 ? It is essentially the %import package extension of ZConfig. It allows package to define its own sections types. Almost surely, %import is already available in the ZConfig version for Zope 3. The additional piece necessary is a placeholder in the schema itself consisting of a multisection of some abstract type. To define package specific extensions, the package can implement this abstract type. This part might not yet be in the Zope 3 schema. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Deploying WSGI Apps with Zope 3.2+
Martijn Faassen wrote at 2006-1-27 13:21 +0100: ... Five actually adds a 'five' namespace, which I think is very useful -- it clearly marks which directives are only there for Zope 2 and thus you cannot expect them to work in Zope 3. Not having namespaces would make this a lot harder to mark, and the temptation would exist to mangle namespaces into the names by using prefixes and the like. I think that is the major complaint: the need to associate an easy to remember and (in a restricted context) completely sufficient prefix (like five:) with a horrible URN, you always have to look up. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
Stephan Richter wrote at 2006-2-3 12:45 -0500: ... declareSite name=mysite / site name=mysite / !-- normal directives here. -- /site The declareSite looks redundant. I see at the site name='mysite' element that a site with name mysite is declared... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] visions, brands and roadmaps in the sand
Martijn Faassen wrote at 2006-3-2 18:44 +0100: ... I worry about losing brands we've worked on hard to establish. While many people do not understand the difference between Zope 2 and Zope 3, many others have heard about Zope 3 and they know it is not Zope 2. I do not understand the loss of brands fear... MS renames its core technologies every few years (at least) and nevertheless, it has a surprising market success... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] visions, brands and roadmaps in the sand
Lennart Regebro wrote at 2006-3-2 20:39 +0100: ... 2. Zope3 may also get slightly streamlined, so that Zope3 is what is needed to run Zope2 but not more. That means that Zope3 would lose the ZMI. I would consider this a severe loss. The ZMI provides menu guided operations. This is much easier that to work with configuration files and API's -- especially for casual users. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-Users] Re: [Zope3-dev] Visionaire! (All your problems, solved)
Martijn Faassen wrote at 2006-3-3 18:13 +0100: Martin Aspeli wrote: On Thu, 02 Mar 2006 11:49:31 -, Lennart Regebro [EMAIL PROTECTED] wrote: This should be Zope3 as it is now. A couple of things can go away. Maybe the rotterdam skin, I don't know. Definitely the default Folder objects and such. People, especially Zope2 people, think that you are supposed to use them. You aren't, you are supposed to build your own. Yeah, why the hell are there there then? ;-) I like the default Folder objects and use them. Building your own is a waste of time if they do exactly what you want. Windows, Windows 98/NT/ME/CE/2000/2003/XP, I hear of Avalon/Longhorn as names for future .Net based Windows versions. Similar (although not that many) variations for Office (Office 98/2000/2003). You can find drastic changes in the technology names (rather than the product names): e.g. COM, OLE, ActiveX, COM+ -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Use ConfigParser for High-Level Configuration
Philipp von Weitershausen wrote at 2006-3-7 01:16 +0100: Dieter Maurer wrote: ... While ZConfig allows you the describe related material together and without indirections, the ConfigParser format forces you to introduce indirections and to spread related definitions over a longer area. Yes, this was my concern with it, too. Though the decouple spelling obviously also has advantages as you can configure a server once and then just refer to this server configuration from several instance configuration. Sure. Fortunately, you can get it in ZConfig, too -- if you need it -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration
Fred Drake wrote at 2006-3-6 14:16 -0500: ... When Tres and I added this, we planned specifically to see how it was received by the Zope 2 community. At least, I like it. ... That said, I don't think Jim's concerns are limited to the Zope configuration schema, but extend to configurations that do not necessarily involve the Zope application server at all. But, you can easily add a hook like this to any schema. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration
Jim Fulton wrote at 2006-3-11 18:03 -0500: ... Where is this documented? I do not know. I saw a feature description in the mailing list. Fred and Tres (the authors) should be able to tell you whether there is a formal documentation and where you can find it. Let's pursue this a bit. Would it be possible to write a configuration file that loaded it's own schemas? Yes -- with some restrictions: as I described in my previous mail. The feature essentially works as follows: You have an abstract section type in your primary schema, usually usable in a multisection. Examples: ZServer server, ZODB storage, the general extension abstract section type In your module/package, you define your own section type implementing the abstract section type in its component.xml. You are completely free in its keys and subsections. In the configuration file, you import your module/package (which makes available the definitions in its component.xml) and instantiate one or more of the section types defined there. Your application/module looks for the sections of its type and uses them. The restriction: you cannot have new keys on the top level -- all must be nested in a section type defined by your component.xml. But, this, I consider an advantage (ZConfig here behave similar to a ConfigParser approach). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Martijn Faassen wrote at 2006-3-13 17:15 +0100: ... A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. I believe that this interpretation is the up-and-coming interpretation of ZCML. I hope not... Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration
Jim Fulton wrote at 2006-3-12 15:54 -0500: Dieter Maurer wrote: Jim Fulton wrote at 2006-3-11 18:03 -0500: ... Where is this documented? I do not know. I saw a feature description in the mailing list. Fred and Tres (the authors) should be able to tell you whether there is a formal documentation and where you can find it. Let's pursue this a bit. Would it be possible to write a configuration file that loaded it's own schemas? Yes -- with some restrictions: as I described in my previous mail. The feature essentially works as follows: You have an abstract section type in your primary schema, usually usable in a multisection. Examples: ZServer server, ZODB storage, the general extension abstract section type In your module/package, you define your own section type implementing the abstract section type in its component.xml. You are completely free in its keys and subsections. In the configuration file, you import your module/package (which makes available the definitions in its component.xml) and instantiate one or more of the section types defined there. Your application/module looks for the sections of its type and uses them. The restriction: you cannot have new keys on the top level -- all must be nested in a section type defined by your component.xml. But, this, I consider an advantage (ZConfig here behave similar to a ConfigParser approach). So the example I gave won't work. In a schema, I have to have an abstract type for each thing I might want to add. But I don't know what I want to add. This doesn't sound very extensible. You can have a *SINGLE* abstract type -- fixed for any extensions you may imagine and use this as the hook in your component.xml. Such a single abstract type was added to the Zope schema to make almost arbitrary extensions possible. I can't fathom the ZConfig documentation so I don't really know what an abstract type is. It is essentially a name, which can be used at various places in your schema and implemented at other places in different ways. I don't know how restrictive it has to be. Can I define an abstract type that matched anything? Yes. I even think you currently cannot impose restrictions on the sectiontypes claiming to implement the abstract type. Can I define a schema that just defines an abstract type that matches anything? I think you must also use the abstract type in a section/multisection definition. But that would be all. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Roger Ineichen wrote at 2006-3-13 21:57 +0100: ... I think ZCML is defently not configuration in the clasic understanding of configuration. Defining directives in ZCML means we bind components together to a application. If developer share this configuration layer with admins and use it for tasks like configuring a mail queue (like we do right now) I'm sure we will get a big mess for admins and developers understanding of what ZCML should be. Why do we need ZCML for this? It can be done with Python equally well... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Sidnei da Silva wrote at 2006-3-13 20:21 -0300: ... That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. As I understand, no other framework out there gives you this. Aspect orientation does this: Use a given unprepared implementation and add all kinds of aspects to them: logging, tracing, persistence, additional checks -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote at 2006-3-14 07:23 -0500: ... * Setting up the indexes in a catalog. definition Really? I would consider it configuration -- even high level configuration. ... BTW, a general thing to keep in mind: - Indirection and abstraction are inherently bad because they hide things. :) (This is a corolary of explicit is better than implicit.) I do not agree with this (but I also do not agree with explicit is better tham implicit -- almost all activities would become drastically more difficult if they could only be done explicitly: walking, driving, eating, ... I am very happy that most things, in real life and in programming work implicitly and on an appropriate abstract level). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Lennart Regebro wrote at 2006-3-14 09:19 +0100: On 3/14/06, Sidnei da Silva [EMAIL PROTECTED] wrote: That is, to me, a very important feature. To be able to write some python module that does not depend on Zope 3 at import time, but is 'hooked into' Zope 3 externally, with ZCML, at 'configuration time'. Why is that important? In most cases you would have to write interfaces for the non-z3 python objects. Assuming you don't actually write them, but cheat and just mark them, you can get away with this, sure. But is it really that hard to write a small wrapper class instead? And you can use Python, too, to mark them: You import the class and call an implements for it. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Lennart Regebro wrote at 2006-3-14 21:17 +0100: On 3/14/06, Dieter Maurer [EMAIL PROTECTED] wrote: Aspect orientation does this: Use a given unprepared implementation and add all kinds of aspects to them: logging, tracing, persistence, additional checks Yeah. And that aspect orientation is in Zope3 done in ZCML... So I don't really know what you are trying to say here. :-) I reject Sidnei's claim Zope3 were unique in this respect (apart from using ZCML, of course) :-) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote at 2006-3-15 07:29 -0500: ... Magic always has the downside that it hides things. Often, as in the case of garbage collection, the benefit outweighs the cost. Too often though, people introduce magic (aka abstraction, indirection, automation) when the benefit doesn't justify the hiding. One should always approach magic with skepticism. Neither costs nor benefits are objective but subjective. For me, when I repeat the same sequence for about half a dozen of times, I am crying out for an abstraction (if possible with a well chosen name) that gets rid of the repetition. I am rarely interested in details and am happy when lots of them are hidden -- that's no cost but benefit. Well chosen names give me enough feeling about the overall effect that I rarely need to dig into the details. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: what is ZCML?
Jeff Shell wrote at 2006-3-15 14:26 -0700: ... Anyways, I don't mind if someone wants 'browser:addform' as an add-on. But I don't think those things belong in the core. If someone wants to make a package that lets them build a web site using nothing but ZCML to glue a bunch of crap together! then lets have it. But not in the core. It's limiting. It's restrictive. The bit that it makes hard is the bit that most people get to at some point in the lifecycle of their web application. Why make them switch paradigms at that point? Maybe, because until that point it made life easier? I am very happy to use high level abstractions (provided they have well chosen names -- browser.addform seems quite good -- and a clear semantics) and start only to dig deeper when necessary. I treat a car as a black box with a well defined set of functions. Only when I reach the limits, I search deeper and may learn that there is a motor that can be tuned... ... That makes the integrators job much harder. If browser:view, browser:page, and zope:view all went away today in favor of subclassing from formlib.Page, BrowserView, or something else common that provided the core full-view-page pieces (publishTraverse, browserDefault, __call__) and only zope:adapter was used as the ZCML directive, it would be much easier (I think) to start providing views that can be better augmented by integrators. (Besides, I think 'integrators' are better served by the programming language. Anyone who thinks they can just download a bunch of random components and build a unique web site with nothing but XML is deluding themselves). Things I agree with... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration
Stuart Bishop wrote at 2006-3-20 10:38 +0700: Also, there is only one schema.xml so multiple components can't each insert their own blob of configuration information into the global schema. Please read From: Tres Seaver [EMAIL PROTECTED] To: zope3-dev@zope.org Subject: [Zope3-dev] Re: httpgz in zope.conf? Date: Mon, 20 Mar 2006 09:53:52 -0500 There, you will learn that components don't need to insert anything into the global schema but can put these things into their local components.xml. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Google SoC Project
Jim Fulton wrote at 2006-5-9 07:22 -0400: ... Finally, there's a lot of interest in generating configuration actions in Python, rather than ZCML. I suspect that avoiding XML processing, conversion, and validation might speed startup quite a bit. Moreover, if the component performs is own reregistration on reload, the Z2 refresh may be possible as well. We use the Z2 refresh all the time and are very satisfied. Of course, with a component (i.e. Product in Z2), all dependent components have to be refreshed as well. We do this with a little tool of ourselves. With a decent dependancy spec, almost all refresh behave as expected. ... I'm really not interested in a reload faclity, like the one commonly used in Zope 2, that is not robust. I've wasted too many hours helping people debug problems that were caused by reload misshaps. I hear of very few problems here. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re[2]: [Zope3-dev] Re: Google SoC Project
Adam Groszer wrote at 2006-5-9 14:36 +0200: ... [snip] JF Python simply does not support a general robust reload, other than JF restart. [snip] What about pushing the problem then to the lower level, to Python itself. I think all developers are fighting the same problem, so all Python developers would benefit from the solution. As I know (that may be wrong) not many even if any language supports that, so that would make one big plus point on the Python side also. I fear, this is a very deep (and difficult) problem! A reload may modify an object that is used in arbitrary places. and Python may not know all these places... Because of this, Python has only two options: * it creates a new object and leaves all using contexts alone. That is what Python does now. * it overwrite the object in place. But for many modifications this is impossible (e.g. if the new object needs more contigous space then the old one). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] TALES PathExpr doesn't call old style classes
Philipp von Weitershausen wrote at 2006-5-23 17:02 +0200: ... callable() isn't even deprecated yet, so if it solves our problem, we can use it IMO. Note that Zope 3 deliberately doesn't use it because of the proxy problem. Zope 2 works around that by stripping proxies/wrappers first (ob.aq_base). Perhaps Zope3 should do that as well. Would callable(removeAllProxies(obj)) be harmful in any way if you end up calling the proxied obj() anyway? At least earlier, callable had a problem: some objects where apparently callable but calling them resulted in AttributeError: __call__. That's why cDocumentTemplate grew a safe_callable. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] TALES PathExpr doesn't call old style classes
Dmitry Vasiliev wrote at 2006-5-23 17:06 +0400: ... PEP-3100 suggest just call the object and catch the exception instead of use callable(). So maybe we can write: try: ob() except: pass return ob Unfortunately exceptions still will be masked. Yes, and therefore *NEVER* do this. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: TALES PathExpr doesn't call old style classes
Philipp von Weitershausen wrote at 2006-5-24 18:16 +0200: ... Yup. We could think about this for some future release cycle, though. I'd very much be in favour of making nocall: the default and introduce something like call:. Then sniffing for callableness wouldn't be necessary. You are aware how many templates you would break? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] selecting the translation domain in ZCML
Jean-Marc Orliaguet wrote at 2006-5-30 12:01 +0200: ... although -- while thinking about it, putting the domain name in .po files breaks the separation on concerns between translators and application developer. Translators shouldn't have to worry about translation domains. That's application specific. Are you sure? In my view the translation domain is vital for translators -- as the domain guides the correct translations. For example, in German we have the word Bank. It may mean bench or bank, depending on the translation domain. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] selecting the translation domain in ZCML
Jean-Marc Orliaguet wrote at 2006-5-30 22:13 +0200:
...
Dieter Maurer wrote:
...
In my view the translation domain is vital for translators --
as the domain guides the correct translations.
...
But it is the application that eventually sets the domain name to use,
based on the context. Translators have no control over it, since they
have no control over page templates or over python code.
You are right, of course: translators do not chose the domain
but are informed about it. However, this does not contradict
that the translation domain is specified in the .po file -- as
the translations in this file are only valid in the
translation domain for which they have been made...
...
My view is that the translations can still be stored in different
folders (one per translation context as you mentioned) and the domain
can be set in ZCML during the configuration of the application for an
entire folder, globally.
I do not disagree.
Hence, the translators are only concerned with putting translations into
folders ('business_terms', 'furniture', ...), no matter what the domain
name will be called.
But why would you want a different domain name than that communicated
to the translators? Do you prefer meaningless over strong names?
--
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 FreeBSD tmiddleton
Tim Peters wrote at 2006-6-17 14:50 -0400: ... The problem arises because what _Python_ calls int is what C calls long, but the I-flavor BTree code stores C int, and C int doesn't correspond to any Python type (except by accident on 32-bit boxes). Why not simply change this, i.e. let BTree use what Python calls an int (i.e. a C long). Of course, we need to be a bit careful, when we load pickles. They might have been written by applications with a longer C long than we have. But, this problem we have anyway (independent of BTrees). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] session state issues
Roy Mathew wrote at 2006-7-11 17:36 -0700: I have what seems to be an odd problem with persistence of information in simultaneous sessions. I keep track of an iterator in an object that is persistent (one instance per-session). The iterator is updated as the user navigates a sequence of objects. The iteration seems to work fine for a single user. If 2 users A and B access the system simultaneously, each users navigation is occasionally thrown off (ie: the session seems to lose track of the iterator state). Iterators can get seriously confused then the object iterated over changes. Maybe, this is your problem? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: OT: pytz
Florent Guillaume wrote at 2006-8-5 00:17 +0200: Stuart Bishop wrote: ... I've been wondering if making pytz work like this was a correct decision. It seems that people who know enough to care about DST transition periods generally work in UTC anyway What makes you say that? Any application where datetimes are user-entered and user-visible will certainly *not* want to store them in UTC, as users will want dates displayed as they were entered (meaning holding their original timezone, even if the timezone is not displayed). *nix recommends to store the time in UTC (in the hardware clock). Nevertheless, users see and can enter the time in their local timezone. This demonstrates that the storage format can be independent of what the user sees or enters... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: OT: pytz
Florent Guillaume wrote at 2006-8-7 12:53 +0200: On 5 Aug 2006, at 22:38, Dieter Maurer wrote: Florent Guillaume wrote at 2006-8-5 00:17 +0200: Stuart Bishop wrote: ... I've been wondering if making pytz work like this was a correct decision. It seems that people who know enough to care about DST transition periods generally work in UTC anyway What makes you say that? Any application where datetimes are user-entered and user-visible will certainly *not* want to store them in UTC, as users will want dates displayed as they were entered (meaning holding their original timezone, even if the timezone is not displayed). *nix recommends to store the time in UTC (in the hardware clock). Nevertheless, users see and can enter the time in their local timezone. Unix has nothing to do with an application manipulating proper calendaring concepts. The original timezone information can be quite important, and the local timezone of the user seeing the information may not be the appropriate one. This demonstrates that the storage format can be independent of what the user sees or enters... Provided all you want is store an instant in time. Which is only a limited subset of what can be useful in general. A look at iCal (RFC 2445) shows that you can either use UTC (maybe with a tacit knowledge about the timezone of the location the calendar event applied to in order to get its local time) or explicitely use the TZID parameter (such that an interesting interpreter can convert to UTC). Only when you give the timezone an implicit (!) meaning (e.g. it's the timezone applying to the location of the event) you get more than with UTC alone. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: New beta releases tonight
Philipp von Weitershausen wrote at 2006-8-13 23:09 +0200: ... forker.shutdown_zeo_server(adminaddr) File src/ZEO/tests/forker.py, line 182, in shutdown_zeo_server s.connect(adminaddr) File string, line 1, in connect error: (22, 'Invalid argument') Looks as if adminaddr where not a tuple consisting of a string and an integer. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3c - be or not to be
Roger Ineichen wrote at 2006-8-25 18:27 +0200: ... The reason why; We really have no time to do this in the next couple of month. And the option sombody else doing it is also *NO* option because we have allready productive projects build on this libraries and have no time to migrate them for nothing. Yes renaming the z3c namspace whould technicaly possible, but for me(us) it's just a waist of time right now. Could be that I will change my mind in the future but not in the next couple of months. I have no opinion on namespaces (especially, whether or not z3c should be renamed). But technically, it would be extremely easy: If nothing else would change than the top level name, then a single module alias (e.g. sys.modules['z3c'] = zorg) would suffice to let all existing software work as before. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Tres Seaver wrote at 2006-9-2 13:03 -0400: ... I'm OK with having in-tree code not use zapi, but I don't see a win in propagating all the mess out to the rest of the world. I'll also note that janitorial deprecation is way too common in the tree today: people decide they don't like the name a method was given, and deprecate it in favor of the better name. The ongoing cost of that deprecation is then borne by everyone else. I have the feeling that almost the complete Python community is abusing deprecations. I was hit by deprecations in the email package: The deprecation told me to use a different method, but this method was not a full replacement for the old one and failed in my use case. In the next release, my old method was removed -- but fortunately, I know how to recreate methods and silence stupid deprecations. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200: ... I for one prefer exceptions over manual error handling. And I prefer straight-forward APIs over unnecessarily complicated constructs. But you probably would not prefer if these straight-forward APIs were continously changing. I prefer a slightly suboptimal stable API over one that is optimized in each version in a non backward compatible way. I do not want to say that this is happening in Zope3 land. I do not yet use Zope3 in earnest and see what is happening more from the mailing list than from my own experience. So, for me, it would be great if developers would take more time to weigh up the what does this new feature or refactoring bring against the how much of a PITA is it going to be for everyone else to relearn this... I like new features but often could not see the gain of refactorings. Many refactorings in Zope 2 land were just silly, e.g. whitespace refactoring such as: from X.Y.Z import a, b, c refactored to from X.Y.Z import a from X.Y.Z import b from X.Y.Z import c I do see the gain of moving out general purpose functions from zope.app into zope. But, I would do it in a backward compatible way -- even when zope.app then contains quite a few trivial packages redirecting to the relocated packages. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 as a reliable platform?!?
Stephan Richter wrote at 2006-9-5 08:36 -0400: On Tuesday 05 September 2006 08:26, Jim Fulton wrote: I think in the future, we should resist minor api tweaks just to improve spelling slightly. I disagree, if the API violates the style guide. If only after the API is in widespread use, a style guide violation has been noticed, then the violation cannot have been that severe. Otherwise, someone would have noticed it earlier. Often, style is a very personal matter. What some individuals feel as a violation may not worry other individuals. API changes should have the large part of the community in mind. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 as a reliable platform?!?
Fred Drake wrote at 2006-9-5 10:50 -0400: ... Hmm. The Z3 style guide has never matched the Python style guide completely, and I think it would do more damage than good to change it. We adopted some things early on in Z3 development that I think helped, but changing it just because more is covered in the Python style guide seems arbitrary. When I remember right, then I read an important sentence in the Python style guide -- something along the lines: This is a guide: you should follow it but there are occasions when you may not do so with good reasons. That's what a guide is: a set of rules recommended to follow, not a lawbook to follow in all cases. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 as a reliable platform?!?
Fred Drake wrote at 2006-9-5 15:03 -0400: On 9/5/06, Dieter Maurer [EMAIL PROTECTED] wrote: When I remember right, then I read an important sentence in the Python style guide -- something along the lines: This is a guide: you should follow it but there are occasions when you may not do so with good reasons. I don't know if this means you agree or not. I agree that we do not need to adopt the Python style guide for Zope3 development. I don't think this paragraph really applies to this discussion. Jim suggested that we change the Z3 style guide, and I'm suggesting that that's counter-productive. But, if some component (such as formlib) entered the Z3 core and it follows more the Python style guide then the Z3 style guide, then this would not mean we have to change this component's API (just to get it more in line with the Z3 style guide). I think this openess was what Jim suggested (and I agree with) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.2 maintenance
Hanno Schlichting wrote at 2006-9-11 23:06 +0200: ... You got it backwards ;) I only forward-port any changes from older branches to the more recent ones, but never do any backports. The reason I do this is because before this, Plone developers tended to only fix a bug on the trunk or the latest stable release. My hope was that by lowering the bar by only requiring developers to fix a bug on the oldest maintained release branch, more people would actually do this and in fact I think this strategy has worked out. This works in conjunction with our quite well-maintained bug-tracker where bugs get assigned to the release they should be fixed in by a small group of people. A very good approach! Because all modifications done on released branch should be fixes only, we want almost all of them in the trunk as well. And there is a good chance that there will only be few merge conflicts. Unfortunately, I could not convince my colleagues to work this way -- despite a good practical experience. One argument has been: the Zope development does not use it... But two things to keep in mind that differentiate Plone from Zope3 in this regard are, that most of the fixes in Plone are template issues or minimal changes that apply cleanly on the newer branches and when they don't or I do not understand them I ask the bug fixer to forward port it. You can of course do this always. ... For Zope3 the only sensible option IMO is, as others already mentioned it, to have a fix-on-the-oldest-maintained-branch-first bug fixing policy which requires to forward port these fixes to all branches up to the trunk. Why are you that pessimistic about Zope3 -- once the moving around has stopped (which might be a challenge for automatic forward merging)? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.2 maintenance
Hanno Schlichting wrote at 2006-9-11 23:18 +0200: ... Yes. We don't have a Hanno for Zope 3. And even if there would be someone willing to do this job, a good understanding of most of the internals would be a prerequisite, as merging something which you do not understand is indeed potentially extremely harmful. The number of people that have a deep understanding of most internals of Zope3 is fairly limited and I think their time is better spent on fixing the bugs in the first place. I am merging Zope modifications into our locally maintained Zope version since about 1998. Lots of merges took place without me even knowing that something happened and without any need to understand things. Of course, there have been occational problems and then I had to get local understanding to fix things. In the Zope3 forward porting case, we can instead ask the fix author to do the port instead. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
Martijn Faassen wrote at 2006-9-12 11:25 +0200: ... On the one hand core developers seem to be happy to use the trunk for development projects, and on the other hand we demand a lot of work doing bugfixes in a release, up to the point where we delay the release itself. core developers probably have other means than simple Zope3 users. When you see some problems simple Zope2 users have, you may understand that they should not be bothered with bugs in addition... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Martijn Faassen wrote at 2006-9-12 14:44 +0200: ... The current CHANGES.txt from the trunk just lists one new feature (added by myself). That's does not deserve a major release. It's the nature of time-based releases, though. If nobody does anything in 6 months, does that mean we won't have a release at all? Of course! Why in hell should you make a release with nothing relevant in it? Both the release process are well as the upgrade process entail a considerable amount of work. You do it only if it is worth the effort. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release management refinements
Philipp von Weitershausen wrote at 2006-9-13 11:05 +0200: Over the last couple of days we've been discussing Zope's new release cycle and the release management. I would like to sum up what seems to be the gist of those discussions: 9 month release period? --- I am almost convinced that we will make the same experience as the Plone people: when we strive for a 9 month release cycle, we will get a 12 month cycle... I think this is almost a law for software development: completing in time is the exception not the rule. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [z3-five] zcml questions
Chris Withers wrote at 2006-9-25 18:44 +0100: ... Can we have a papal edict that zcml that has side effects is a bug? (including the dotted name thing...) Hm: the purpose of zcml is to have side effects (register things, patch classes with marker interfaces, add permissions, ...) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Python version for Zope 3.4 ?
Philipp von Weitershausen wrote at 2006-9-28 11:22 +0200: ... The last time this was discussed with Jim, the idea was to try to use Zope 3's security proxy approach in Zope 2 for Python Script security - Jim and I had some ideas I need to dredge up from the back of my mind. I am quite fearful in this regard: Lots of existing code rely on the fact that trusted code can do anything without to worry about security. As security proxies restrict trusted code, too (though trusted code can remove the wrapper), we might get more security at the cost of massive backward incompatibility. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Martin Aspeli wrote at 2006-11-9 04:37 -0800: ... Why does your class not have a (non-marker) interface in the first place? The use of interfaces as documentation and as formalisms for expressing a class' functionality (in adapters, utilities etc) is one of the benefits that Zope 3 introduces. I can see how they may not always add that much value immediately, but they are a good way of ensuring things are reasonably well-defined, well-documented and easily locatable. I have quite a different point of view: Interfaces define essentially the signature of methods but these signatures can also directly be derived from the class. Zope3 interfaces are slightly better as they can also specify attributes -- which is very helpful as Python does not provide a good means for this. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100: ... def myStrAdapter(something): return str(something) It instantiates a 'str' object. The 'str' object is the adapter for 'something'. Huh? This would be a severe terminology abuse: An adapter should adapt something to something else *BUT* an str object does not adapt anything (it does not operate on another object). 'myStrAdapter' is the adapter factory. In my view, *this* is the adapter (adapting something to str) and not an adapter factory (as its result is a string object which does not adapt anything)... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote at 2006-11-15 20:34 +0100: Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100: ... def myStrAdapter(something): return str(something) It instantiates a 'str' object. The 'str' object is the adapter for 'something'. Huh? This would be a severe terminology abuse: I agree, it's bending the terminology a lot. It wasn't me who came up with the 'str' and 'int' example. An adapter should adapt something to something else *BUT* an str object does not adapt anything (it does not operate on another object). Well, imagine str(123) '123' Here '123' is the 'str' adapter of the integer 123. It's conceptually the same if you do That's the terminology abuse: '123' is not an adapter because it does not do the adaption. '123' is the *result* of adapting 123 to 'str'. You may call '123' the 'str' adaption of the integer 123. IZopeDublinCore(myobj) except that in the str(123) case, you call the class directly instead of using the Component Architecture's registry as a flexible dispatch. With appropriate terminology use, you would call IZopeDublinCore the adapter and IZopeDublinCore(myobj) the ZopeDublinCore adaption (maybe adaptation) of myobj. Again IZopeDublinCore(myobj) is not an adapter but an adapted value. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote at 2006-11-15 21:11 +0100: ... Not sure what official terminology glossary you're basing this on I am basing this on the meaning of english words. An adapter is something that adapts (and not something that is adapted). adapt is a transitive verb. It applies to something. This means that an adapter, too, applies to something. It is a function. but we often refer to IZopeDublinCore(myobj) as the IZopeDublinCore adapter of myobj. I begin to understand where this comes from: In Chris' example, the adaption result is a string. It is very difficult to envision a string as an active object (what the name adapter suggests). In more complex situations the adaptation result is an active object that actively mediates between the interface it provides and the adapted object. This probably led to the use of the active term adapter rather than the more neutral term adaptation (maybe adaption). As Chris example demonstrates, it would have been better to call IZopeDublinCore(myobj) the IZopeDublinCore adaptation of myobj. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Jean-Marc Orliaguet wrote at 2006-11-15 20:51 +0100: ... but what problem is all this supposed to solve? are you guys writing a PhD or something .-) ? Well chosen terminology is a key to understanding. Therefore, it is justified to discuss about it. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re[2]: [Zope3-dev] Heads up: bugs in zope.app.catalog?
Adam Groszer wrote at 2006-11-17 13:13 +0100: What is the `good` behaviour regarding None values? Do we need to catalog them or skip them? If you index them, you rely on a non garanteed implementation artefact: Python explicitly does not garanteed that comparisons between objects of different type are persistent across restarts. The BTree variants used in the implementation of indexes require that the keys are persistenty compared. Failing to do so, will break the index. The current Python implementation ensures persistent comparison results. Thus, you are on the good side. However, earlier Python implementations did not and maybe future implementations may not, too It is safer, to have just a single key type in your indexes... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?
Chris Withers wrote at 2006-11-28 18:09 +: Benji York wrote: Chris Withers wrote: I don't think it'll be a common pattern, but it doesn't feel right to me that a named adapter (ie: one registered with a specific name) has no way of finding out what name it has been registered with... Because the same adapter can be registered more than once, it would actually need to find out all the names with which it was registered. Really? Now this is a use case I hadn't thought of.. can you give me some examples of where you've run into this? An example where an adapter *can* be registered several times was presented by yourself :-) The str adapter (factory) can be used to adapt anything to a string. You may register it several times because you may not want to adapt all interfaces with it but only those derived of several base interfaces. You may or may not use different names as you might have different types of string adaptation (e.g. different types of string presentations). The str example shows also that it is not sensible that the adapter registry framework gives the adapter (factory) a way to determine its name (str has nothing where the name could be sticked in). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Core topic in Collector
Jim Fulton wrote at 2006-12-14 07:21 -0500: ... Yawn. IMO, the collect, despite it's flaws, isn't bad enough to spend time on, especially given other priorities. OTOH, I'd be happy to just switch to using Launchpad, which would require basically no effort, especially if we don't bother transferring old collector data. It is not a good indication for striving for quality when problem data is taken out of sight... Of course, not transferring old collector data is less work, but so is not writing tests or documentation ;-) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Usage of IAnnotations disrespects interface declaration
Christian Theune wrote at 2006-12-11 08:30 +0100: ... Both are not acceptable, especially option #1. We can't just change existing contracts as we see fit. Right. However, I think it's possible to regard this is a bug in the original contract. But, some adapters for IAnnotations may not know about the newly introduced responsibilities and fail to implement them. Thus, fixing this bug in the proposed way will introduce bugs at other places. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Java applets and zope3
Paul Carduner wrote at 2006-12-12 22:59 -0800: ... load: class http://www.carduner.net/Programs/Fractals/Attractor.class not found. java.lang.ClassNotFoundException: http:..www.carduner.net.Programs.Fractals.Attractor.class ... at java.lang.Thread.run(Unknown Source) Caused by: java.io.IOException: open HTTP connection failed. Java tracebacks, too, are not so bad. As you can clearly see, the Java runtime tried to open an HTTP connection and failed. The reason is probably that it tried the wrong server. Use a TCP logger (e.g. EtherReal) to understand what the client does on the network level. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Fixing ZServer bugs?
Christian Theune wrote at 2006-12-19 10:06 +0100: ... Did we ever drop support for ZServer? The changelog reads 'replaced ZServer with twisted' which sounds very much like ZServer was defined obsolete. I have understood the discussions differently: As I understood ZServer should stay alongside twisted as it is much faster. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Jim Fulton wrote at 2006-12-19 17:27 -0500: Dieter Maurer wrote: Jim Fulton wrote at 2006-12-19 11:54 -0500: ... I made a mistake several years ago when I decided to (have Amos) implement FTP over ZPublisher. The Zope publisher is a CGI-inspired HTTP-based and thus stateless API. It is a poor fit for FTP and I overgeneralized. Why do you think so? Because FTP is a stateful protocol and HTTP isn't. Yes, but with a minimal state... I implemented a ZServer based NNTP server over ZPublisher within a few days -- and did not have the feeling that I need to stress ZPublisher. I don't know anything about NNTP. It is as stateful as FTP, having a minimal state, too. ... Instead, I was pleased that I could use authentication, request logging, request profiling, transaction handling, error handling -- all features either in core ZPublisher or added by us. One could still use and benefit from many of the frameworks in Zope without using ZPublisher. We moved from a (papercut based) dedicated NNTP server implemented as a ZEO client (the type of solution, you currently seem to prefer) over to a ZServer based NNTP server on top of ZPublisher. And we were very pleased with the transition: both with respect to maintenance as with respect to performance Yes, we have to maintain a minimal state (for NNTP, this is, user identity, selected group and selected article) outside of ZPublisher and provide access to it via request and response. This is managed within a few dozens lines of code. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Chris Withers wrote at 2006-12-20 09:15 +: Martijn Faassen wrote: It would be very nice if we could make that work! Zope as a drop-in Apache extension would certainly help wider adoption. Yes indeed :-) We're not a normal pythonish Apache thing though, 'cos we need to rigidly limit the number of app server threads because of the zodb object cache. Someone already worked on this and reported success. He integrated a ZEO client via mod_python. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Is there an alternative to zdaemon?
Jim Fulton wrote at 2006-12-22 15:55 -0500: Thoughts? We are using zdaemon widely and would be sad to loose it. The underdocumented argument is unjustified in my view: * zdaemon comes with reasonable online documentation (the help command) * like for all zconfig based programs, essential documentation can be found in the schema file. As the configuration options have been carefully documented (also quite common for zconfig based programs), this is sufficient documentation for the configuration. * There are other forms of documentation than testable documentation (aka doctests). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Some ZPT insights needed
Martijn Faassen wrote at 2007-1-6 20:34 +0100: This kind of automagic unicode error defeating logic scares me. Andreas decided to switch to Unicode only page templates in a micro (!) release. As almost all Zope 2 applications return non-unicode strings (they almost had to as the page templates usually were non-unicode), he *MUST* provide some automatic unicode error defeating logic as otherwise most applications would break. I'd therefore like it if there were a way, application-root specific, to turn off any auto-conversion behavior. Do you think that would be possible? +1 -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
Philipp von Weitershausen wrote at 2007-1-14 14:59 +0100: ... Traditionally, you parse an 8bit string, figure out its encoding (e.g. from ?xml encoding=utf-8? and return some representation of that XML with unicode data. That's why it's actually quite ok for XML parsers to only accept string data. Parsing usually means rebuilding the structure from a text string and *NOT* encoding guessing or Unicode decoding. Therefore, it is actually quite stupid for a parser to try to encode an already decoded string (i.e. a Unicode string) only that it can guess the encoding ;-) A halfway intelligent parser would accept Unicode when it gets it and concentrate on the remaining part of its task: either reporting structural events or building a parse tree. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
Chris Withers wrote at 2007-1-14 18:14 +: ... The problem comes when someone sends you something like: u'?xml version=1.0 encoding=something-else?node /' What should be done then? We parse the declaration and generate an info element for it but otherwise ignore it as it has lost its meaning after the XML has been converted to Unicode. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
Martijn Faassen wrote at 2007-1-15 15:44 +0100: Hey, On 1/15/07, Andreas Jung [EMAIL PROTECTED] wrote: [snip] ok, got it. But this problem can be solved easily by changing the encoding within the preamble. I would say refusing to guess and bailing out with an error message is better in this case. I disagree with you. Logically, parsing an encoded XML document consists of two passes: decode the encoded string into unicode and reconstruct the XML info elements from the serialization. Traditionally, these two passes are not performed one after the other but folded together in a single pass. But that tradition should not prevent to separate out the (Unicode) decoding phase. And after this phase is done, there is not ambiguity left with the XML declaration. Its encoding attribute is simply irrelevant for the second phase (apart from generating the PI info element). Thus, there is no guessing; someone else has just performed the first phase of the complete process -- maybe using the encoding attribute or some overriding information. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Idea: Failure to lookup adapters
Sidnei da Silva wrote at 2007-1-15 17:25 -0200: ... The kind of info I'm looking for is something along the lines: 'We've tried to look up an adapter for (ISomething, ITheOther) but none was found' 'Found an adapter for IFoo, which is a base class for the IBar interface requested. No adapter has been found for the most-specific interface IBar' Comments? In Zope 2, I would use __traceback_info__ or (more likely) __traceback_supplement__ and the traceback formatting facilities in zExceptions.ExceptionFormatter. This is a very efficient way to analyse all problems that result in an exception -- far better than log entries. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
Tres Seaver wrote at 2007-1-15 16:57 -0500: ... Frankly, I don't get the desire to *store* a complete XML document (as opposed to the extracted contents of attributes or nodes) as unicode My desire comes from the easy principle: all text should be unicode. Decoding/encoding happens only at the system boundaries and no longer internally. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
Martijn Faassen wrote at 2007-1-16 23:19 +0100: Dieter Maurer wrote: Martijn Faassen wrote at 2007-1-15 15:44 +0100: I would say refusing to guess and bailing out with an error message is better in this case. I disagree with you. Logically, parsing an encoded XML document consists of two passes: decode the encoded string into unicode and reconstruct the XML info elements from the serialization. Traditionally, these two passes are not performed one after the other but folded together in a single pass. But that tradition should not prevent to separate out the (Unicode) decoding phase. And after this phase is done, there is not ambiguity left with the XML declaration. Its encoding attribute is simply irrelevant for the second phase (apart from generating the PI info element). That's nice as far as it goes. What if after the second phase you need to parse the XML again? What do you do with your encoding header then? After the second phase, I now longer have an XML string but instead either a sequence of events (SAX style) or a tree of XML info elements (syntax tree style). But, whatever I have, the second stage does not magically change my unicode string. It could be parsed over and over again. If it's irrelevant, you better strip it out before you put it into the parser. I loose information then. The event stream or info element tree lacks the XML declaration PI then, or at least its encoding attribute. The parsing process is allowed to loose some information. For example it can loose whitespace details or the order of attributes. I don't know whether the loss or modification of PIs is considered acceptable. In general, this would definitely be wrong. I have read some article in comp.text.xml that complained about the loss of the encoding information -- at it may be a good hint about the default encoding to be used on encoding/serialization. This menas that some XML processing systems loose the information and not everyone is happy. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
Andreas Jung wrote at 2007-1-17 17:48 +0100: ... So Martijn's and my proposal remain. They are not very different. In the end the behavior is almost identical. But I will adopt your suggestion to remove the preamble when storing the data internally (basically to avoid a possible encoding ambiguity). In future times, the preamble might contain information which should not be dropped, e.g. when there is an XML version different from 1.0. For PageTemplates, we know that the encoding information is probably not relevant after the parsing -- unless we want to use it as a default for the Content-Type charset but I doubt that this is a good thing. If the Content-Type's charset is given explicitely, then the encoding of the XML declaration needs to be adapted to this value during the serialization anyway -- thus overriding any encoding present there. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 without ZODB
Philipp von Weitershausen wrote at 2007-1-22 13:51 +0100: ... I think the ZConfig argument was largely due to misunderstandings. I would be surprised if people really cared whether to Zope used ConfigParser or ZConfig (except Fred, perhaps ;)) And, as so often, me. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
Jim Fulton wrote at 2007-1-25 09:11 -0500: ... I disagree with this assertion for the reason that Marius stated, which is that adapters are factories and utilities are not. I Should I be really interested in this implementation detail? All I care of, is that the returned object implements the required interface and is related to the object to be adapted (if any). How the adapter is found/created is of no interest to me. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] python 2.5 optimizations and Zope Catalog ?
Christophe Combelles wrote at 2007-1-27 03:11 +0100: http://wiki.python.org/moin/NeedForSpeed/Successes while reading the highlights of python 2.5, I've found that some string and unicode operations, particularly **search** operations, are a LOT faster, sometimes 25x faster! As a result, (when z3 will work on py2.5), can we expect a great improvement in the Catalog? Unlikely, as the catalog's 'search' is very different from the string and unicode search operations. Phrase searches may however get a bit faster. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Persistent declarations, dead interfaces and a TypeError
Sidnei da Silva wrote at 2007-2-23 12:08 -0300: ... Wonder if we can just check for that? And then how to avoid a dependency of zope.interface on OFS.Uninstalled.BrokenClass. You can positively check that the object is an Interface subclass. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposal for optimized Blob handling
Christian Theune wrote at 2007-3-7 17:37 +0100: I'm writing up a proposal for the ZODB to make even more efficient Blob handling possible. This includes not copying the data from an uploaded file, but using a `link` operation when possible. Is it possible at all? Uploaded files end up in a temporary file. They need to get moved away from this temporary location (as they are likely to be deleted at various administrator decided dates). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposal for optimized Blob handling
Christian Theune wrote at 2007-3-7 21:17 +0100: ... Nope. It won't disappear if you link it again. And the link(src, dst) does move it to a 'save' location ;) You do not tell us, which link you mean. Python's os.link creates a hard link which will only work if source and destination are on the same file system. It is not uncommon that temporary files are on their own filesystem. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: ZPT missing header
Christian Zagrodnick wrote at 2007-3-9 15:07 +0100: ... zope.pagetemplate.pagetemplatefile is removing the header. So it is the pagetemplate, yes. It did so for resources as well. But *only* for the plain HTML header, *not* an XHTML header. I don't see why they should behave different. While I agree that they should behave identical, I do not see a reason to remove the header. Why adding additional complexity, which may introduce bugs (as we have seen)? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
