[Zope3-dev] [Fwd: [Z3d] 537/ 3 Resolve RecordingHTTP is not implemented]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Functional tests are important in every application not only in Zope 3 itself. Therefore zope.app.recorder with the RecordingHTTP should be part of the releases. Egon - Original-Nachricht [snip] Issue #537 Update (Resolve) RecordingHTTP is not implemented Status Resolved, community/issue critical To followup, visit: http://www.zope.org/Collectors/Zope3-dev/537 == = Resolve - Entry #3 by philikon on Aug 12, 2006 6:53 am Status: Pending = Resolved RecordingHTTP is implemented in zope.app.recording. It works fine in a Zope 3 checkout (just tested it again), but since zope.app.recording doesn't ship in Zope 3.3 releases, it obviously doesn't work in Zope 3 installs. I removed the section in zope.conf.in that advertises RecordingHTTP. (r69419, r69420). [snip] == - -- Egon Frerich, Freudenbergstr. 16, 28213 Bremen E-Mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: GnuPT 2.7.2 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE60xluTzybIiyjvURAshPAKCGZ1Eii5+4QUV18yN2x3XrYamtMwCffe3h kDNt5ke/32NDA8XCNORfjXg= =DkN2 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux tlotze
The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux tlotze. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 7221 Blamelist: andreasjung,benji_york,ctheune,fdrake,jens,jim,jukart,poster,rocky,rogerineichen,shh,sidnei,whitmo BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [Fwd: [Z3d] 537/ 3 Resolve RecordingHTTP is not implemented]
Egon Frerich wrote: Functional tests are important in every application not only in Zope 3 itself. Therefore zope.app.recorder with the RecordingHTTP should be part of the releases. That doesn't necessarily follow. zope.app.recorder generates (or rather is primarily used to generate) old-style functional doctests, which are virtually unused with the advent of zope.testbrowser. If it wasn't shipped with releases before, there seems to be even less reason to ship it now. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [Fwd: [Z3d] 537/ 3 Resolve RecordingHTTP is not implemented]
On Tuesday 22 August 2006 14:39, Benji York wrote: Egon Frerich wrote: Functional tests are important in every application not only in Zope 3 itself. Therefore zope.app.recorder with the RecordingHTTP should be part of the releases. That doesn't necessarily follow. zope.app.recorder generates (or rather is primarily used to generate) old-style functional doctests, which are virtually unused with the advent of zope.testbrowser. If it wasn't shipped with releases before, there seems to be even less reason to ship it now. Yep, I agree. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [Fwd: [Z3d] 537/ 3 Resolve RecordingHTTP is not implemented]
On Aug 22, 2006, at 2:39 PM, Benji York wrote: Egon Frerich wrote: Functional tests are important in every application not only in Zope 3 itself. Therefore zope.app.recorder with the RecordingHTTP should be part of the releases. That doesn't necessarily follow. zope.app.recorder generates (or rather is primarily used to generate) old-style functional doctests, which are virtually unused with the advent of zope.testbrowser. If it wasn't shipped with releases before, there seems to be even less reason to ship it now. +1 In fact, it really should be retired from the svn tree. (It was a wonderful tool its time. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Fwd: [Z3d] 537/ 3 Resolve RecordingHTTP is not implemented]
Jim Fulton wrote: On Aug 22, 2006, at 2:39 PM, Benji York wrote: Egon Frerich wrote: Functional tests are important in every application not only in Zope 3 itself. Therefore zope.app.recorder with the RecordingHTTP should be part of the releases. That doesn't necessarily follow. zope.app.recorder generates (or rather is primarily used to generate) old-style functional doctests, which are virtually unused with the advent of zope.testbrowser. If it wasn't shipped with releases before, there seems to be even less reason to ship it now. +1 In fact, it really should be retired from the svn tree. +1 I was actually suggesting to do some fall cleaning after the Zope 3.3 releases to move out all the stuff that we're not really using nor maintaining nor shipping... zope.app.workflow, zope.app.zopetop, zope.app.recorder, just to mention a few. Philipp ___ 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: [Fwd: [Z3d] 537/ 3 Resolve RecordingHTTP is not implemented]
Philipp von Weitershausen wrote: Jim Fulton wrote: On Aug 22, 2006, at 2:39 PM, Benji York wrote: Egon Frerich wrote: Functional tests are important in every application not only in Zope 3 itself. Therefore zope.app.recorder with the RecordingHTTP should be part of the releases. That doesn't necessarily follow. zope.app.recorder generates (or rather is primarily used to generate) old-style functional doctests, which are virtually unused with the advent of zope.testbrowser. If it wasn't shipped with releases before, there seems to be even less reason to ship it now. +1 In fact, it really should be retired from the svn tree. +1 I was actually suggesting to do some fall cleaning after the Zope 3.3 releases to move out all the stuff that we're not really using nor maintaining nor shipping... zope.app.workflow, zope.app.zopetop, zope.app.recorder, just to mention a few. +1 -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Timedelta widget?
Has anyone created a widget for the zope.schema.Timedelta field? I'd love to see one that's available under the ZPL about now. :-) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] [Fwd: [Z3d] 562/ 3 Reject ObjectCopier must copy not reference the object]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I put some minimal files together and uploaded them to the Collector so
that the problem should be more clear.
Some remarks about the IRC log (2006-08-17):
faassen so that if he changes something in the original, it also
changes in the copy, or vice versa
I do not change something in the original so there is no change in the
copy. Let me explain what had happen.
The object name in a container should be the same as the value in a
datafield. If you add an object the NameChooser takes the value from
this datafield.
If you want to copy an object in the ZMI the copy must have another
object name because the names in a container must be unambigous. So the
NameChooser find a new name. The solution is to supplement the object
name with a prefix. In my solution this is the prefix Copy. If the
original object has the object name kitchen the copy gets the name
Copykitchen. An as the name of the object should be the same as the
value of the datafield (from which the object name originally comes) the
datafield in the copy is changed from the NameChooser accordlingly. So
in the datafield von object Copykitchen we find the value
Copykitchen. That is correct. The change in this datafield doesn't
happened manually. It happens by the NameChooser.
philiKON his logic in the namechooser seems bogus too
Can you please be more specific?
Egon
.
- Original-Nachricht
Betreff: [Z3d] 562/ 3 Reject ObjectCopier must copy not reference the
object
[snip]
Issue #562 Update (Reject) ObjectCopier must copy not reference the object
Status Rejected, community/issue critical
To followup, visit:
http://www.zope.org/Collectors/Zope3-dev/562
==
= Reject - Entry #3 by faassen on Aug 17, 2006 7:46 am
Status: Pending = Rejected
I'm not sure I understand the report fully. The claim is that no copy is
made by the ObjectCopier but references are made only. This is not true
for the ObjectCopier - it does make copies (though in some cases it will
make references if there is a reference in the object to an object in
another location).
It's possible something special happens in case of the use of the object
name. More details are needed here.
For the time being, I'm going to reject this issue, but please
give us a more detailed description about what's going on first.
[snip]
___
= Edit - Entry #2 by srichter on Jun 16, 2006 8:20 am
Changes: submitter email, importance (medium = critical)
= Request - Entry #1 by Frerich on Mar 3, 2006 5:14 pm
In my application one of the contenttype datafields should be the
objectname in the container. With a subclass of NameChooser I managed to
add content objects into the container with an objectname which is
identical with a name in a datafield.
In the container view it is possible to select id(s) for copying and
then to paste the selected objects into the same or into another container.
If the objectname of a pasted object is already in the container the
UserError The given name is already being used is triggered. Therefore
I programmed in the NameChooser:
def chooseName(self, name, object):
name = object.RaumName
try:
self.checkName(name, object)
except UserError, e:
if str(e) == The given name is already being used:
object.RaumName = uCopy + object.RaumName
self.chooseName('', object)
name = object.RaumName
return name
return name
So we get unambiguous objectnames for the container (maybe
CopyCopyObject).
And the datafield in the object (here: RaumName) is synchronized with
the objectname.
Since the ObjectCopier doesn't create a real copy but references only
the object the datafield is changed in two objects: in the *original*
object and the copied object. And the content of datafield in the
original object (something with Copy) is different from the objectname
(without Copy).
==
- --
Egon Frerich, Freudenbergstr. 16, 28213 Bremen
E-Mail: [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE65ZBuTzybIiyjvURAuEDAKCbvsMX6jOPShbo3+HAdcmi3SYU8QCfaanB
LCt1+jb65ml1ObUGmdza+eY=
=9PO7
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [Fwd: [Z3d] 562/ 3 Reject ObjectCopier must copy not reference the object]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I assume I found the problem with the ObjectCopier. The ObjectCopier
calls checkObject before copying the object with locationCopy. So I get
in my NameChooser the original object not the copy.
Egon
Egon Frerich schrieb am 2006-08-23 01:41:
I put some minimal files together and uploaded them to the Collector so
that the problem should be more clear.
Some remarks about the IRC log (2006-08-17):
faassen so that if he changes something in the original, it also
changes in the copy, or vice versa
I do not change something in the original so there is no change in the
copy. Let me explain what had happen.
The object name in a container should be the same as the value in a
datafield. If you add an object the NameChooser takes the value from
this datafield.
If you want to copy an object in the ZMI the copy must have another
object name because the names in a container must be unambigous. So the
NameChooser find a new name. The solution is to supplement the object
name with a prefix. In my solution this is the prefix Copy. If the
original object has the object name kitchen the copy gets the name
Copykitchen. An as the name of the object should be the same as the
value of the datafield (from which the object name originally comes) the
datafield in the copy is changed from the NameChooser accordlingly. So
in the datafield von object Copykitchen we find the value
Copykitchen. That is correct. The change in this datafield doesn't
happened manually. It happens by the NameChooser.
philiKONhis logic in the namechooser seems bogus too
Can you please be more specific?
Egon
.
Original-Nachricht
Betreff: [Z3d] 562/ 3 Reject ObjectCopier must copy not reference the
object
[snip]
Issue #562 Update (Reject) ObjectCopier must copy not reference the object
Status Rejected, community/issue critical
To followup, visit:
http://www.zope.org/Collectors/Zope3-dev/562
==
= Reject - Entry #3 by faassen on Aug 17, 2006 7:46 am
Status: Pending = Rejected
I'm not sure I understand the report fully. The claim is that no copy is
made by the ObjectCopier but references are made only. This is not true
for the ObjectCopier - it does make copies (though in some cases it will
make references if there is a reference in the object to an object in
another location).
It's possible something special happens in case of the use of the object
name. More details are needed here.
For the time being, I'm going to reject this issue, but please
give us a more detailed description about what's going on first.
[snip]
___
= Edit - Entry #2 by srichter on Jun 16, 2006 8:20 am
Changes: submitter email, importance (medium = critical)
= Request - Entry #1 by Frerich on Mar 3, 2006 5:14 pm
In my application one of the contenttype datafields should be the
objectname in the container. With a subclass of NameChooser I managed to
add content objects into the container with an objectname which is
identical with a name in a datafield.
In the container view it is possible to select id(s) for copying and
then to paste the selected objects into the same or into another container.
If the objectname of a pasted object is already in the container the
UserError The given name is already being used is triggered. Therefore
I programmed in the NameChooser:
def chooseName(self, name, object):
name = object.RaumName
try:
self.checkName(name, object)
except UserError, e:
if str(e) == The given name is already being used:
object.RaumName = uCopy + object.RaumName
self.chooseName('', object)
name = object.RaumName
return name
return name
So we get unambiguous objectnames for the container (maybe
CopyCopyObject).
And the datafield in the object (here: RaumName) is synchronized with
the objectname.
Since the ObjectCopier doesn't create a real copy but references only
the object the datafield is changed in two objects: in the *original*
object and the copied object. And the content of datafield in the
original object (something with Copy) is different from the objectname
(without Copy).
==
--
Egon Frerich, Freudenbergstr. 16, 28213 Bremen
E-Mail: [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
http://mail.zope.org/mailman/options/zope3-dev/e.frerich%40nord-com.net
- --
Egon Frerich, Freudenbergstr. 16, 28213 Bremen
E-Mail: [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
