Stephan Richter wrote:
On Monday 12 December 2005 16:29, Dominik Huber wrote:
1. The brand *skin* and *layer* are fairly common and they are
reflecting two logical uses cases. At a first glance the usage for a
layer type is not given, but the layer concept is still interesting to
build
I have a schema where for one attribute (processDef) the user should
be able to modify it only at the time he adds the object.
This is a quick hack to spare some lines of code, but it is not
working as expected. Modifying derived interface modifies the base
too.
Is that the expected behavior?
How
I would suggest to register the
layers like skins using a ILayerBrowserType interface:
interface
interface=.interfaces.I18NFeatures
type=zope.publisher.interfaces.browser.IBrowserLayerType
/
It is simple to create a zcml directive specifically for registering a
Steve Alexander wrote:
I would suggest to register the
layers like skins using a ILayerBrowserType interface:
interface
interface=.interfaces.I18NFeatures
type=zope.publisher.interfaces.browser.IBrowserLayerType
/
It is simple to create a zcml directive specifically
It is simple to create a zcml directive specifically for registering a
layer. If there is a good reason to register layers, then I think there
should be a zcml directive for it.
I disagree. Just because it is simple to create new ZCML directives
doesn't mean we don't have to. The less
Christian Theune wrote:
I propose to disable the comment functionality on the wiki pages for the
Zope 3 developer Wiki.
+1
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Hi there,
Christian Theune wrote:
a) Can we agree on a target group for the Zope 3 wiki? Can it be core
developers only?
The problem is that the only link we have been giving out to the whole
world whenever Zope 3 is announced somewhere is to that developer wiki.
I think we really really
Steve Alexander wrote:
Who will use these interfaces? In what parts of the code will they be
present?
I think these marker interfaces are used only in infrastructure code to
do with setting up layers and skins. In this case, they will not be
typed often, and will not even be read often. So,
Martijn Faassen wrote:
Hi there,
Christian Theune wrote:
a) Can we agree on a target group for the Zope 3 wiki? Can it be core
developers only?
The problem is that the only link we have been giving out to the whole
world whenever Zope 3 is announced somewhere is to that developer wiki.
Sidnei da Silva wrote:
On Mon, Dec 12, 2005 at 07:14:08PM -0500, Jim Fulton wrote:
| Here's what is in the docstring for HTTPRequest:
|
| - Lazy Data
|
| These are callables which are deferred until explicitly
| referenced, at which point they are resolved and stored as
|
On Tue, Dec 13, 2005 at 07:28:09AM -0500, Jim Fulton wrote:
| Sidnei da Silva wrote:
| So we are shooting for a z2 request implemented in terms of a z3
| request. Sounds like an adapter to me :)
|
| Maybe, however, if it is, it should happen as part of the request
| factory.
That's what I had in
On Tuesday 13 December 2005 06:17, Martijn Faassen wrote:
a) Can we agree on a target group for the Zope 3 wiki? Can it be core
developers only?
The problem is that the only link we have been giving out to the whole
world whenever Zope 3 is announced somewhere is to that developer wiki.
I
On Tuesday 13 December 2005 05:41, Adam Groszer wrote:
IDocTypeEditForm.getDescriptionFor('processDef').readonly=True
IDocType.getDescriptionFor('processDef').readonly
True
IDocTypeEditForm.getDescriptionFor('processDef').readonly
True
This is correct Python behavior. :-) If you want a
On Tuesday 13 December 2005 04:30, Philipp von Weitershausen wrote:
That said, I still think that in the long term, local registration should
not be done TTW.
Who said that I just want to register local components? :-) I want to attack
true TTW development, similar to how ZClasses worked. I
On Tuesday 13 December 2005 06:15, Steve Alexander wrote:
I understand from this discussion that registering layers is needed only
for certain ZMI things, to be implemented later on. So, I guess the
ZCML will be implemented later on, or not implemented later on. In
either case, later on.
I
Stephan Richter wrote:
On Tuesday 13 December 2005 06:15, Steve Alexander wrote:
I understand from this discussion that registering layers is needed only
for certain ZMI things, to be implemented later on. So, I guess the
ZCML will be implemented later on, or not implemented later on. In
On Tuesday 13 December 2005 08:34, Philipp von Weitershausen wrote:
No, we just make the registration of layers optional. If you want layers
to be registered (and marked with an ILayerType marker) for whatever
reason, it's your choice. The framework shouldn't make you like it does
now.
This
Phantom of GadflyAdapter
GadflyAdapter sometimes causes phantom read.
The reason is that many connections are made simultaneously
on a gadfly database through the thead local variable
_v_connection. Threadsafety level 2 or higher is required
to use the thread local variable.
To remedy this
I understand from this discussion that registering layers is needed only
for certain ZMI things, to be implemented later on. So, I guess the
ZCML will be implemented later on, or not implemented later on. In
either case, later on.
I disagree. The layers are registered now. You rip them out
On Tuesday 13 December 2005 09:54, Tadashi Matsumoto wrote:
Simple patch:
--- gadflyda.py.org 2005-12-06 22:19:47.0 +0900
+++ gadflyda.py 2005-12-12 22:41:07.0 +0900
@@ -51,6 +51,8 @@
# The registerable object needs to have a container
__name__ = __parent__
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion. This is a major blocking / freaking out kind of
issue. I'm trying to figure out now how to crawl through the debugger
and test the 'getMultiAdapter' lookup
I have an rdb connection that keeps disappearing.
I know the real problem is that the default wait_timeout and
interactive_timeout for MySql 5.0 is set at 8 hours. The site I am
working on for development waits 8 hours overnight for me to start
working again, then I get
Mysql server has
Jeff Shell wrote:
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion.
That would be my suspicion too. It should be easy to test.
Just get a check out and merge out that change:
svn merge
Here's one thing that I would like to see fixed.
In Zope 3 trunk right now, the schema for the server is defined in
zope/app/twisted/schema.xml. However, if I'm not mistaken, you can't
import that directly from another schema. Instead, the type
definitions should be in a separate component.xml
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote:
Jeff Shell wrote:
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion.
That would be my suspicion too. It should be easy to test.
Just get a
Jeff Shell wrote:
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote:
Jeff Shell wrote:
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion.
That would be my suspicion too. It should be easy to test.
Christian Theune wrote:
Well. First, the error would be something like an OperationalError (or
similar). Hmm. Not too distinguishable. Ideally we could:
- differentiate this kind of error from other OperationalErrors (like a
syntax error in your query)
The error in the traceback is
Jeff Shell wrote:
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote:
Jeff Shell wrote:
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote:
Jeff Shell wrote:
Is it related to this? Bug in Multi Adapter Lookup?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my
Jeff Shell wrote:
...
Going through a lot of debugging, it looks as through it has to do
with how things are ranked in
zope.interface.adapter.AdapterLookup.lookup() for multi-adapters.
Yup.
I haven't stepped through it in the debugger in Zope 3.1 yet, but I just
got finished doing it in Zope
Jim Washington wrote:
Spelunking a bit in the code,
zope.app.rdb.ZopeDatabaseAdapter.isConnected() looks at whether
_v_connection is present, not whether the connection is actually alive.
If we fix this here, isConnected() perhaps should handle the case where
the connection might be reaped
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Florent Guillaume wrote:
Jim Washington wrote:
Spelunking a bit in the code,
zope.app.rdb.ZopeDatabaseAdapter.isConnected() looks at whether
_v_connection is present, not whether the connection is actually
alive. If we fix this here,
On Dec 13, 2005, at 10:11 AM, Benji York wrote:
Jeff Shell wrote:
I think there was a proposal for smart widgets that could require
Javascript but have the supporting Javascript library loaded only
once..? What's become of that?
That sounds like zope.resourcelibrary
I plan to do this tomorrow, in the silence means consent vein.
Want to refresh your memory?
http://mail.zope.org/pipermail/zope3-dev/2005-December/016887.html
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
Jim Washington wrote:
Florent Guillaume wrote:
Jim Washington wrote:
Spelunking a bit in the code,
zope.app.rdb.ZopeDatabaseAdapter.isConnected() looks at whether
_v_connection is present, not whether the connection is actually
alive. If we fix this here, isConnected() perhaps should
On Dec 13, 2005, at 9:32 PM, Gary Poster wrote:
I sent this out too hastily. See below.
The answer we expected to give to the improved implementation
details hinged on the page postprocessing proposal Jim made.
It was not a proposal, but a brainstorm.
On 12/13/05, Jim Fulton [EMAIL PROTECTED] wrote:
Jeff Shell wrote:
...
Going through a lot of debugging, it looks as through it has to do
with how things are ranked in
zope.interface.adapter.AdapterLookup.lookup() for multi-adapters.
Yup.
I don't know enough about the relationshipd
On Tue, 13 Dec 2005 10:08:17 -0500
[EMAIL PROTECTED] wrote.
On Tuesday 13 December 2005 09:54, Tadashi Matsumoto wrote:
Simple patch:
If you write a test for this, I'll check it in.
Ok, I will try.
But I'm not sure I can make a test that always fails
for the origial code and succeeds for
Christian Theune wrote:
Am Dienstag, den 13.12.2005, 16:32 -0500 schrieb Jim Washington:
Christian Theune wrote:
Well. First, the error would be something like an OperationalError (or
similar). Hmm. Not too distinguishable. Ideally we could:
- differentiate this kind of
38 matches
Mail list logo
