Jim Fulton wrote:
At:
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PublicationPostProcessing
I've put doesn some thoughs for discussion on making the publication APIs
more explicit and for supporting post processing tasks like adding
standard look and feel or adding
Tim Peters wrote:
How would you do what manually? Install all the versions of Python
you care about on Windows, and build Zope using the version of Python
you want to test with. For example,
\Python23\python setup.py build_ext -i install_data --install-dir .
\Python23\python test.py
Benji York wrote:
It's running the tests, that's what we're interested in.
Ah, okay, but could we also use the buildbot model to build binary
distros for various platforms?
As a side issue, what's the security setup like?
How do you control who can set up a slave and, as such, who gets to
Steve Alexander wrote:
Interesting. It looks to me like you're calling a User object what the
CMF calls a Member.
Sure. Does the CMF have any users who aren't members?
The theory is a bit hazy but the practice is quite clear: in CMF all
participants are members. The Member object is just a
On 9/16/05, Florent Guillaume [EMAIL PROTECTED] wrote:
(Or use a convenience method to do that, I'm not sure if alsoProvides() was
ever implemented.)
zope.interface.alsoProvides() works like a champ.
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Zope Corporation
Paul Everitt wrote:
Jim Fulton wrote:
At:
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PublicationPostProcessing
I've put doesn some thoughs for discussion on making the publication APIs
more explicit and for supporting post processing tasks like adding
standard
Philipp von Weitershausen wrote:
Florent Guillaume wrote:
Philipp von Weitershausen wrote:
from zope.app.content.interfaces import IContentType
from zope.app.file.interfaces import IFile
from zope.interface import directlyProvides
directlyProvides(IFile, IContentType)
Am 16.09.2005 um 15:59 schrieb Jim Fulton:
Paul Everitt wrote:
Jim Fulton wrote:
Consider the headings under Need for page-composition support,
Pipelines, Transitive Adaptation, and the subset described
under Subscription. It might be possible to also do these
inside a WSGI Twisted in
[Chris Withers]
Oh, sorry, I meant how do you select the right version of VC++?
You don't; distutils does; if you use a Python 2.3 on Windows, its
distutils will use VC6 to compile C extensions; if you use a Python
2.4 on Windows, its distutils will use VC7. It's all driven by which
Python you
Jean-Marc Orliaguet wrote:
does alsoProvides() check for interfaces already listed?
No, but directlyProvides does. Issuing the same directlyProvides(...)
call twice has the same effect as issuing it once.
Philipp
___
Zope3-dev mailing list
The Zope 3 development team is proud to announce Zope 3.1.0 candidate 3.
Zope 3 is the next major Zope release and has been written from scratch based
on the latest software design patterns and the experiences of Zope 2.
It is in our opinion that Zope 3.1 is more than ready for production use,
Sorry for the long delay in replying.
We've been using widget-specific JS and CSS for some time now and I like our
approach. It's quite different from the proposal.
We're using the same pattern used by forms/widgets -- i.e. the PT is
responsible for explicitly including HTML fragments provided
I don't understand what you just said :-)
My fault -- I haven't been plugged into the other discussion.
Is there a branch somewhere that has a simple demo to help with grokability?
-- Garrett
On Friday, September 16, 2005 12:28 PM, Gary Poster wrote:
On Sep 16, 2005, at 12:49 PM, Garrett
I mean something that illustrates Gary's 'big picture'. I understand the
resource lib proposal, but I don't have any grasp of the broader vision driving
it.
If it's just a patch to get 'rich' widgets working, I'll stick with my initial
impression of it being too magical.
-- Garrett
On
On Friday, September 16, 2005 4:05 PM, Benji York wrote:
Garrett Smith wrote:
If it's just a patch to get 'rich' widgets working, I'll stick with
my initial impression of it being too magical.
The main reasons why this isn't a problem individual widgets
can solve
is that 1) they can't
My point is that if rich widgets are the *only* driver here, the solution below
is a better fit with the existing widgets implementation.
The transformation of the HEAD doesn't jive with existing patterns. If there's
a new pattern afoot (pipelining?), I hope we get a chance to discuss it. If
On Friday, September 16, 2005 3:58 PM, Gary Poster wrote:
You could also be asking about the pipeline ideas, but that's not my
first guess. :-)
Yes, I suspect this is what I'm missing.
There was an earlier post about Ajax. It seems an entirely new approach would
be needed to solidly support
Garrett Smith wrote:
On Friday, September 16, 2005 5:17 PM, Benji York wrote:
Garret Smith wrote:
FWIW, we would not be able to use this new scheme exclusively as some
of our IHeadContent providers provide more than file includes. E.g.
we have a menu component that dynamically builds
On Sep 16, 2005, at 6:15 PM, Garrett Smith wrote:
On Friday, September 16, 2005 3:58 PM, Gary Poster wrote:
You could also be asking about the pipeline ideas, but that's not my
first guess. :-)
Yes, I suspect this is what I'm missing.
Maybe so. Maybe you just disagree. :-)
In a
19 matches
Mail list logo
