On Monday 06 February 2006 12:33, Dieter Maurer wrote:
No it is not. Explicit is better then implicit. declareSite creates a
new site in the sites mapping. We use this pattern for layers and skins
already.
If it *creates* something why itn't its name createSite
(rather than declareSite).
On Friday 03 February 2006 17:23, Dieter Maurer wrote:
Stephan Richter wrote at 2006-2-3 12:45 -0500:
...
declareSite name=mysite /
site name=mysite /
!-- normal directives here. --
/site
The declareSite looks redundant. I see at the site name='mysite'
element that a site with name
Stephan Richter wrote:
On Thursday 02 February 2006 11:50, Martijn Faassen wrote:
or this content object (that is a site), when it's installed into the
ZODB (like a CMFSite or a Silva Root), please also install the following
local utilities (catalog, intid utility, etc).
I have already
Martijn Faassen wrote:
Jim Fulton wrote:
I've posted a proposal to simplify local component management at:
http://dev.zope.org/Zope3/LocalComponentManagementSimplification
Comments and questions are welcome.
I like the proposal.
I'm trying to figure out what this means exactly:
Jim Fulton wrote:
I've updated the proposed APIs. I changed wording from provide to
register
as unprovide doesn't make sense. (This also conglicts less with
existing APIs.)
I like the new wording. Do you offer the new wording within the zapi
too? That would be cool.
zapi.registerAdapter()
Jim Fulton wrote:
One issue with subscribers currently is that ZCML subscriber directives
can't be overridden. We need a fix for this.
In my understanding this usecase is covered by the new implementation,
isn't it?
Regards,
Dominik
___
Dominik Huber wrote:
Jim Fulton wrote:
I've updated the proposed APIs. I changed wording from provide to
register
as unprovide doesn't make sense. (This also conglicts less with
existing APIs.)
I like the new wording. Do you offer the new wording within the zapi
too?
I'd prefer to get
Dominik Huber wrote:
Jim Fulton wrote:
One issue with subscribers currently is that ZCML subscriber directives
can't be overridden. We need a fix for this.
In my understanding this usecase is covered by the new implementation,
isn't it?
What new implementation?
Jim
--
Jim Fulton
Jim Fulton wrote:
Dominik Huber wrote:
Jim Fulton wrote:
I've updated the proposed APIs. I changed wording from provide to
register
as unprovide doesn't make sense. (This also conglicts less with
existing APIs.)
I like the new wording. Do you offer the new wording within the zapi
too?
Jim Fulton wrote:
Dominik Huber wrote:
Jim Fulton wrote:
One issue with subscribers currently is that ZCML subscriber directives
can't be overridden. We need a fix for this.
In my understanding this usecase is covered by the new
implementation, isn't it?
What new implementation?
The
On Friday 03 February 2006 06:17, Martijn Faassen wrote:
I have already demonstrated such behavior in the bugtracker package. You
can use subscribers for it as well.
Could you be a bit more specific on where in the bugtracker package I
should be looking to find this behavior?
Sure.
I must
On Friday 03 February 2006 07:17, Jim Fulton wrote:
BTW, the new adapter registries have __bases__ attributes and
support multiple base registries. The same will probably hold for
component registries (that handle both adapters and utilities).
So, one could have a local registry that stores
On Friday 03 February 2006 07:17, Jim Fulton wrote:
Good point. I'm liking your proposal. It deserves some more thought.
However, another way to do the same thing woyuld be to allow ZCML to
define multiple registries and have a way of saying that a site of a
particular kind should use an
On Friday 03 February 2006 07:06, Jim Fulton wrote:
I've updated the proposed APIs. I changed wording from provide to
register as unprovide doesn't make sense. (This also conglicts less
with existing APIs.)
Like Dominik, I like the API as well.
Comments and questions are still welcome.
I
Stephan Richter wrote:
...
I just noticed that we have a slight paradigm shift here now; Subscriptions
are split into subscriptions and handlers. I like that distinction, but it
needs to be well-documented and communicated.
I don't disagree, except to note that that split happened some time
Hi,
In general I like the proposal, but I have a small nit:
registerSubscriptionAdapter's signature indicates that one of its
arguments is adapts, but the docstring indicates that it is named
required. The same thing is true with unregisterSubscriptionAdapter,
registerHandler, and
Amos Latteier wrote:
Hi,
In general I like the proposal, but I have a small nit:
registerSubscriptionAdapter's signature indicates that one of its
arguments is adapts, but the docstring indicates that it is named
required. The same thing is true with unregisterSubscriptionAdapter,
Stephan Richter wrote at 2006-2-3 12:45 -0500:
...
declareSite name=mysite /
site name=mysite /
!-- normal directives here. --
/site
The declareSite looks redundant. I see at the site name='mysite' element
that a site with name mysite is declared...
--
Dieter
On Thursday 02 February 2006 07:38, Jim Fulton wrote:
Comments and questions are welcome.
I like the proposal in general. The big missing use case that is missing for
me is the task of unregistering or reregistering a persistent component. In
the ZODB I need to be able to remove a registration
Stephan Richter wrote:
On Thursday 02 February 2006 07:38, Jim Fulton wrote:
Comments and questions are welcome.
I like the proposal in general. The big missing use case that is missing for
me is the task of unregistering or reregistering a persistent component. In
the ZODB I need to be
Jim Fulton wrote:
I've posted a proposal to simplify local component management at:
http://dev.zope.org/Zope3/LocalComponentManagementSimplification
Comments and questions are welcome.
I like the proposal.
I'm trying to figure out what this means exactly:
Registries may place
Stephan Richter wrote:
On Thursday 02 February 2006 07:38, Jim Fulton wrote:
Comments and questions are welcome.
I like the proposal in general. The big missing use case that is missing for
me is the task of unregistering or reregistering a persistent component.
I like the
Dominik Huber wrote:
Stephan Richter wrote:
On Thursday 02 February 2006 07:38, Jim Fulton wrote:
Comments and questions are welcome.
I like the proposal in general. The big missing use case that is
missing for me is the task of unregistering or reregistering a
persistent
On Thursday 02 February 2006 11:50, Martijn Faassen wrote:
or this content object (that is a site), when it's installed into the
ZODB (like a CMFSite or a Silva Root), please also install the following
local utilities (catalog, intid utility, etc).
I have already demonstrated such behavior in
On Thursday 02 February 2006 12:47, Jim Fulton wrote:
I like the proposal too, but if we start to allow utilities within the
content-space, this unregistering or reregistering should be highly
transparent for end-user.
Therefore it might be still usefull to provide a marker interface such
25 matches
Mail list logo
