Hi there,
quick reminder for all of you who have Zope 2.9 branch checkouts: There
has been a change (finally!) in the release branch naming scheme. The
2.9 branch was renamed to Zope/branches/2.9 as a result. This will be
the naming scheme for all release branches in Zope 2 and 3 from now on.
Log message for revision 40158:
Name the root collection simply Zope so that the name of the tarball will
be decent. This doesn't conflict with the collection representing the 'zope'
package because the *root* collection and a dependency of it never have to
coexist as sibling directories
Log message for revision 40159:
Merge r40158 from the trunk:
Name the root collection simply Zope so that the name of the tarball will
be decent. This doesn't conflict with the collection representing the
'zope'
package because the *root* collection and a dependency of it never
Andreas Jung wrote:
--On 16. November 2005 14:03:05 -0500 Jim Fulton [EMAIL PROTECTED] wrote:
Does this mean that the existing 2.9 branch needs to be removed and that
the trunk remains frozen?
Didn't Florent delete the branch? Obviously he did not as I assumed.
So in this case Philipp
Log message for revision 40126:
Only include *.py files for the scripts (in particular, DON'T include
the ZODBTools directory which was previously caught up in the '*' glob
and confused zpkgsetup).
Also include ZODBTools scripts (again, only *.py files).
Changed:
U
Log message for revision 40127:
Merge r40126 from the trunk:
Only include *.py files for the scripts (in particular, DON'T include
the ZODBTools directory which was previously caught up in the '*' glob
and confused zpkgsetup).
Also include ZODBTools scripts (again, only *.py
Tres Seaver wrote:
Log message for revision 40092:
Don't hard-wire forward-slash into sys.path (redux).
Please don't forget to merge this and the previous rev to the Zope 2.9
branch. From now on, both the trunk and the 2.9 branch need to be taken
care of.
Philipp
Florent Guillaume wrote:
BTW I'm for removing the 2.9 branch for now.
You didn't, so I presume 2.9 branch stays? It's important to clear the
status of this branch because bugfixes need to be merged to it (see my
email about Tres' bugfix, for example).
By the way, in the future, just to avoid
Andreas Jung wrote:
--On 15. November 2005 00:20:00 +0800 Philipp von Weitershausen
[EMAIL PROTECTED] wrote:
Florent Guillaume wrote:
BTW I'm for removing the 2.9 branch for now.
You didn't, so I presume 2.9 branch stays? It's important to clear the
status of this branch because
Log message for revision 40048:
use a specific revision of the Zope 3 trunk for now until we have some sort
of tag
available (e.g. a Zope 3.2 beta tag).
Changed:
_U Zope/trunk/lib/python/
_U Zope/trunk/lib/python/zope/
-=-
Property changes on: Zope/trunk/lib/python
yuppie wrote:
Philipp von Weitershausen wrote:
Log message for revision 39903:
- converted interface to z3 interface.
Changed:
D Zope/trunk/lib/python/AccessControl/IUserFolder.py
I think we should maybe leave the Zope 2 interfaces around for at least
one release. People
Yvo Schubbe wrote:
Log message for revision 39903:
- converted interface to z3 interface.
Changed:
D Zope/trunk/lib/python/AccessControl/IUserFolder.py
I think we should maybe leave the Zope 2 interfaces around for at least
one release. People with custom user folder implementations
Jim Fulton wrote:
We need to stitch zope.app into Zope 2 more carefully than we
are now. Much of what we are stitching is unreleased in Zope3
and depends on things not stitched nto Zope 2.
Among other things, this means that we can't use
python2.4 test.py -m.
to run all tests
yuppie wrote:
* Moved to a zpkgutils-based build system, as the Zope 3.2 extension
modules
require to be built with it. If everything goes ahead as planned,
the release
tarball will also be built with zpkgutils (some work has also been
done in
that direction).
That part
Philipp von Weitershausen wrote:
That worked for me (though I usually don't do the configure; make dance,
but just do an in-place build with python setup.py build -i; see also
below).
Sorry, I meant
$ python setup.py build_ext -i
That's what make all does on Zope 3 and now on Zope 2
Jim Fulton wrote:
What changes are those? A fresh Zope trunk checkout works for me. Here's
what I did:
$ svn co svn+ssh://[EMAIL PROTECTED]/repos/main/Zope/trunk
Zope-trunk
$ cd Zope-trunk
$ ./configure
$ make
That worked for me (though I usually don't do the configure; make
be
nested). Thanks to Sidnei da Silva for the initial development back
in March, Lennart Regebro and Philipp von Weitershausen for bringing
it up to date for inclusion into Five 1.2.
* Improved event support
Five can now make standard Zope 2 containers (aka object managers)
send Zope 3
Log message for revision 39813:
the skeleton dir is called differently in zope 2
Changed:
U Zope/branches/philikon-zope32-integration/releases/Zope2/SETUP.cfg
-=-
Modified: Zope/branches/philikon-zope32-integration/releases/Zope2/SETUP.cfg
Log message for revision 39814:
whitespace
Changed:
U Zope/branches/philikon-zope32-integration/releases/Zope2.map
-=-
Modified: Zope/branches/philikon-zope32-integration/releases/Zope2.map
===
---
Log message for revision 39810:
fix up the syntax of this thing.
also removed duplicate entry on docutils
Changed:
U Zope/branches/philikon-zope32-integration/releases/Zope2.map
-=-
Modified: Zope/branches/philikon-zope32-integration/releases/Zope2.map
Log message for revision 39817:
made the wrong one the module
Changed:
U Zope/branches/philikon-zope32-integration/releases/Zope2.map
-=-
Modified: Zope/branches/philikon-zope32-integration/releases/Zope2.map
===
---
Log message for revision 39771:
update zconfig to 2.3.1 for a zpkg-related case sensitivity fix
Changed:
_U Zope/branches/philikon-zope32-integration/lib/python/
-=-
Property changes on: Zope/branches/philikon-zope32-integration/lib/python
Log message for revision 39740:
Move to Zope 3.2 in the externals. Packages that are new in this since
Zope X3 3.0 are:
- pytz
- zodbcode
- zope.deprecation
- zope.dottedname
- zope.formlib
- zope.index
- zope.testbrowser
Changed:
_U
Log message for revision 39741:
Let's try some zpkg integration. I'll probably fail miserably
Changed:
A Zope/branches/philikon-zope32-integration/buildsupport/
-=-
Property changes on: Zope/branches/philikon-zope32-integration/buildsupport
Log message for revision 39747:
Stab at building through zpkgutils. I don't really know what I'm doing,
though, so it doesn't work yet.
Changed:
A Zope/branches/philikon-zope32-integration/releases/
A Zope/branches/philikon-zope32-integration/releases/Zope2/
U
Log message for revision 39748:
Bring zdaemon external up to speed with the trunk
Changed:
_U Zope/branches/philikon-zope32-integration/lib/python/
-=-
Property changes on: Zope/branches/philikon-zope32-integration/lib/python
Log message for revision 39749:
Don't let zpkgutils go on ZConfig cold turkey
Changed:
A Zope/branches/philikon-zope32-integration/releases/zpkg-support.pth
-=-
Added: Zope/branches/philikon-zope32-integration/releases/zpkg-support.pth
Log message for revision 39751:
point setup.py to the right package location in zope 2.
And ... WOW. it works! Yay.
Changed:
U Zope/branches/philikon-zope32-integration/setup.py
-=-
Modified: Zope/branches/philikon-zope32-integration/setup.py
Hello all,
[Sorry for the cross-post, please CC replies to zope3-i18n@zope.org only.]
two months ago, I started an initiative [1] to translate Zope 3.1 using
Ubuntu's Launchpad system [2]. Since then, I've received a lot of emails
from numerous volunteers around the world and many of them made
Hello all,
[Sorry for the cross-post, please CC replies to [EMAIL PROTECTED] only.]
two months ago, I started an initiative [1] to translate Zope 3.1 using
Ubuntu's Launchpad system [2]. Since then, I've received a lot of emails
from numerous volunteers around the world and many of them made
Thomas Adams wrote:
Hi all,
I'm a newbie to Zope, using version 2.7.3 (okay it is not the newest one)
and I want to know if there is something
like a MVC approach available for Zope, i.e. Model-View-Controller
approach, as it is for instance in Java with the Struts framework from
Apache.
yuppie wrote:
If there are no objections, I'd like to merge two changes into the
Zope-2_8-branch before 2.8.1 is released:
1.) Backports from zope.tal to TAL and a small modification of ustr:
http://svn.zope.org/?rev=37613view=rev
http://svn.zope.org/?rev=37614view=rev
This is a fix
Nicholas Wieland wrote:
First of all thanks everyone for the help, I've resolved my problems one
after the other thanks to the suggestions I've found here.
Now I'm rewriting urls by substituting the href attribute with custom
data, and everything works fine.
What I'd like is having an url
kit blake wrote:
Wow, what a difference two days makes. I heard about the ZF
announcement by telephone two mornings ago, and I breathed a huge sigh
of relief. It solves a problem we've been worrying about for years. It
means we can sit across from a nervous IT director, and when he asks
dubious
Jean-Marc Orliaguet wrote:
This is really great news!
I am going to start working at getting Chalmers to be one of the key
players in the foundation which would make the foundation even more
vendor-neutral. I am confident that this will go through.
This almost sounds as if the Foundation
Jean-Marc Orliaguet wrote:
Philipp von Weitershausen wrote:
Jean-Marc Orliaguet wrote:
This is really great news!
I am going to start working at getting Chalmers to be one of the key
players in the foundation which would make the foundation even more
vendor-neutral. I am confident
Andreas Jung wrote:
--On 17. Juni 2005 13:04:17 +0200 Philipp von Weitershausen
[EMAIL PROTECTED] wrote:
Jean-Marc Orliaguet wrote:
This is really great news!
I am going to start working at getting Chalmers to be one of the key
players in the foundation which would make the foundation even
Chris McDonough wrote:
On Fri, 2005-06-17 at 07:52 -0400, Stephan Richter wrote:
Also, I agree with Andreas and Philipp that developers should be members, not
companies. Otherwise, how could I, as an independent developer, have a say?
BTW, this is also positive for companies, since they can
Five 1.0.1 released!
The Five team is happy to release Five 1.0.1, a bugfix release for
Five 1.0. The most important news is unicode support for add and edit
forms; other minor fixes are included as well. Please consult the
CHANGES_ for more details.
.. _CHANGES:
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
[snip]
Right. Here's what we could do:
1. Copy Five's interface definitions over to Zope 2.8 (mostly to
OFS.interfaces, I guess) where they are added as Zope 2 interfaces
2. Keep Five's (redudant) interface definitions. They can
yuppie wrote:
Proposed Solution
=
1.) Adding ZCML that bridges existing z2 interfaces into the
'interfaces' module of their package. [Zope 2.8.0]
+1
2.) Copying z3 interfaces from Five.interfaces to the 'interfaces'
module of the corresponding package. Marking those in Five as
yuppie wrote:
Current State
=
Five (now part of Zope 2.8) ships with one big interfaces.py file
that contains z3 interfaces for Zope 2 core classes. (There are also
some five specific interfaces in that file, but they are not subject
of this proposal.)
interfaces.zcml states that
Martijn Faassen wrote:
yuppie wrote:
[snip]
This way, all the work that remains for me is to merge in Five 1.0
into Zope 2.8.
My point is:
Doing that in a backward compatible way is impossible. So we have to
do it now or never.
That's true, but it's not that difficult to ask people to change
yuppie wrote:
I don't think we need to break backward compatability. We would just
need to deprecate the Five.interfaces location.
Basically, the goals are:
* The solution needs to work with Zope 2.7
* Preferrably, the interface import spelling should be equal on both
systems (which means a
yuppie wrote:
4.) Making interfaces.zcml point to the new locations. [Five 1.0+]
5.) Adding unit tests that verify interfaces and implementations.
[Zope 2.8.0]
IMHO that's yagni. We actually don't use interfaces that much for
verifying implementations anymore. I think their most common use in
yuppie wrote:
Yes. I still don't see where the need for incompatability is. Maybe
I'm just blind. Can someone explain?
I no longer see a problem. If we make sure the Five interfaces and those
in the Zope tree are the same, there are no incompatibilities.
By the way, I've just merged in Five 1.0
Tres Seaver wrote:
Your unit test should exercise the whole API promised by an
implementation anyway, so often an explicit interface check is redudant
(of course, it can't hurt). verifyClass() per se isn't bad, it's in fact
a useful indicator, but having that it as a *sole* measure whether a
class
Martijn Faassen wrote:
yuppie wrote:
By the way, I've just merged in Five 1.0 into Zope 2.8 (which was a
significant amount of work, due to all kinds of copyright headers
being different).
Can't we use the same headers for Five 1.0 and Zope 2.8? Both releases
are ZPL 2.1, aren't they? Are there
interfaces
were created by Philipp von Weitershausen before Tres implemented the
bridging functionality.
Correct.
2.) Could we move the interfaces that are currently not available as
Zope 2 interfaces to the corresponding packages in Zope 2.8, using
Five/interfaces.py just as an fallback for Zope
yuppie wrote:
Philipp von Weitershausen wrote:
Right. Here's what we could do:
1. Copy Five's interface definitions over to Zope 2.8 (mostly to
OFS.interfaces, I guess) where they are added as Zope 2 interfaces
I would prefer to reserve the name 'interfaces' for Zope 3 interfaces.
So far
Stephan Richter wrote:
Hello everyone,
I just wanted to let you all know that the first book covering Zope 3 hit the
shelves yesterday. It is called the Zope 3 Developer's Handbook and was
published by Sams' Developer's Library.
Link to Sams Web-Site:
Sorry for the flooding, it seemed that GMane rejected my messages
because my computer clock was set month ahead (no idea why) while in
fact the messages were posted. Philipp.
___
Zope-Dev maillist - Zope-Dev@zope.org
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
I chose alternative 4 from:
http://dev.zope.org/Zope3/RenameTheZopePackage
As that seemed to be the most popular, although I personnally prefer
3.
Resolving this peacefully is becoming more urgent for me as I'd
like to be able to use
Jim Fulton wrote:
Historically, we've had Packages, Products, Packages3 and Products3
directories in the CBS repository. I wonder of we need these going
forward. Perhaps we should just have top-level projct directories
in the new subversion repository.
+1
Philipp
Andreas Kostyrka wrote:
On Sun, Apr 25, 2004 at 12:48:30PM -0400, Fred Drake wrote:
On Sunday 25 April 2004 12:29 pm, Jim Fulton wrote:
cvs co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3
That should be:
svn co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3
cvs co
Jim Fulton wrote:
2. Especially Andreas expressed his worries about the current release
policy in Zope 2 and its future regarding maintainance and support. I
have to say that I share some of his skepticism regarding Zope 2. I
personally have never fully understood ZC's reasons for the release
Jim Fulton wrote:
Philipp von Weitershausen wrote:
Why would they switch to Zope 2.8 if not for the component architecture?
To stay current? To get MVCC? To get new-style extension classes, and
thus access to many modern Python features. Later releases will provide
benefits beyond just the Z3
Martin, Maik, Andreas, and others,
I see two issues being raised in this thread:
1. Maik disagrees with the design philosophy behind Zope3 (the Component
Architecture) and the place Zope3 wants to position itself at in the
future. As a Zope developer who has spent the last two years both
Jim,
let's make this telegraph style :)
OK, here's another.
What about renaming the Zope 3 zope package to z.
+1
- It fits with the expansion of Zope:
Z Object Publishing Environment.
- It's short :)
- *At this time* (but after the move to svn), it's not too hard to make
a change like
Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
I don't see a problem at all; IIRC, we agreed that the backports from
Zope3 would live in a 'src' directory, while Zope 2 stuff continues to
live in 'lib/python'. No case problem
Gintautas Miliauskas wrote:
Update of /cvs-repository/Zope3/src/zope/tal
In directory cvs.zope.org:/tmp/cvs-serv27951/src/zope/tal
Modified Files:
talparser.py
Log Message:
Removed an assertion which disallows usage of Zope3 i18n in XML markup.
Added a few test cases which run the new code
Jean Baltus wrote:
Hi all,
The problem I describe here does NOT appear with Zope 2.6.1, nor Zope
2.6.2b4, only with Zope 2.7.
I installed Zope 2.7 with CMF 1.4, Plone 1.1alpha2 and
TranslationService 0.4. When I create a Plone site (called dice here)
Ive got the following error:
...
*
Chris McDonough wrote:
Update of /cvs-repository/Zope/lib/python/TAL
In directory cvs.zope.org:/tmp/cvs-serv15492/lib/python/TAL
Modified Files:
TALGenerator.py
Log Message:
Merge TAL i18n fixes which break CMF to HEAD from 2.7 branch.
The agreement Jim was basically that this backward
Richard Jones wrote:
During the Melbourne Zope3 Sprint, someone ran up against a situation where
they'd have liked to have TALES perform a tuple unpacking like Python can.
I've just run into a similar situation :)
Say a method listFilesByUser returns a list of (user, [files]) it'd be nice to
Shane Hathaway wrote:
Here's the way I'd like to spell it:
div tal:repeat=user_files here/listFilesByUser
User: span tal:replace=user_files/int:0 /
File: span tal:replace=user_files/int:1 /
/div
+1
We've come up with a number of generally useful prefixes, BTW. Off the
top of my
Evan Simpson wrote:
Hmmm. I hadn't thought of that before, but I've certainly wanted to
tell the path traverser whether to use attribute, index, or key access
on several occasions (using 'items' as a dictionary key bites me
regularly).
I can imagine the pain. Explicit is better than implicit.
Clemens Robbenhaar wrote:
The actual work is the transformation of instances of class A.Foo to
class B.Foo; to be on the safe side one would have to copy over all
attributes manually. If You want to try a fast and dirty solution, You
could try to write the new class into the '__class__' attribute
Hi,
def addExternalMethod(self, id, title, module, function, REQUEST=None):
Add an external method to a folder
id=str(id)
title=str(title)
module=str(module)
function=str(function)
i=ExternalMethod(id,title,module,function)
#self._setObject(id,i)
I don't get
Hi there,
how do I turn off this annoying traceback that is always printed out when an
error occurrs?
--
Philipp von Weitershausen
[ *pronounce: "fun Viters-houzen" ]
Web http://www.philikon.de/
___
Zope-Dev maillist - [EMAIL
supporting WebDAV?
Any suggestions welcome!
Phil
--
Philipp von Weitershausen
[ *pronounce: "fun Viters-houzen" ]
http://www.philikon.de/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No c
801 - 870 of 870 matches
Mail list logo
