[Zope-dev] AW: Zope-Dev digest, Vol 1 #1148 - 12 msgs
Jana Mahlke
jana.mahlke@copia-ag.de
Fri, 8 Jun 2001 12:15:26 +0200
unsubscribe!!!
-----Urspr=FCngliche 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 who=
le
>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 ju=
st
>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 =3D None # Mapping: {path -> (object, adding)}
unfinished_changes =3D None # Same as above
tid =3D None # Transaction ID
def catalogObject(self, ob, path):
unf =3D self.unfinished_changes
if unf is None: self.unfinished_changes =3D unf =3D {}
unf[path] =3D (ob, 1)
def uncatalogObject(self, path):
unf =3D self.unfinished_changes
if unf is None: self.unfinished_changes =3D unf =3D {}
unf[path] =3D (ob, 0)
def searchResults(self, ...):
self.finishChanges()
# ... Perform search ...
return results
def finishChanges(self):
unf =3D self.unfinished_changes
if unf is not None:
fin =3D self.finished_changes
if fin is None or self._p_serial !=3D 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 =3D fin =3D {}
self.tid =3D self._p_serial
for path, (ob, adding) in unf.items():
if adding: self.addToIndexes(ob, path)
else: self.removeFromIndexes(path)
fin[path] =3D (ob, adding)
self.unfinished_changes =3D 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 quit=
e
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 th=
e
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 th=
e
api given the vast information available today.
> For example the dcworkflow product was just released. I believe the b=
est
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 examp=
le
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 ZPattern=
s,
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 so=
me
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 a=
nd
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 th=
is
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 indexi=
sh
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 a=
re
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 th=
an
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 convin=
ce
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=3D"LoginResults=3D=3D'Pass'">
> <dtml-if expr=3D"PATH_INFO=3D=3D'/Maintain/Results'">
> Valid response
> <dtml-else>
> False response
> </dtml-if>
> <dtml-else>
> False response
> </dtml-if>
<dtml-if expr=3D"LoginResults=3D=3D'Pass' and PATH_INFO=3D=3D'/Maintain/R=
esults'">
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 b=
e
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 i=
s
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 objec=
t
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 understan=
d
this format, some or all of this message may not be legible.
------_=3D_NextPart_001_01C0F002.AEADCB00
Content-Type: text/plain;
charset=3D"iso-8859-1"
I am compressing files which need to be uncompressed inline before downlo=
ad.
The DTML <href=3D...> calles a python method in the product which returns=
the
uncompressed file data. Say this file is an MSWord document, how do I ret=
urn
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.
------_=3D_NextPart_001_01C0F002.AEADCB00
Content-Type: text/html;
charset=3D"iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885=
9-1">
<META content=3D"MSHTML 5.00.3315.2870" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D024500210-08062001>I am co=
mpressing
files which need to be uncompressed inline before download. The DTML
<href=3D...> calles a python method in the product which returns th=
e
uncompressed file data. Say this file is an MSWord document, how do I ret=
urn
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=3DArial size=3D2><SPAN
class=3D024500210-08062001></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN
class=3D024500210-08062001>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D024500210-08062001>Simon
B.</SPAN></FONT></DIV></BODY></HTML>
------_=3D_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