Ian Bicking wrote:
It would be a concern if, for instance, Plone started depending on
buildout recipes for installation, without "plain" distutils recipes. Of
course right now there are no distutils recipes for old-style Products.
So actually it's an active issue -- if buildout enables Plone t
On 25 Jan 2007, at 23:13 , whit wrote:
The point is that buildout *already* handles eggs. There's really
no point for having an extra layer on top of buildout. The
zc.recipe.egg recipe can install any egg (as a development one or
not) in an automated fashion, which is exactly what you'd want
whit wrote:
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
This is awesome, and by that I don't mean the fact that we have a
plone buildout, but that we actually have Zope 2 recipes for
buildout. I hope they can be moved to svn.zope.org for further
development to benefit the
Rocky Burt wrote:
On Thu, 2007-25-01 at 05:07 -0800, Martin Aspeli wrote:
I do wonder what would happen if you had both lib/python/Products/CMFCore
and Products/CMFCore, though. Would there be an explicit preference or would
Zope fail to start up with a conflict? I think I'd prefer the latter, i
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
For their upcoming versions, Zope 2 consuming platforms such as Plone
are creating standard Zope3-style Python packages while still having
Zope 2 products around. This proposal aims at unifying the deployment
of products and Python packages
Daniel Nouri wrote:
Philipp von Weitershausen wrote:
For their upcoming versions, Zope 2 consuming platforms such as Plone
are creating standard Zope3-style Python packages while still having
Zope 2 products around. This proposal aims at unifying the deployment
of products and Python packages
This proposal aims at bringing Zope 2 a bit closer to Zope 3 by making
the widely used Acquisition API aware of Zope 3's __parent__ pointers.
This will alleviate the need of using Acquisition base classes in Zope 2
for every security-sensitive object, be it persistent or just a
dynamically look
On 23 Jan 2007, at 23:56 , Martin Aspeli wrote:
Philipp von Weitershausen wrote:
This is awesome, and by that I don't mean the fact that we have a
plone buildout, but that we actually have Zope 2 recipes for
buildout. I hope they can be moved to svn.zope.org for further
developme
For their upcoming versions, Zope 2 consuming platforms such as Plone
are creating standard Zope3-style Python packages while still having
Zope 2 products around. This proposal aims at unifying the deployment
of products and Python packages into a Zope 2 instance alike by using
Python eggs and th
Martin Aspeli wrote:
I've been playing with this a bit over the past couple of days, and it's
now in a state where I understand what's going on and I feel that I may
well try to use it in a real project. It still needs a bit of work
(notably, the testrunner is struggling to run tests for things
Andreas Jung wrote:
I added/extended some tests that will fail because of errors in Zope.
One failure is related to the FTP acquisition bug (#2261). Two other
failures are related to rendering ZPTs with content_type text/xml.
The latter two failures are gone now.
--
http://worldcookery.com
Grig Gheorghiu wrote:
I'm trying to check out zope.interface for one of the tests I'm running
for Twisted in the Pybots project. I've been getting an error lately:
[EMAIL PROTECTED] tmp]$ svn co
svn://svn.zope.org/repos/main/zope.interface/trunk zope.interface
A zope.interface/buildout.cfg
A z
Chris Withers wrote:
Stephan Richter wrote:
If you are populating the CA before ZCML is fully parsed, then:
Why is the CA predicated on ZCML?!
It's not. And Stephan's "Collect all registrations before executing
them!" isn't actually necessary either (it's just necessary for conflict
resolu
Dieter Maurer wrote:
I tried to use Zope3 events to get informed when requests start and end.
One of our modules (the interface module to "jpype") requires such
a notification for reliable work. Therefore, it tried to register
the corresponding subscriptions on import of this module.
That is a
yuppie wrote:
Hi!
Andreas Jung wrote:
I plan to release Zope 2.10.2 in a week or so (don't nail
me to a particular date).
The Zope 2.10 branch still uses Five 1.5.1. There are a few changes on
the Five 1.5 branch (including a security fix) which should become part
of Zope 2.10.2.
I volun
On 7 Jan 2007, at 20:44 , Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Andreas Jung wrote:
I added Products/PageTemplates/configure.zcml to register an
utility.
That works fine when running Zope however "zopectl test" won'
Andreas Jung wrote:
I added Products/PageTemplates/configure.zcml to register an utility.
That works fine when running Zope however "zopectl test" won't work
properly anymore because the utility registration does not seem to
happen when running the tests. Bug or feature?
Tests need to do thei
Chris Withers wrote:
I don't know how easy this is to do, but one thing that would be
_really_ nice would be to use an existing compatible python install
rather than Zope splatting it's own in regardless.
-1
That's what Zope 3 does (it's a standard distutils installer). It makes
it hard to i
Sidnei da Silva wrote:
I was wondering why there is no easy way to register a view for an
exception in Zope 2 yet (not even in Zope 2.10!).
Because nobody has refactored Zope 2 to support this yet...
There is a product in the z3-base called FiveException:
http://codespeak.net/svn/z3/FiveExce
Andreas Jung wrote:
Andreas Jung wrote:
What are our benefits from a Z2 Eggification. Eggification is basically
about packaging and distribution of components with little dependencies
in order to re-use them in other contexts. However most components of
Zope 2 are heavily dependent on others.
Lennart Regebro wrote:
I don't mind making Products.Five smaller. And I don't mind making
loads of small packages called five.something either.
That said, I think it's important to make as much of zope3 work under
zope2, so any zope3 package included in the zope2 distribution should
also have it
Andreas Jung wrote:
What are our benefits from a Z2 Eggification. Eggification is basically
about packaging and distribution of components with little dependencies
in order to re-use them in other contexts. However most components of
Zope 2 are heavily dependent on others.
Yes, that's true. B
yuppie wrote:
Tres Seaver wrote:
Test failures
-
Subject: FAILED (errors=1) : Zope-trunk Python-2.4.3 : Linux
From: Zope Unit Tests
Date: Mon Oct 23 21:35:18 EDT 2006
URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006371.html
First, thanks for resuming this collected r
yegor wrote:
I installed Plone 2.5 but it seems that the issue is Zope-related, so I'm
posting it here should I go for a different mailing list?)
I suggest using a Plone users mailinglist. This is definitely the wrong
list, it's for the development OF Zope, not for the development WITH
Zope.
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200:
...
I find that the introduction of classes with (multiple) inheritance
has been very economic. It was another concept but a highly fruitful
one, despite the fact that they are not so liked in Zope3 land.
I think
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-30 02:30 +0200:
...
You want to stick this interface to individual objects,
while Lennart proposed to stick it to a type and use
some kind of inheritance to make it effective on all objects
instantiated from this type.
But where
Lennart Regebro wrote:
Types in Zope 3 are typically expressed by interfaces.
Yes, and that would most likely be the case here too. Most likely
which "type" and object is would be expressed by letting that object
have a specific interface. This does not make "interface" and "type"
conceptually
Christopher Lozinski wrote:
I do like the idea of ZClasses as a separate product.
Good! Then let's move it out of the Zope 2 trunk.
Actually I think all of Zope should be an assembly of separate products.
I would love to see multiple flavors of Zope each as an assembly of
separate products.
Andreas Jung wrote:
--On 29. September 2006 02:23:13 +0200 Philipp von Weitershausen
<[EMAIL PROTECTED]> wrote:
Dieter Maurer wrote:
Also the thread that ZClass (re)distribution code will be removed
need not worry you too much. Fortunately, Zope is open source
and you can simply combi
Lennart Regebro wrote:
On 9/29/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
You want to stick this interface to individual objects,
while Lennart proposed to stick it to a type and use
some kind of inheritance to make it effective on all objects
instantiated from this type.
For me, Lennart's ap
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-29 01:35 +0200:
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-28 14:23 +0200:
...
Why not set marker interfaces directly on the objects? That whole "type"
thing is unnecessary. Just use interfaces.
Dieter Maurer wrote:
Also the thread that ZClass (re)distribution code will be removed
need not worry you too much. Fortunately, Zope is open source
and you can simply combine the new release with pieces of an older
release to retain features essential to you.
I see no problem in making the "ZC
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-28 14:23 +0200:
...
Why not set marker interfaces directly on the objects? That whole "type"
thing is unnecessary. Just use interfaces.
Usually, a type is seen as a set of objects, its type instances.
It is quite nice
Lennart Regebro wrote:
On 9/27/06, Andreas Jung <[EMAIL PROTECTED]> wrote:
It's definitely time to work on a replacement.
Yes. And here is my short vision of that. Comments are appreciated.
Have you looked at zope.app.schemacontent, Sidnei's prototype for
TTW-schemas and content based on th
Christopher Lozinski wrote:
I think that there is a different tool for every job. Sometimes I think
Plone is the best solution, sometimes Zope 2 is the best solution.
Sometimes Zope 3is the best solution, and sometimes ZClasses are the
best solution.
Yes, you're right about different tools
Christian Heimes wrote:
Zope's security declarations have to be called with a method *name* AS
STRING. Developers are human beeings and human beeings tend to make
small errors like typos. Or they forget to change the security
declaration when they rename a method. Zope doesn't raise an error when
Hey Christian, welcome back! :)
Christian Heimes wrote:
Lennart Regebro schrieb:
You have many good points in your list of troubles. Many of them are
resolved by using security declarations through ZCML instead. It would
be interesting to here your views on this.
In general I preferre old and
Stefan H. Holek wrote:
Log message for revision 70218:
"Backport" testrunner from 2.10 branch.
Changed:
_U Zope/branches/2.9/lib/python/zope/
-=-
Property changes on: Zope/branches/2.9/lib/python/zope
___
Name: svn:externals
AFAIK, Stefan Hollek checked it in to demonstrate an incompatibility of
Zope 2.10 vs. 2.9. See http://www.zope.org/Collectors/Zope/2187.
Andreas Jung wrote:
Those two tests are currently failing on the 2.10 branch (updated with
the Zope 3.3.0rc1 code). Any hints?
Andreas
---
E
Martijn Faassen wrote:
I don't have time for a discussion right now as I'm off to Germany soon.
The one thought that strikes me is that these release management notes,
when finalized, should be in some clear, findable, well-known and
maintained location. Otherwise we'll forget again. I know, th
Andreas Jung wrote:
>
>
> --On 29. August 2006 18:50:43 +0200 Dieter Maurer <[EMAIL PROTECTED]>
> wrote:
>
>> Jens Vagelpohl wrote at 2006-8-28 20:14 +0200:
>>> On 28 Aug 2006, at 19:19, Andreas Jung wrote:
>>>
Some time ago the following patch was proposed to control the timing
for op
Kris Adcock wrote:
> --- Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
>> Kris Adcock wrote:
>
>>> I've tried going through the "Undo" procedure, but the idea of manually
>>> ticking 130,000 boxes (in pages of 20) and undoing them fil
Kris Adcock wrote:
> Hiya,
>
> My company has been using a Zope server to store some reference material, but
> it has grown beyond belief, and I need to extract all the collected files
> (about 1.3 terabytes!) from the Data.fs into distinct files onto a different
> server.
>
> Unfortunately, I've
Hi all,
we're having a bugday for the Zope "June" releases this Thursday. Yes,
we know it's August. That's why we need YOUR help to get this release
out quickly.
How can you help? Look at the issue trackers at
http://www.zope.org/Collectors and search for bugs of the 'critical' or
'3.3 release' c
Tres Seaver wrote:
> Andreas Jung wrote:
>>> If there are no objections, I plan to release Zope 2.9.4 in about one
>>> week (likely next Thu or Fri).
>
> Even sooner would be fine with me. I plan to release a 2.8.8 this
> weekend with the changes for the ReST fix (I already released a 2.7.9).
>
Tres Seaver wrote:
> We neeed to do a Zope3 3.2.2 release to go along with 2.9.4
Why?
___
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
Tres Seaver wrote:
> svn: URL
> 'svn+ssh://svn.zope.org/repos/main/Zope/branches/tseaver-retire_zpkg/lib/python/zope/app'
> doesn't match existing URL
> 'svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.1/src/zope/app' in
> 'lib/python/zope/app'
>
> I may have to munge 'zope/app' manually and ch
Tres Seaver wrote:
> I've now done the same work on a branch for that tree:
>
> [/home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10]
> $ head .svn/entries
>
> xmlns="svn:">
> committed-rev="68857"
> name=""
> committed-date="2006-06-26T21:16:14.182239Z"
>
> url="svn+s
Chris Withers wrote:
> Philipp von Weitershausen wrote:
>> Chris Withers wrote:
>>> Florent Guillaume wrote:
>>>> Chris Withers wrote:
>>>>> Both core zope and Plone spew forth in their default state.
>>>> Zope 2.10 does? It shouldn&#
Dieter Maurer wrote:
> Philipp von Weitershausen wrote at 2006-6-24 20:03 +0200:
>> ...
>> c) are so much core to Zope 3 that they don't make sense in Zope 2 (such
>> as twisted, securitypolicy)
>
> When I remember right, we should get "twisted" in Zo
Tres Seaver wrote:
> That will be good. Even after eliminating the list you provided (see
> below), there is still a lot of stuff in zope.app which is irrelevant to
> Zope2 (I think).
Agreed. By the way, I just compated a Zope 2.9.3 install with your
tarball. The same comparison should be done ag
Tres Seaver wrote:
> The point is that the "release" tarball should generate the same
> environment that the developers routinely work in; otherwise, we leave
> the poor suckers who install from it stuck with whatever bugs are caused
> by the difference.
Ok. I'll note that Python eggs don't fulfi
Tres Seaver wrote:
>>> Since you're denoting this as a "current version number", do I take it
>>> that you're planning on changing the way Zope 2.9 and 2.10 releases are
>>> created as well? I would consider egg-based deployment a feature; at
>>> least it's a big enough change that I'd be worried f
Tres Seaver wrote:
>>> I believe that the extra flexibility which zpkg is intended to provide
>>> (dependency-based subset distributions, primarily) would be better
>>> served by moving Zope to use eggs,
Where are the eggs, btw?
> I will be ready shortly to merge this branch to the 2.9 branch, th
Tres Seaver wrote:
> Log message for revision 68810:
> Note dropping of 'zpkg'; use a current version number.
>
> Changed:
> U Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt
> U Zope/branches/tseaver-retire_zpkg/setup.py
>
> -=-
> Modified: Zope/branches/tseaver-retire_zpkg/doc/CHAN
Dieter Maurer wrote:
> Philipp von Weitershausen wrote at 2006-6-22 09:03 +0200:
>> Dieter Maurer wrote:
>> ...
>>> If you are working on it, then you should implement a
>>> means that "__bobo_traverse__" can tell the caller that
>>> it should us
Tres Seaver wrote:
> I believe that the extra flexibility which zpkg is intended to provide
> (dependency-based subset distributions, primarily) would be better
> served by moving Zope to use eggs, and that we should thus retire zpkg
> as the means for building Zope2 releases.
+1
Dieter Maurer wrote:
> Florent Guillaume wrote at 2006-6-18 02:05 +0200:
>> ...
>> if hasattr(object,'__bobo_traverse__'):
>> subobject=object.__bobo_traverse__(request, name)
>
> If you are working on it, then you should implement a
> means that "__bobo_traverse__" can
Chris Withers wrote:
> Andreas Jung wrote:
>>
>>> I for one, is NOT interested in backporting fixed in Five trunk to
>>> both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current
>>> versions of Five if we say that Zope 2.8 and 2.7 should be still
>>> supported after the release of 2.10.
Chris Withers wrote:
> Philipp von Weitershausen wrote:
>>
>> Follow this thread:
>> http://mail.zope.org/pipermail/zope3-dev/2005-November/016561.html
>
> *grunt* *sigh*
>
> It has to happen at some stage, surely?
Jim suggested a different strategy with "Z
Chris Withers wrote:
> Florent Guillaume wrote:
>> Chris Withers wrote:
>>> Both core zope and Plone spew forth in their default state.
>>
>> Zope 2.10 does? It shouldn't. Please point out the deprecation
>> warnings it sends.
>
> I, like many people I suspect, am still struggling to get projects
Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
>> Florent Guillaume wrote:
>>> Florent Guillaume wrote:
>>>> So here's a proposal: how about having the following order:
>>>> - __bobo_traverse__
>>>> - unacquired attribute
>
Chris Withers wrote:
> Jens Vagelpohl wrote:
>> Use the collector. It is *the* place where people go to look for
>> things to fix. What length of time it takes to fix is a totally
>> separate issue. Bugs that get posted on mailing lists get ignored
>> unless they are "the world is coming to an end"
Chris Withers wrote:
> Benji York wrote:
>> Philipp von Weitershausen wrote:
>>> Uh, never mind.
>>
>> +1 :)
>
> Any chance you could explain why you feel that way?
Follow this thread:
http://mail.zope.org/pipermail/zope3-de
Chris Withers wrote:
> Philipp von Weitershausen wrote:
>> Note that this should also extend to the Zope 3 releases. Zope 3.2 is
>> part of Zope 2.9 and will hence be used for quite some time. Yet,
>> bugfixes aren't even backported to the Zope 3.2 branch anymore...
&g
Florent Guillaume wrote:
> Philipp von Weitershausen wrote:
>> Lennart Regebro wrote:
>>> On 6/18/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
>>>>> The remaining important question is: if a *default* view is specified
>>>>> usin
Lennart Regebro wrote:
> On 6/18/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
>> > The remaining important question is: if a *default* view is specified
>> > using the zope 3 mechanism, should we always treat it as a zope 3 view,
>> > and refuse t
Chris Withers wrote:
> Tres Seaver wrote:
>> Unit test coverate for custom products is actually quite good. The
>> problems are nearly always to do with "third party" products, many of
>> which have been in "useful stable" mode since long before either
>> deprectaions or ubiquitous unit testing we
Florent Guillaume wrote:
> Florent Guillaume wrote:
>> So here's a proposal: how about having the following order:
>> - __bobo_traverse__
>> - unacquired attribute
>> - zope 3 views
>> - acquired attributes
>
> Attached is the current diff I'm working with (for Zope 2.10).
Hey, cool. You know, th
Dieter Maurer wrote:
>> * cutting down the amount of code duplication and duplicated frameworks.
>>
>> We've had two ZPT implementations, now we have to maintain only one. We
>> had our own logging framework, now we can simply use Python's, etc.
>
> The second logging framework ("zLOG") was a tiny
Andreas Jung wrote:
> My recommendation:
>
> 1 yr deprecation period as it is now
> 1 yr + X maintenance period for older branches.
+1
Note that this should also extend to the Zope 3 releases. Zope 3.2 is
part of Zope 2.9 and will hence be used for quite some time. Yet,
bugfixes aren't even back
Chris McDonough wrote:
> On Jun 15, 2006, at 3:13 AM, Philipp von Weitershausen wrote:
>> We've had two ZPT implementations, now we have to maintain only one. We
>> had our own logging framework, now we can simply use Python's, etc.
>> These changes may seem cosmet
Tres Seaver wrote:
> Lennart Regebro wrote:
>>> On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> wrote:
The time-based release cycle just amplifies this across many branches
and point releases, so nobody really knows which products work with
what branch/release and under what configur
Dieter Maurer wrote:
> Chris Withers wrote at 2006-6-14 07:32 +0100:
>> ...
>> Would be interested to know what other people think...
>
> I like time based releases but I hate deprecations
> for "cosmetic annoyances" (term stolen from Andreas).
>
> I have the feeling that most deprecations so far
e wrong, I'm not complaining. I'm just
trying to improve things.
> Next thing you are going to remove implicit acquisition ;-).
Nope :).
> On 28. Mai 2006, at 12:53, Philipp von Weitershausen wrote:
>
>> That's true. However, we really want the Zope 2 request
Tres Seaver wrote:
> Florent Guillaume wrote:
>>> Log message for revision 68445:
>>> Revert unwanted checkin.
>>>
>>>
>>> Changed:
>>> U Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py
>>>
>>> -=-
>>> Modified:
>>> Zope/branches/2.10/lib/python/Products/PageTemplates/
Florent Guillaume wrote:
> On 1 Jun 2006, at 17:53, Philipp von Weitershausen wrote:
>> Florent Guillaume wrote:
>>> Log message for revision 68446:
>>> Make python security policy work with a boolean __aatus__
>>
>> Wow, I wasn't aware tha
Philipp von Weitershausen wrote:
> Florent Guillaume wrote:
>> The following TALES expression using the 'item' name doesn't work:
>>
>> python:repeat['item'].even()
>> Unauthorized: The container
Florent Guillaume wrote:
> Log message for revision 68446:
> Make python security policy work with a boolean __aatus__
Wow, I wasn't aware that only ints were possible. Shouldn't this be
backported to Zope 2.9 as well? I consider it a bug when an 1 won't be
exchangeable for True in something tha
Florent Guillaume wrote:
> The following TALES expression using the 'item' name doesn't work:
>
> python:repeat['item'].even()
> Unauthorized: The container has no security assertions. Access to
> 'even' of (Products.PageTemplates.Expressions.PathIterator object at
> 0x47986f0) denied.
>
> w
Andreas Jung wrote:
> I plan to create a branch for Zope 2.10 after 2.10beta 2 or short before
> the 2.10 final release. This means that the Zope trunk should only be
> used for bugfixes *only* until the branch is cut. So no new development
> and feature should happen on the trunk until then..Use y
The Five team is happy to announce the release of two Five bugfix
releases, 1.2.5 and 1.3.6, a Five 1.4 final release and another Five
1.5c beta release today.
What is Five
Five is a Zope 2 product that allows you to integrate Zope 3
technologies into Zope 2, today. Among others, i
Tres Seaver wrote:
>>> Basically:
>>>
>>> * we hardly see a use case for empty path elements. They don't work
>>> right now, at least not in the way that you expected them to work. So,
>>> we're not really breaking anything if we take away something that didn't
>>> work in the first place.
>
> The
Tres Seaver wrote:
> Philipp von Weitershausen wrote:
>
>>> Log message for revision 68328:
>>> A recent fix in the zope 3 traversing code now requires the ITraversable
>>> adapter to be present even when traversing just dicts. No problem, we
Chris McDonough wrote:
>> As said, I think the first step towards unifying the request interfaces
>> would be to deprecate the __getattr__ protocol for request variables. I
>> think we should start with Zope 2.11.
>
> I'm sure you know this, but I wanted to point out that doing this will
> break a
Lennart Regebro wrote:
> On 5/27/06, Rocky Burt <[EMAIL PROTECTED]> wrote:
>> I've heard rumours that ultimately the preferred manner of integration
>> of z2 and z3 requests was to replace the z2 ZPublisher with the z3
>> zope.publisher.
>
> Well, that would not necessarily mean that the requests
Tres Seaver wrote:
> 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
Tres,
I've thought about this some more and chatted with Fred. Here's what I
think:
>> 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 /, t
Tres Seaver wrote:
> Philipp von Weitershausen wrote:
>>> Philipp von Weitershausen wrote:
>>>
>>>> Tres Seaver wrote:
>>>>
>>>>>>> +@deprecate("The 'first' method has been deprecated and will
>>>
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 cal
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 in
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
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
Philipp von Weitershausen wrote:
> http://svn.zope.org/Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testDTMLTests.py?rev=68229&view=auto
> http://svn.zope.org/Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testHTMLTests.py?rev=68230&a
Hi,
as some of you might have seen from the checkins, I'm trying to complete
Andreas's work of bringing the Zope 3 ZPT engine to Zope 2.
Andreas has done a great job dealing with the very non-trivial unicode
and persistency-compabitibility issues already. I've taken over since to
fix up Five acco
Paul Winkler wrote:
>> I'm not sure if 2.5 implements ZDOM. If so, has anyone used it yet?
>> If someone has used it, then perhaps that someone could send me a code
>> snippet as an example?
>
> Personally I've never seen ZDOM before.
You haven't missed anything :).
> AFAICT from a very brief
Florent Guillaume wrote:
> We can't potentially break currently perfectly working applications.
> I'd propose either:
>
> - introduce a config flag somewhere (zope.conf), off by default,
> switching the zope 2 REQUEST.debug to not using form/cookies/others but
> the proper attribute that zope 3 exp
Chris Withers wrote:
> Philipp von Weitershausen wrote:
>> Philipp von Weitershausen wrote:
>>> Several components that we'd like to use in Zope2, such as the
>>> SequenceEngine from Zope3,
>>
>> That's meant to say SequenceWidget, and we alr
Jim Fulton wrote:
> Philipp von Weitershausen wrote:
>> Jim Fulton wrote:
>>
>>> It would be helpful if the authors of the branches listed on:
>>>
>>> http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/Tasks
>>>
>>> would update the pa
Jim Fulton wrote:
> It would be helpful if the authors of the branches listed on:
>
> http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/Tasks
>
> would update the page by either deleting their branch or giving
> a realistic estimate of when it will be ready. It's
> a good idea to be conserva
201 - 300 of 474 matches
Mail list logo
