[Zope-Annce] Announce: Vancouver Python Workshop
Vancouver Python Workshop = Building on the huge success of the 2004 Vancouver Python Workshop, the Vancouver Python and Zope User Group is pleased to announce the 2006 Vancouver Python Workshop. The conference will begin with keynote addresses on August 4st. Further talks (and tutorials for beginners) will take place on August 5th and 6th. The Vancouver Python Workshop is a community organized conference designed for both the beginner and for the experienced Python programmer with: * tutorials for beginning programmers * advanced lectures for Python experts * case studies of Python in action * after-hours social events * informative keynote speakers * tracks on multimedia, Web development, education and more More information see: http://www.vanpyz.org/conference/ or contact Brian Quinlan at: brian at sweetapp.com Vancouver = In addition to the opportunity to learn and socialize with fellow Pythonistas, the Vancouver Python Workshop also gives visitors the opportunity to visit one of the most extraordinary cities in the world (1). For more information about traveling to Vancouver, see: http://www.vanpyz.org/conference/vancouver.html http://www.tourismvancouver.com http://en.wikipedia.org/wiki/Vancouver Important dates === Talk proposals accepted: May 15th to June 15th Early registration (discounted): May 22nd to June 30th Normal registration: from July 1st Keynotes: August 4th Conference and tutorial dates: August 5th and 6th (1) http://news.bbc.co.uk/2/hi/business/2299119.stm -- Andy McKay Enfold Systems http://www.enfoldsystems.com ___ Zope-Announce maillist - Zope-Announce@zope.org http://mail.zope.org/mailman/listinfo/zope-announce Zope-Announce for Announcements only - no discussions (Related lists - Users: http://mail.zope.org/mailman/listinfo/zope Developers: http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] Zope 3 ZPTs in Zope 2: Nearly done
On 5/22/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Silence is treated as consent with what I propose in the comments. ... ;-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 3 ZPTs in Zope 2: Nearly done
Tres Seaver wrote:
Zope2 uses them at the beginning of a path to indicate traversal from
the root. -1 to dropping that case (it is the one which makes
'/foo/bar' behave orthagonally).
Yeah, I'm actually about -10 to this ;-)
...think about trying to explain why:
context.restrictedTraverse('/plonesite/folder/document').absolute_url()
...works, while the following barfs at you:
tal:attributes=href /plonesite/folder/document/absolue_url
...which would mean you could no longer use Zope 2's catalog uids as
paths for traversal, which would be a shame :-/
Havinng blank elements work as no-ops
also makes them behave predictably: this is what command shells (sane
ones, anyway) do with them. E.g.:
$ ls /path/to//foo
yiels the same results as:
$ ls /path/to/foo
So -0 to dropping the current blank traversal behavior at all.
Then again, I'm +0.1 on dropping empty path elements anywhere but the
start of the path...
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py Officially deprecate the BBB methods on the iterator and add a note
Tres Seaver wrote: +@deprecate(The 'last' method has been deprecated and will disappear + in Zope 2.12. Use the 'end' property instead.) def last(self, name=None): if self.end: return True I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html): Yeah, what Tres said ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 3 ZPTs in Zope 2: Nearly done
On Mon, May 22, 2006 at 03:41:21AM +0200, Philipp von Weitershausen wrote:
Philipp von Weitershausen wrote:
http://svn.zope.org/Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testDTMLTests.py?rev=68229view=auto
http://svn.zope.org/Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testHTMLTests.py?rev=68230view=log
I meant
http://svn.zope.org/Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testHTMLTests.py?rev=68230view=log
http://svn.zope.org/Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testExpressions.py?rev=68229view=auto
instead.
Re. one of your questions:
#there are ways to make code compatible with 2.9 and 2.10:
#Add a nocall: before the python: expression (if that's
#possible?!?).
Yes, it's possible. This works fine in 2.9:
p tal:define=blah nocall:python:int tal:content=python:blah('1')+2
/p
--
Paul Winkler
http://www.slinkp.com
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py Officially deprecate the BBB methods on the iterator and add a note
Tres Seaver wrote: +@deprecate(The 'first' method has been deprecated and will disappear + in Zope 2.12. Use the 'start' property instead.) def first(self, name=None): if self.start: return True return not self.same_part(name, self._last, self.item) +@deprecate(The 'last' method has been deprecated and will disappear + in Zope 2.12. Use the 'end' property instead.) def last(self, name=None): if self.end: return True I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html): This sounds sensible. Thanks for the pointer. I'll undeprecate them :). Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope 3 ZPTs in Zope 2: Nearly done
Tres Seaver wrote:
Re: Empty path elements:
Zope2 uses them at the beginning of a path to indicate traversal from
the root.
Sure, in restrictedTraverse and the like. But not in TALES expressions.
While you can start a TALES expression on a /, the empty path element at
the beginning stands for the global namespace. Hence, path:foo/bar and
path:/foo/bar are identical. Specially, you still have to write root/bla
or /root/bla to traverse from the root object.
-1 to dropping that case (it is the one which makes
'/foo/bar' behave orthagonally). Havinng blank elements work as no-ops
also makes them behave predictably: this is what command shells (sane
ones, anyway) do with them. E.g.:
$ ls /path/to//foo
yiels the same results as:
$ ls /path/to/foo
So -0 to dropping the current blank traversal behavior at all.
Therefore, +0 to modifying Z3's version to allow the same behavior (I
think Zope2's version is more correct).
I would tend to agree, however, Fred must've had a reason when he added
the check for empty path elements in zope.tales.expressions:
26551 srichter class SubPathExpr(object):
12874 philikon
9658 matth def __init__(self, path, traverser, engine):
9637 matth self._traverser = traverser
9658 matth self._engine = engine
10598 stevea
9637 matth # Parse path
9658 matth compiledpath = []
9658 matth currentpath = []
9658 matth for element in str(path).strip().split('/'):
26722 fdrake if not element:
26722 fdrake raise engine.getCompilerError()(
26722 fdrake 'Path element may not be empty in
%r' % path)
r26722 unfortunately doesn't have a log message that might hint at the
reason. It does feature an extensive test
(testEmptyPathSegmentRaisesCompilerError) for this change though.
Perhaps Fred can shed some light on this issue? (CCing him)
Re: calling primitive types which are at the end of a path expression.
They should be called, as should any other callable at the end of a path
expression; anything else is a hard-to-explain bit of special case
hackery. The ZPT spec has *always* read so. +1 to fixing both / either
Z2 or Z3 to make this uniformly so. BBB be damned in this case, as the
behavior (not calling the primitiive type) is contrary to spec.
Right. Basically, we'd be fixing a bug because the current Zope 2
behaviour is contradicting spec. Too bad this behaviour is documented in
a test... oh well, tests can have bugs, too. I will fix the test in Zope
2.10 to work with Zope 3's (correct) behaviour. I should probalby also
fix Zope 2.9's behaviour if we consider this a bug?!?
Philipp
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py Officially deprecate the BBB methods on the iterator and add a note
Philipp von Weitershausen wrote: Tres Seaver wrote: +@deprecate(The 'first' method has been deprecated and will disappear + in Zope 2.12. Use the 'start' property instead.) def first(self, name=None): if self.start: return True return not self.same_part(name, self._last, self.item) +@deprecate(The 'last' method has been deprecated and will disappear + in Zope 2.12. Use the 'end' property instead.) def last(self, name=None): if self.end: return True I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html): This sounds sensible. Thanks for the pointer. I'll undeprecate them :). I'll add nonetheless that neither 'first' nor 'last' nor 'nextIndex' are required by the ZPT spec (http://www.zope.org/Wikis/DevSite/Projects/ZPT/RepeatVariable). Hence, Zope 3 just doesn't have them. I can still see a use case for 'first' and 'last' which is why I'll do my best to continue to support them. Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py Officially deprecate the BBB methods on the iterator and add a note
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Philipp von Weitershausen wrote: Tres Seaver wrote: +@deprecate(The 'first' method has been deprecated and will disappear + in Zope 2.12. Use the 'start' property instead.) def first(self, name=None): if self.start: return True return not self.same_part(name, self._last, self.item) +@deprecate(The 'last' method has been deprecated and will disappear + in Zope 2.12. Use the 'end' property instead.) def last(self, name=None): if self.end: return True I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html): This sounds sensible. Thanks for the pointer. I'll undeprecate them :). I'll add nonetheless that neither 'first' nor 'last' nor 'nextIndex' are required by the ZPT spec (http://www.zope.org/Wikis/DevSite/Projects/ZPT/RepeatVariable). Hence, Zope 3 just doesn't have them. I can still see a use case for 'first' and 'last' which is why I'll do my best to continue to support them. This is a case for *expanding* what Z3 has: it isn't right by default, you know, especially when it comes to pieces of Z2 technology which it has forked. For instance, I know of several DTML fixes done since Z3 forked off zope.documenttemplate: they should be forward-ported, but may languish due to lack of care. ZPT is different: is has been in heavy production use, with *lots* more attention to real world use cases than the Z3 version would have gotten until only recently. Let's use some caution about harmonizing the two. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEchHL+gerLs4ltQ4RAif7AKCM7ge713kNc+uW2xECLewHDGk45QCeKNOw tpC42LYQMBinUalgw+gGxzI= =Q8H2 -END PGP SIGNATURE- -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testExpressions.py Fix a test that was testing wrong behaviour: primitive types
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Log message for revision 68244:
Fix a test that was testing wrong behaviour: primitive types
werent' called if they were the result of a path expression, while
all other callables were called. This tests now tests the correct
behaviour (which happens to be already implemented by the Zope 3
TALES engine)
+assert ec.evaluate('x | python:int') == 0
Wait a minute -- that isn't a path expression there!
Yes it is. This line could explicitly written as:
assert ec.evaluate('path: x | python:int') == 0
The python: expression is just part of the path expression.
The '|' is not supposed to change the rules for evaluation of the
subexpressions!
It doesn't change the rules for the evaluation of the subexpressions
themselves. But it might easily change the rules of what happens to the
result of the expression afterwards.
If
'int' or the like were somehow avaialbe at module scope, or via
'options' or another top-level name, then they should be called *when
they are the last item in a path expression*.
The test was actually correct beofore: because tne PathExpression, 'x',
raises, the PythonExpression, 'int', is evalutated. The result of a
subexpression is not suppoeed to be called,
No, not the result of a subexpression, but the result of the overall
path expression. That's how it works in both Zope 2 and Zope 3. Zope 2
just special-cases primitive types.
Philipp
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py Officially deprecate the BBB methods on the iterator and add a note
Tres Seaver wrote: Philipp von Weitershausen wrote: Philipp von Weitershausen wrote: Tres Seaver wrote: +@deprecate(The 'first' method has been deprecated and will disappear + in Zope 2.12. Use the 'start' property instead.) def first(self, name=None): if self.start: return True return not self.same_part(name, self._last, self.item) +@deprecate(The 'last' method has been deprecated and will disappear + in Zope 2.12. Use the 'end' property instead.) def last(self, name=None): if self.end: return True I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html): This sounds sensible. Thanks for the pointer. I'll undeprecate them :). I'll add nonetheless that neither 'first' nor 'last' nor 'nextIndex' are required by the ZPT spec (http://www.zope.org/Wikis/DevSite/Projects/ZPT/RepeatVariable). Hence, Zope 3 just doesn't have them. I can still see a use case for 'first' and 'last' which is why I'll do my best to continue to support them. This is a case for *expanding* what Z3 has: and expanding the spec... it isn't right by default, you know, especially when it comes to pieces of Z2 technology which it has forked. Oh, I know. That's why I was actually going back to the spec since that's what counts at the end of day. For instance, I know of several DTML fixes done since Z3 forked off zope.documenttemplate: they should be forward-ported, but may languish due to lack of care. You're comparing apples and oranges. DTML was maintained in Zope 2 and never really needed in Zope 3. ZPT on the other hand was mostly maintained in Zope 3. Plus, the goal is to use the Zope 3 implementation everywhere so there must be some advantages in the Zope 3 implementation over the Zope 2 one... otherwise we wouldn't be doing this... ZPT is different: is has been in heavy production use, with *lots* more attention to real world use cases than the Z3 version would have gotten until only recently. Let's use some caution about harmonizing the two. Sure. That's why I'm discussing these things here... Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testExpressions.py Fix a test that was testing wrong behaviour: primitive types
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Log message for revision 68244:
Fix a test that was testing wrong behaviour: primitive types
werent' called if they were the result of a path expression, while
all other callables were called. This tests now tests the correct
behaviour (which happens to be already implemented by the Zope 3
TALES engine)
+assert ec.evaluate('x | python:int') == 0
Wait a minute -- that isn't a path expression there!
Yes it is. This line could explicitly written as:
assert ec.evaluate('path: x | python:int') == 0
The python: expression is just part of the path expression.
The '|' is not supposed to change the rules for evaluation of the
subexpressions!
It doesn't change the rules for the evaluation of the subexpressions
themselves. But it might easily change the rules of what happens to the
result of the expression afterwards.
If
'int' or the like were somehow avaialbe at module scope, or via
'options' or another top-level name, then they should be called *when
they are the last item in a path expression*.
The test was actually correct beofore: because tne PathExpression, 'x',
raises, the PythonExpression, 'int', is evalutated. The result of a
subexpression is not suppoeed to be called,
No, not the result of a subexpression, but the result of the overall
path expression. That's how it works in both Zope 2 and Zope 3. Zope 2
just special-cases primitive types.
If a subexpression returns a callable, you're telling me that you think
the top-level expression is supposed to call it? That's nuts! The
spec[1] says:
When a TALES path expression is evaluated, it attempts to traverse
each path, from left to right, until it succeeds or runs out of
paths. To traverse a path, it first fetches the object stored in the
variable. For each path segment, it traverses from the current object
to the subobject named by the path segment.
Once a path has been successfully traversed, the resulting object is
the value of the expression. If it is a callable object, such as a
method or class, it is called. The semantics of traversal (and what it
means to be callable) are implementation-dependent.
If a traversal step fails, evaluation immediately proceeds to the
next path. If there are no further paths, an error results.
Calling the callable happens *before* attempting alternate expressions,
not after. That is partly because the *call* might be what triggers
the alternation.
[1]
http://www.zope.org/Wikis/DevSite/Projects/ZPT/TALES%20Specification%201.3
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEciCT+gerLs4ltQ4RAhesAKDHpp1+XJRukZfRgp/wBrDyBA3/HACfRj4P
k20UEFCRTzu++Bcyp015JDE=
=nmpz
-END PGP SIGNATURE-
--
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py Officially deprecate the BBB methods on the iterator and add a note
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: Philipp von Weitershausen wrote: Philipp von Weitershausen wrote: Tres Seaver wrote: +@deprecate(The 'first' method has been deprecated and will disappear + in Zope 2.12. Use the 'start' property instead.) def first(self, name=None): if self.start: return True return not self.same_part(name, self._last, self.item) +@deprecate(The 'last' method has been deprecated and will disappear + in Zope 2.12. Use the 'end' property instead.) def last(self, name=None): if self.end: return True I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html): This sounds sensible. Thanks for the pointer. I'll undeprecate them :). I'll add nonetheless that neither 'first' nor 'last' nor 'nextIndex' are required by the ZPT spec (http://www.zope.org/Wikis/DevSite/Projects/ZPT/RepeatVariable). Hence, Zope 3 just doesn't have them. I can still see a use case for 'first' and 'last' which is why I'll do my best to continue to support them. This is a case for *expanding* what Z3 has: and expanding the spec... it isn't right by default, you know, especially when it comes to pieces of Z2 technology which it has forked. Oh, I know. That's why I was actually going back to the spec since that's what counts at the end of day. For instance, I know of several DTML fixes done since Z3 forked off zope.documenttemplate: they should be forward-ported, but may languish due to lack of care. You're comparing apples and oranges. DTML was maintained in Zope 2 and never really needed in Zope 3. ZPT on the other hand was mostly maintained in Zope 3. Not really. It was forked, but had very little maintenance on either side, actually. The Z3 version is *known* to be missing a few features of the Z2 version. Plus, the goal is to use the Zope 3 implementation everywhere so there must be some advantages in the Zope 3 implementation over the Zope 2 one... otherwise we wouldn't be doing this... We want *one* implementation, preferably with all the advantages / features needed by both forks. ZPT is different: is has been in heavy production use, with *lots* more attention to real world use cases than the Z3 version would have gotten until only recently. Let's use some caution about harmonizing the two. Sure. That's why I'm discussing these things here... Yup, agreed. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEciDG+gerLs4ltQ4RAq7cAKDD1A9Gs5OgP8YiI9W9Ny/W2tksKwCgvIKp LYflg/ttuoojtOZ1GSWxBjw= =hfEH -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] url with space %20 on end fails
Erik Dahl wrote at 2006-5-12 10:07 -0400: I have an object that has a space at the end of its id (I know this is bogus but I guess its a valid id). its url is: http://zenoss/zport/dmd/Devices/Power/UPS/devices/POB%202nd%20Floor% 20%20 A bug in Zope -- maybe fixed in the meantime as Andreas mentioned. If not, I know where the bug is and can provide a patch. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [ZWeb] zope.org misused for Pharmaceuticals
Andreas Jung wrote: Since some days I have seen several member accounts being used as platform for pharmaceutical ads...what can we do against this? Would it make sense to revoke the View permission from Authenticated users for unpublished content? ANdreas I check new and edited objects on a daily basis and delete ad-content and in severe cases disable member accounts. Authenticated users should not be able to view objects in private state. If you have a few seconds join me in #zope-web. Michael -- http://zope.org/Members/d2m http://planetzope.org ___ Zope-web maillist - Zope-web@zope.org http://mail.zope.org/mailman/listinfo/zope-web
[Zope] Error Value: Can't pickle objects in acquisition wrappers
Hi,
I have a product with a container class to save a list of groups and
others objects..
The container class is:
class StorageAdapter(ObjectManager, BasicUserFolder):
this class have a function to add groups like that:
def addGroup(self, id=, nombre=, REQUEST =None):
to add a new group
#create a group
grupo = Group(id, nombre)
#add a group to container
try:
self._objects=self._objects+
({'id':id,'meta_type':Group.meta_type},)
self._setOb(id,grupo)
object=self._getOb(id)
self._p_changed = 1
except: return MessageDialog(
title ='error',
message='error al añadir grupo',
)
if REQUEST is not None:
REQUEST['RESPONSE'].redirect(self.absolute_url()+'/gestGroupForm')
The class group is simple like this.
class Group(ObjectManager, BasicUserFolder):
Class Group
meta_type = 'Group'
title='Grupo'
def __init__(self, id, nombre):
_debug(init del Group)
self.id=id
self.nombre=nombre
#acl to control this group
f=AclUserFolder()
_debug(creo el acl del Group)
try:self._setObject('acl_users', f)
except: return MessageDialog(
title ='error Acl Existente',
message='Este Group ya contiene un ACL',
)
self.__allow_groups__=self.acl_users
...
...
...
the function addGroup is called from a dtml and the groups are added ok
and later I can view the result perfectly in dtml, but i want to add a
new attribute to class group then in the method __init__ i have add the
sentence:
self.contacts=[]
this is the only change and then i obtain this error:
2006-05-22T16:29:14 ERROR Zope.SiteErrorLog
http://localhost:8080/prueba/ST/addGroup
Traceback (most recent call last):
File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 119, in
publish
transactions_manager.commit()
File /usr/lib/zope/lib/python/Zope2/App/startup.py, line 234, in
commit
transaction.commit()
File /usr/lib/zope/lib/python/transaction/_manager.py, line 84, in
commit
self.get().commit(sub)
File /usr/lib/zope/lib/python/transaction/_transaction.py, line 381,
in commit
self._saveCommitishError() # This raises!
File /usr/lib/zope/lib/python/transaction/_transaction.py, line 379,
in commit
self._commitResources()
File /usr/lib/zope/lib/python/transaction/_transaction.py, line 424,
in _commitResources
rm.commit(self)
File /usr/lib/zope/lib/python/ZODB/Connection.py, line 462, in
commit
self._commit(transaction)
File /usr/lib/zope/lib/python/ZODB/Connection.py, line 503, in
_commit
self._store_objects(ObjectWriter(obj), transaction)
File /usr/lib/zope/lib/python/ZODB/Connection.py, line 525, in
_store_objects
p = writer.serialize(obj) # This calls __getstate__ of obj
File /usr/lib/zope/lib/python/ZODB/serialize.py, line 330, in
serialize
return self._dump(meta, obj.__getstate__())
TypeError: Can't pickle objects in acquisition wrappers.
i don't known where can be my error, if someone can help me.
thank
jose carlos
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Error Value: Can't pickle objects in acquisition wrappers
At Monday 22/5/2006 12:24, jose carlos wrote:
I have a product with a container class to save a list of groups and
others objects..
TypeError: Can't pickle objects in acquisition wrappers.
That means that you have an object with an attribute that is
acquisition-wrapped.
That is, self.xxx is not a pure object but has an acquisition wrapper.
From the posted code it is not clear, but:
f=AclUserFolder()
try:self._setObject('acl_users', f)
might fail is AclUserFolder() returns an existing, wrapped, user folder.
Or maybe id,nombre are not exactly what you expect.
The error message is not very informative, try adding at least
object._p_oid to see which object is failing.
Gabriel Genellina
Softlab SRL
_
Horóscopos, Salud y belleza, Chistes, Consejos de amor:
el contenido más divertido para tu celular está en Yahoo! Móvil.
Obtenelo en http://movil.yahoo.com.ar
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Error Value: Can't pickle objects in acquisition wrappers
jose carlos wrote at 2006-5-22 17:24 +0200: I have a product with a container class to save a list of groups and others objects.. You must take care not to store values containing (or being) AcquisitionWrappers in attributes of persistent objects. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] REMOTE_USER Security Issue
Cliff Ford wrote at 2006-5-14 23:39 +0100: ... My problem is that I figured out how a user who has permission to create python scripts (might work with dtml and page templates too) could access otherwise forbidden content by making calls that pretend to come from another user. Has any one else come across this problem and devised a solution, either in software or organisation? Problem verified with Zope 2.9.2 and latest RemoteUserFolder. That surprises my -- unless the user can create AccessRules: Usually, authentication is performed before any PythonScript is executed. I know only one exception: AccessRules -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
