unsubscribe!!! -----Ursprüngliche Nachricht----- Von: zope-dev-admin@zope.org [mailto:zope-dev-admin@zope.org]Im Auftrag von zope-dev-request@zope.org Gesendet: Freitag, 8. Juni 2001 12:08 An: zope-dev@zope.org Betreff: Zope-Dev digest, Vol 1 #1148 - 12 msgs Send Zope-Dev mailing list submissions to zope-dev@zope.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.zope.org/mailman/listinfo/zope-dev or, via email, send a message with subject or body 'help' to zope-dev-request@zope.org You can reach the person managing the list at zope-dev-admin@zope.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Zope-Dev digest..." Today's Topics: 1. Re: Property Storage (Phillip J. Eby) 2. Re: Bulletproof ZCatalog proposal (Shane Hathaway) 3. Re: [Announce] API Documentation Fishbowl Project (R. David Murray ) 4. Re: Bulletproof ZCatalog proposal (Shane Hathaway) 5. Re: Bulletproof ZCatalog proposal (Phillip J. Eby) 6. DCOracle2 Beta 2 (Matt Kromer) 7. RE: A simple dtml-if question... (Jeff Nielsen / UgoFast) 8. using php on zope (Stian Jenssen) 9. Re: ANN: ReplacingDateTime proposal (Erik Enge) 10. Re: ANN: ReplacingDateTime proposal (Stephan Richter) 11. Re: Bug in Zope VersionControl (Martijn Pieters) 12. How to return downloadable content from Python Method (Blandford, Simon [BSS Audio UK]) --__--__-- Message: 1 Date: Thu, 07 Jun 2001 15:46:42 -0500 To: "Chris Withers" <chrisw@nipltd.com>,<zope-dev@zope.org> From: "Phillip J. Eby" <pje@telecommunity.com> Subject: Re: [Zope-dev] Property Storage At 09:29 PM 6/7/01 +0100, Chris Withers wrote:
If I change one property on, say, a DTML Document, does that store a whole new copy of the document in the ZODB?
It updates the object in the ZODB. Whether that causes a copy to be made, depends on the underlying storage. FileStorage makes copies, BerkeleyStorage (at least Ty's first implementation thereof) does not.
Is so, then how about storing properties in their own mini-class that just subclassed Persistent, so each property got its own pickle jar?
There are a lot of things you'd have to tinker with to get that behavior. You would probably be better off just using a storage that doesn't make copies, or using ZPatterns to store selected attributes in such a storage (such as a differently-backed ZODB, the filesystem, or an SQL or LDAP database). --__--__-- Message: 2 Date: Thu, 7 Jun 2001 17:13:06 -0400 (EDT) From: Shane Hathaway <shane@digicool.com> To: "Phillip J. Eby" <pje@telecommunity.com> Cc: Erik Enge <erik@thingamy.net>, <zope-dev@zope.org> Subject: Re: [Zope-dev] Bulletproof ZCatalog proposal On Thu, 7 Jun 2001, Phillip J. Eby wrote:
I was thinking that certain types of objects would be committed by the transaction manager before all others. In this case, the catalog (or a special object in the catalog) would be committed first. It would resolve all conflicts in the contained indices before they occur by replaying the changes in the persisted queues from the transaction history, then setting the _p_serial attributes to convince the storage that the conflicts have already been resolved.
Hm. Sounds to me like what you actually want is for the transaction manager to do this *after* everything else, rather than before. Thus, you would catch any changes which occur *during* transaction commit - such as commit-phase cataloging (as some folks do with ZPatterns currently).
Maybe I didn't explain this clearly enough. Let me write some quick pseudocode: class Catalog (Persistent): finished_changes = None # Mapping: {path -> (object, adding)} unfinished_changes = None # Same as above tid = None # Transaction ID def catalogObject(self, ob, path): unf = self.unfinished_changes if unf is None: self.unfinished_changes = unf = {} unf[path] = (ob, 1) def uncatalogObject(self, path): unf = self.unfinished_changes if unf is None: self.unfinished_changes = unf = {} unf[path] = (ob, 0) def searchResults(self, ...): self.finishChanges() # ... Perform search ... return results def finishChanges(self): unf = self.unfinished_changes if unf is not None: fin = self.finished_changes if fin is None or self._p_serial != self.tid: # Create finished_changes if not yet created # and clear it if we're in a different transaction # from the last time finished_changes was changed. self.finished_changes = fin = {} self.tid = self._p_serial for path, (ob, adding) in unf.items(): if adding: self.addToIndexes(ob, path) else: self.removeFromIndexes(path) fin[path] = (ob, adding) self.unfinished_changes = None def __getstate__(self): # Called during transaction commit. self.finishChanges() return Persistent.__getstate__(self) def _p_priority(self): # Causes this object to be added to the *top* # of the list of objects to commit rather than the # bottom. (Just an idea.) return 1 def _p_resolveConflict(self, old, committed, newstate): ''' Apply the changes in self.finished_changes to committed and return the result. ''' This does mean that _p_resolveConflict() might be called frequently, but (potentially) it would never fail because of conflicts. Now, this doesn't provide any automatic cataloging, which is what I think you're suggesting. I think automatic reindexing, a good idea, is mostly independent of bulletproofing and lazifying the catalog. To achieve automatic indexing, I was thinking that a special attribute would be added to cataloged objects. It would contain the OIDs of the catalogs interested in the object. Transaction.register() would look for this attribute and invoke catalogObject(). Of course, that wouldn't quite work because the object might change again within the transaction and the transaction manager wouldn't be told about the second and further changes. But I'm sure there's a good way to compensate for this, such as making the catalog scan for later changes before calling searchResults(). (cPersistence might need to assist.) Shane --__--__-- Message: 3 Date: Thu, 7 Jun 2001 17:30:23 -0400 (EDT) From: "R. David Murray " <bitz@bitdance.com> To: jimbo <jimbo@tacomaplace.com>, dan@control.com cc: zope-dev@zope.org Subject: Re: [Zope-dev] [Announce] API Documentation Fishbowl Project On Wed, 6 Jun 2001, jimbo wrote:
I believe that if you are a true developer you will/can figure out the api given the vast information available today. For example the dcworkflow product was just released. I believe the best documentation would be how-to actually use the product.
Ah, not really. Or, rather, "maybe", with the *new* products whose APIs are being constructed/documented better from the start, but if and probably only if there are either comprehensive examples or the framework docs mentioned in the proposal. IMO the biggest issue here for developers, as others have said, is clarifying/documenting the old Zope interfaces. If we get that, then new products will be even better/better integrated. This includes ZClasses. Half the problem with ZClasses is that they sort of almost work, but they break down partly because the interfaces really aren't documented very well. (I strongly recommend learning python. It's an easy language to learn. Then use real Python classes instead of ZClasses. ZClasses have their place, but if you are doing serious development they tend to get in the way more than they help, IMO).
In short enough geek speek. Change the language into something the rest of masses can understand. How can I use zope/API to get PAID! How can I actually make the dcworkflow or the core session or the ZPT do something. Plenty of example uses. I think they might call them case studies or something to that effect.
"How can I actually make x do something" sounds an awful lot like what I think the "framework docs" portion of the proposal is addressing, when you are talking about components like workflow and coresessiontracking that are used to *develop* applications. I think you will find that good API+framework documentation will either provide a good deal of the info you are looking for, or, for products that are less in the way of infrastructure components and more in the way of end user products, provide the essential foundation upon which more end-user directed documentation can built. Good end user stuff is best written by someone who understands how the product works in detail, and the API/framework docs provide the foundation to acquire that knowledge (assuming the product author himself doesn't go straight on to providing the end user docs). How to get use the API to get paid is, I think, outside of the scope of the proposal <grin>. As for the proposal itself, the mechanism outlined sounds OK to me. I do also have an issue with the Interface scarecrow in that it does not seem to cover stuff that is not specifically a Class interface. I'm thinking of module level functions in particular, but also the documentation of Protocols mentioned by another poster is of concern. So Interfaces by themselves do not seem to be enough. Where they are enough, though, I should think there would be nothing stoping someone from writing one for an existing Zope internal interface, without modifying the code (ie: no automated verification in that case). Of course, I suspect that anyone doing that grubby job would tend to want to start tinkering with the code to "clean up" the interface...which come to think of it might be something that should go in the "risks" section <wry grin>. On the third hand, there's nothing to stop the community from generating some "this is how I think it works" documentation that people with "inside knowledge" can then help tune. I think some of this happened during the original Interfaces Wiki days, and it seems to have produced good results. I also want to say that I really like the fact that this proposal makes it clear that DC understands the long term value of good developer documentation <grin>. Oh, and one final thought. It seems to me that the Developer's Guide needs to evolve into a "meta framework" document: a place to learn how the whole system fits together, and how you use the various components to build working systems. I think it's a solid start in its current form. --RDM --__--__-- Message: 4 From: Shane Hathaway <shane@digicool.com> Subject: Re: [Zope-dev] Bulletproof ZCatalog proposal Date: Thu, 07 Jun 2001 19:07:23 -0400 Organization: Digital Creations, Inc. To: zope-dev@zope.org "Phillip J. Eby" wrote:
That is, in ZPatterns one can specify triggers such as:
WHEN OBJECT DELETED, CHANGED CALL someCatalog.manage_uncatalog(self.absolute_url(1)) WHEN OBJECT ADDED, CHANGED CALL someCatalog.manage_catalog(self,self.absolute_url(1))
After I read this again I realized what you were saying. This capability of ZPatterns is very brittle, don't you think? If the catalog is updated manually before the special ZPatterns object is added to the queue, the behavior is undefined AFAIK--either the later changes to the catalog will be ignored, will cause a conflict, or some objects will be written twice in the same transaction. However, if we could specify transaction commit priorities, and the ZPatterns update came first, auto-indexing came second, and everything else followed, I think it would work. Or perhaps ZPatterns should be able to register things that occur *before* the two-phase commit protocol. Shane --__--__-- Message: 5 Date: Thu, 07 Jun 2001 20:28:08 -0500 To: Shane Hathaway <shane@digicool.com>,zope-dev@zope.org From: "Phillip J. Eby" <pje@telecommunity.com> Subject: Re: [Zope-dev] Bulletproof ZCatalog proposal At 07:07 PM 6/7/01 -0400, Shane Hathaway wrote:
"Phillip J. Eby" wrote:
That is, in ZPatterns one can specify triggers such as:
WHEN OBJECT DELETED, CHANGED CALL someCatalog.manage_uncatalog(self.absolute_url(1)) WHEN OBJECT ADDED, CHANGED CALL someCatalog.manage_catalog(self,self.absolute_url(1))
After I read this again I realized what you were saying. This capability of ZPatterns is very brittle, don't you think?
Yep. That's why I've previously described ZPatterns as a "hack". :)
If the catalog is updated manually before the special ZPatterns object is added to the queue, the behavior is undefined AFAIK--either the later changes to the catalog will be ignored, will cause a conflict, or some objects will be written twice in the same transaction.
True. But this behavior is avoidable through the use of subtransaction commits, in the event that someone has to have transactions which update a ZCatalog directly. Usually, when someone is using catalogs with ZPatterns, they use triggers to do all the updates and don't touch the catalog manually. Note that I'm not saying this still isn't a hack. But it's the best I could do without either fixing the multi-commit issue in ZODB, or with some kind of priority scheme.
However, if we could specify transaction commit priorities, and the ZPatterns update came first, auto-indexing came second, and everything else followed, I think it would work. Or perhaps ZPatterns should be able to register things that occur *before* the two-phase commit protocol.
Yep. One of the last two times I spoke with Jim in person (either the January DC visit or IPC 8, I forget which), he said something about it maybe being a good idea to have some kind of priority system like that. I'd love to see something like it exist, if it would make some of ZPatterns' hackery unnecessary. The implementation could consist of two subscription queues: ruleAgents and indexingAgents. ZCatalog would register in indexingAgents, and ZPatterns objects would register in one or the other, usually ruleAgents. (I can think of some circumstances where it would be nice to use the indexingAgents queue, but right now ZPatterns apps have to work around this by defining their rules in execution priority order.) Upon being told to perform a transaction or subtransaction commit, the transaction would notify all the ruleAgents, and then all the indexingAgents. Objects could still subscribe to either queue while this notifying is taking place. (So that triggered actions could cause indexish objects to register as indexingAgents, not to mention causing updated objects to fire additional triggers.) Once all agents in a queue are notified, that queue should be cleared so that notifications are on a per-subtransaction basis. Once both queues are cleared, normal transaction behavior goes forward. Hm. That's simpler than I thought it was going to be. Shoot, I can even see how to implement it as a runtime patch, that would've been simpler than all the shenanigans ZPatterns goes through to fake out the transaction machinery... and it's a better implementation. Ah well. At the time I wanted to avoid trying to convince Jim to add machinery to transactions "just" for ZPatterns, given that ZPatterns wasn't a particularly established product at the time. Let me know if you guys put something like this in, though, and I'll definitely look at reworking ZPatterns to use the mechanism. It could potentially cut a lot of code out and improve the robustness at the same time. --__--__-- Message: 6 From: "Matt Kromer" <matt@digicool.com> To: zope-dev@zope.org Date: Thu, 07 Jun 2001 23:04:08 -0400 Subject: [Zope-dev] DCOracle2 Beta 2 Description DCOracle2 is a Python binding to Oracle 8. DCOracle2 is a replacement for DCOracle, written primarily in C. DCOracle 1 uses OCI 7 bindings for most Oracle calls, with OCI 8 mixed in for LOB support. Oracle 8i disallows mixing of calls within a statement, and so breaks LOB support. DCO2 uses entirely OCI 8 calls, and thus can use LOBs. New in this Release Beta 2 Fix ZOracleDA attempting to fetch on non-select. Add explicit C Cursor.close() to break cycle allowing cursor to be deallocated. Change fetchmany() and fetchall() to return None if no results remain rather than []. Several connection/cursor and cursor/procedure cycle deferring actions. SPARC byteorder fixes for stored procedures. Also, binary builds are available for Solaris and Linux i386. Contents This release contains both DCOracle2 and a slightly modified ZOracleDA; it will register as ZOracleDA would (to silently upgrade Oracle connections) and thus cannot be run concurrently with ZOracleDA/DCOracle. Installation To replace ZOracleDA, untar into lib/python/Products and make, move ZOracleDA out of lib/python/Products, and rename lib/python/Products/DCO2 to lib/python/Products/ZOracleDA. Usage This release is intended for testing with ZOracleDA feature compatibility (including LOB support) and is also intended for general use. Platforms NT support has been tested, Microsoft Visual Studio project files are included; this has only received testing with Oracle 8.0 and Oracle 8.1 on Linux, Solaris, and Windows NT; a wider variety of platform experience is welcomed. Download The product is available at http://www.zope.org/Members/matt/dco2 --__--__-- Message: 7 From: "Jeff Nielsen / UgoFast" <Ugo@speakeasy.net> To: "Chris Withers" <chrisw@nipltd.com> Cc: "Christian Theune" <ct@gocept.com>, "Zope-Dev@Zope. Org" <zope-dev@zope.org> Subject: RE: [Zope-dev] A simple dtml-if question... Date: Thu, 7 Jun 2001 21:28:08 -0700 Hey thanks. That works. -----Original Message----- From: Chris Withers [mailto:chrisw@nipltd.com] Sent: Thursday, June 07, 2001 4:43 AM To: Jeff Nielsen / UgoFast Cc: Christian Theune; Zope-Dev@Zope. Org Subject: Re: [Zope-dev] A simple dtml-if question...
Thanks Christian, but it didn't work. I went with the long way:
<dtml-if expr="LoginResults=='Pass'"> <dtml-if expr="PATH_INFO=='/Maintain/Results'"> Valid response <dtml-else> False response </dtml-if> <dtml-else> False response </dtml-if>
<dtml-if expr="LoginResults=='Pass' and PATH_INFO=='/Maintain/Results'"> Valid Response <dtml-else> Fasle Response </dtml-if> cheers, Chris --__--__-- Message: 8 From: Stian Jenssen <stian.jenssen@nrk.no> To: "'zope-dev@zope.org'" <zope-dev@zope.org> Date: Fri, 8 Jun 2001 10:40:49 +0200 Subject: [Zope-dev] using php on zope
Hi there!
I wan't to use php with zope, does anybody know how the header syntax shall look like? Tried diffrent syntaxes but i get wierd outputs, not as expected.
--__--__-- Message: 9 Date: Fri, 8 Jun 2001 10:53:01 +0200 (CEST) From: Erik Enge <erik@thingamy.net> To: andreas@digicool.com cc: zope-dev@zope.org, srichter@cbu.edu Subject: Re: [Zope-dev] ANN: ReplacingDateTime proposal On Thu, 7 Jun 2001, Andreas Jung wrote:
Feel free to review and comment the propsal to replace the current DateTime module of Zope by the mxDateTime module:
From the proposal:
""" License issues mxDateTime stands under the EGENIX Public License that is considered to be an Open Source license. It should be compatible to GPL except there is discussion about the choice of the law clause between R. Stallmann and M-A. Lemburg """ Shouldn't it be focused on compatability with the ZPL instead of the GPL? From what I hear, there still are issues with, for example, distributing Python Products as GPL with Zope. Anyone with better knowledge about this care to enlighten me? --__--__-- Message: 10 Date: Fri, 08 Jun 2001 04:56:09 -0500 To: Erik Enge <erik@thingamy.net> From: Stephan Richter <srichter@cbu.edu> Subject: Re: [Zope-dev] ANN: ReplacingDateTime proposal Cc: zope-dev@zope.org
Shouldn't it be focused on compatability with the ZPL instead of the GPL? From what I hear, there still are issues with, for example, distributing Python Products as GPL with Zope.
Anyone with better knowledge about this care to enlighten me?
See an earlier post on a different thread. Chris wrote that the license is BSDish and is therefore compatible with ZPL. This means that mxDateTime could be distributed with Zope. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management --__--__-- Message: 11 Date: Fri, 8 Jun 2001 12:01:51 +0200 From: Martijn Pieters <mj@digicool.com> To: Christian Theune <ct@gocept.com> Cc: zope-dev@zope.org Subject: Re: [Zope-dev] Bug in Zope VersionControl On Thu, Jun 07, 2001 at 08:30:26PM +0200, Christian Theune wrote:
Okay ... I admit using opera and enjoying it.
Problem is, that opera is sooo standardsconform.
See Zope/lib/python/Products/OFSP/Version.py:175 in function enter()
Somebody thats the path for the cookie as SCRIPT_NAME. This seems that the scope of the versions should be limited to the subtree where the version object was instanciated. Nice idea.
But this doesn't work.
First:
Internet Explorer and Netscape ignore the path of the cookie and assume '/'.
Second:
Opera is conform to the rfc of http 1.1, and this means, that the cookie is only valid for the version itself, and is not used in any place out of http://myzope:8080/blaah/myVersion
Proposed solution:
Change the path to '/'. And have the same behaviour on all browsers.
Or:
Change the path to REQUEST["URL1"] (is this the parent folder?) and have the intended mechanism working at least on opera.
The last is my personal favorite, because you can have different versions concurrently open on different projects @ one server.
Proposed patch for both solutions comes as attachement.
REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer environment, this is '/'. In a situation where the Zope server is running behind another webserver, and is not at the root of that server, SCRIPT_NAME represents the path to the Zope server. For instance, if your Zope server is presented to the outside world as 'http://a.server.com/a/path/to/zope/' then SCRIPT_NAME will be '/a/path/to/zope/', whereever you are in the Zope object hierarchy. Thus, a version cookie is bound to the root of the Zope server. In your case, it seems that Opera is ignoring the cookie path altogether, and instead falls back on the default, which is the path of the Version object itself. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ --------------------------------------------- --__--__-- Message: 12 From: "Blandford, Simon [BSS Audio UK]" <Simon.Blandford@bss.co.uk> To: "'zope-dev@zope.org'" <zope-dev@zope.org> Date: Fri, 8 Jun 2001 11:06:27 +0100 Subject: [Zope-dev] How to return downloadable content from Python Method This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F002.AEADCB00 Content-Type: text/plain; charset="iso-8859-1" I am compressing files which need to be uncompressed inline before download. The DTML <href=...> calles a python method in the product which returns the uncompressed file data. Say this file is an MSWord document, how do I return this as a file to download? Presently, the browser just tries to display the binary file and makes a mess of it. Regards, Simon B. ------_=_NextPart_001_01C0F002.AEADCB00 Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META content="MSHTML 5.00.3315.2870" name=GENERATOR></HEAD> <BODY> <DIV><FONT face=Arial size=2><SPAN class=024500210-08062001>I am compressing files which need to be uncompressed inline before download. The DTML <href=...> calles a python method in the product which returns the uncompressed file data. Say this file is an MSWord document, how do I return this as a file to download? Presently, the browser just tries to display the binary file and makes a mess of it.</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=024500210-08062001></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=024500210-08062001>Regards,</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=024500210-08062001>Simon B.</SPAN></FONT></DIV></BODY></HTML> ------_=_NextPart_001_01C0F002.AEADCB00-- --__--__-- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev (To receive general Zope announcements, see: http://lists.zope.org/mailman/listinfo/zope-announce For non-developer, user-level issues, zope@zope.org, http://lists.zope.org/mailman/listinfo/zope ) End of Zope-Dev Digest