Am 24.08.2009 um 19:02 schrieb Dan Korostelev:
2009/8/22 Michael Howitz m...@gocept.com:
Am 21.08.2009 um 21:06 schrieb Dan Korostelev:
[...]
z3c.layer.pagelet also uses these interfaces to re-implement login/
logout
like zope.app.security but by using pagelets and viewlets.
So it would be
Am 24.08.2009 um 22:55 schrieb Roger Ineichen:
[...]
Everything which has to do with login has nothing to do
in z3c.layer.pagelet.
z3c.layer.pagelet should only offer a working setup for
pagelet based traversal stuff and error handling.
Until we find a better place for it I'd like to keep it
On 2009-08-22, Uli Fouquet u...@gnufix.de wrote:
As it turned out product configurations are not set with
zope.app.wsgi (contrary, for instance, to zope.app.server).
[...snip...]
Is there a special reason why that was not included in
zope.app.wsgi?
My question exactly.
And this raises
Hi Chris!
Chris Withers wrote:
yuppie wrote:
Currently buildout is just used to set up the software.
Wrong. The buildout I posted, which uses no fancy recipes, sets up an
instance. The egg cache, as such, is the software...
You ripped my sentence out of context. We were talking about
Hi Gary
Betreff: Re: AW: [Zope-dev] zope.publisher 3.5 branch has
code/behavior not a part of subsequent releases
On Aug 24, 2009, at 6:02 PM, Roger Ineichen wrote:
Hi Tres
Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has
code/behavior
not a part of subsequent releases
Summary of messages to the zope-tests list.
Period Mon Aug 24 12:00:00 2009 UTC to Tue Aug 25 12:00:00 2009 UTC.
There were 8 messages: 8 from Zope Tests.
Tests passed OK
---
Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Mon Aug 24 20:43:52 EDT 2009
URL:
Hi Michael
Betreff: Re: AW: [Zope-dev] Proposal: zope.app.publisher refactoring
Am 24.08.2009 um 22:55 schrieb Roger Ineichen:
[...]
Everything which has to do with login has nothing to do in
z3c.layer.pagelet.
z3c.layer.pagelet should only offer a working setup for
pagelet based
Hello,
We're using zope.sendmail to send mail from our applications. These
applications are built on top of a more generic application library. It
is this application library that depends on zope.sendmail. This
application library listens for certain events and then can decide to
send out an
Hello,
I'd rather use a mailer stub for testing.
Like the one in zope.sendmail.tests.test_mailer.py
...
class SMTP(object):
...
Something like this can be setup for individual tests with
utility
name=mailer-name
provides=zope.sendmail.interfaces.IMailer
Adam GROSZER wrote:
Hello,
I'd rather use a mailer stub for testing.
Like the one in zope.sendmail.tests.test_mailer.py
...
class SMTP(object):
...
Something like this can be setup for individual tests with
utility
name=mailer-name
Hello,
I think automagic things are evil.
Later if you realize that you don't need them you have to fight to get
rid of them.
Tuesday, August 25, 2009, 4:19:30 PM, you wrote:
JWK Adam GROSZER wrote:
Hello,
I'd rather use a mailer stub for testing.
Like the one in
Jan-Wijbrand Kolman wrote:
Zope.sendmail explains in its README.txt that the developer using
zope.sendmail should himself take care of not sending emails (by setting
up a test layer for example, that would register a no-op IMailDelivery
utility).
Why not just use testfixtures [1] and Mock
Chris Withers wrote:
Jan-Wijbrand Kolman wrote:
Zope.sendmail explains in its README.txt that the developer using
zope.sendmail should himself take care of not sending emails (by setting
up a test layer for example, that would register a no-op IMailDelivery
utility).
Why not just use
Jim Fulton wrote:
On Tue, Aug 11, 2009 at 8:02 AM, Martijn Faassenfaas...@startifact.com
wrote:
[snip]
Ah, that's cool. I take it it's not yet possible to do without the test
extra entirely and let buildout rely on the test_require section? That
way we could do without duplication.
That's
Thomas Lotze wrote:
Martijn Faassen wrote:
One question to ask is whether getParent and getParents are used all over
the place or just by zope.traversing. If they're only used by
zope.traversing we might not want to move them to a more general place,
but perhaps we can even see about
Jim Fulton wrote:
On Tue, Aug 11, 2009 at 5:39 PM, Jim Fultonj...@zope.com wrote:
...
Why is zope.ucol in the list? It's a pain to install (and thus test)
because it needs ICU.
BTW, I hope that zope.ucol isn't needed (when you need unicode
collation badly enough that you're willing to
Jim Fulton wrote:
I do think we need a computer readable system that includes information
like this:
* whether a project is in a KGS (such as for the ZTK)
* whether a project is used to test a KGS (a package not in the ZTK but
used to test whether changes don't induce breakage, let's say,
Takayuki Shimizukawa wrote:
2009/8/22 Chris Withers ch...@simplistix.co.uk:
The first type of problem occurs when a form is submitted and the form
fields contain encoded strings. Somewhere down the line I get:
The first type, I don't know.
The second type of problem only occurs in IE and
Benji York wrote:
On Fri, Aug 14, 2009 at 2:51 PM, Jim Fultonj...@zope.com wrote:
Keep in mind that the thing we're talking about is pretty simple,
basically a single file. Branches beyond a test branch seem like
overkill. Maybe I missunderstand you. What sorts of branches did you
have in
Jim Fulton wrote:
On Fri, Aug 14, 2009 at 1:03 PM, Chris Withersch...@simplistix.co.uk wrote:
...
One question, and I know I'm late in on this so feel free to point me at
previous discussions, but say the KGS uses some.egg 1.0.0, a bug gets fixed
in some.egg and 1.0.1 is released. Does a
Jim Fulton wrote:
On Sat, Jul 4, 2009 at 7:33 AM, Christian Theunec...@gocept.com wrote:
So, if you see that a package is missing or is classified in the wrong
way, then please speak up.
I think zope.wfmc and zope.app.wfmc should be removed. I don't think
they're widely used. I don't use
Hey,
Shane Hathaway wrote:
[snip]
Few developers care about XML-RPC these days. Most web developers are
now working with REST, JSON, and other similar stuff. It's probably
best to move all XML-RPC artifacts, including those in zope.publisher,
to a single package, so that most developers
Dan Korostelev wrote:
2009/8/21 Dan Korostelev nad...@gmail.com:
Browser view directives (browser:page and friends) - move this to some
zope.browserpage package and make its structure more clean, so
people could understand the magic of browser page class generation.
:-)
Silly me, I
Dan Korostelev wrote:
2009/8/24 Stephan Richter srich...@cosmos.phy.tufts.edu:
On Friday 21 August 2009, Dan Korostelev wrote:
BrowserSkinsVocabulary - this can be moved to zope.publisher.browser
and rewritten with zope.schema's SimpleVocabulary not to introduce
dependency on
Hey,
Jim Fulton wrote:
[snip]
A. Suck it up and live with the deprecation warnings until we get rid
of zope.app.zcmlfiles
B. Remove the security declaration for mhlib from globalmodules.zcml.
Is anyone actually building web applications that publish MH mail
folders?
C. Stop including
Hi there,
Here are some steering-groupish responses.
General note: I'm quite enthusiastic about the general plan to clean up
zope.app.publisher! Thanks for bringing this up!
Dan Korostelev wrote:
Menu mechanism (the browser:menuItem directive and friends) - move
this to the new
Hi there,
Fabio Tranchitella wrote:
[snip]
Will we have an official buildbot instance somewhere under the zope.org
domain? In this case, I'm willing to administer and maintain it, if nobody
else steps in.
I'd be happy to see this. We can do this with a DNS thing
(buildout.zope.org) or we can
2009/8/25 Martijn Faassen faas...@startifact.com:
You have zope.browsermenu, zope.browserpage, zope.browserresource. I
propose instead we name them zope.menu, zope.page and zope.resource.
-1 These things are really only for browser, and ZCML directives are
in browser namespace, while, for
Stephan Richter wrote:
On Wednesday 12 August 2009, Jim Fulton wrote:
I'm not sure why this all has to be computer readable. What is the
use case for computer readable knowledge of whether a package is in
the kgs or just used to test it? What is the need for computer
readable information
On Tuesday 25 August 2009, Martijn Faassen wrote:
We can use such a list to extract more information from included
packages. For example, I have a script to extract all CHANGES.txt entries
in comparison to an older KGS version.
Ah, nice use case. In fact I also have a script that parses
Hey Dan,
See also my feedback in the original thread.
Dan Korostelev wrote:
Four new packages have been introduced:
See my comment on naming. I think we should call 'zope.menu',
'zope.page', 'zope.resource'.
* zope.browsermenu - browser menu system, without any changes. :-)
*
On Tue, Aug 25, 2009 at 12:21 PM, Martijn Faassenfaas...@startifact.com wrote:
...
That sounds reasonable, as long as it is documented. I got confused at
first about the term 'test branch', but you just mean a non-maintenance
branch of a package to do some development on. The special thing is
Cool. I just updated the .rst file. Someone else has to update the web site. :)
Jim
On Tue, Aug 25, 2009 at 12:17 PM, Martijn Faassenfaas...@startifact.com wrote:
Jim Fulton wrote:
On Sat, Jul 4, 2009 at 7:33 AM, Christian Theunec...@gocept.com wrote:
So, if you see that a package is missing
2009/8/25 Martijn Faassen faas...@startifact.com:
See my comment on naming. I think we should call 'zope.menu',
'zope.page', 'zope.resource'.
See my answer there :-)
* zope.ptresource - the page template resource that was moved into a
separate package to make zope.browserresource
Hello,
On Fri, Aug 14, 2009, Jim Fulton wrote:
On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurer jo...@freesources.org wrote:
...
zope2 releases based on buildout make it very hard for distributors to
package zope2. especially as zope2 requires
from what i know about buildout (and that's not
On 24/08/2009 Chris Withers wrote:
that's important for distributors who want to distribute generic
software, not user specific instance setups.
Distributors just want a tarball or similar, let them use
zc.sourcerelease and have a slightly different buildout.cfg, or even
default.cfg,
36 matches
Mail list logo
