After having been sick for a week I'm back on track now...
Fabio Tranchitella wrote:
I want to bring the test coverage for zope.component.zcml and
zope.component.security to 100% before asking to merge it back to the
trunk.
I'd like to tackle the move of zope.site.hooks to zope.component
Hey Thomas,
* 2009-10-19 10:12, Thomas Lotze wrote:
I'd like to tackle the move of zope.site.hooks to zope.component this
week. While I'm sure that that wouldn't conflict with your work, I would
prefer releasing both refactorings at once as they both involve using the
new scheme of
* 2009-10-14 17:33, Martijn Faassen wrote:
That's more or less what I have in mind. The suggestions are just about
trying to make it prettier.
...
[snip]
I applied your suggestions, and I think now the code is more robust; with
this branch, all the ZTK tests pass except zope.sendmail, which
Hey,
Fabio Tranchitella wrote:
[snip]
I tried to implement my idea here:
svn://svn.zope.org/repos/main/zope.component/branches/conditional-zope.security
This is a quite intrusive change, so please take it as a suggestion and
not as a real proposal: is this the right approach?
That's
On 10/12/09 01:22 , Fabio Tranchitella wrote:
Hello,
* 2009-10-09 15:37, Martijn Faassen wrote:
I'm okay with *not* doing the split up and going with your idea, but I
think eventually such a split up would simplify things. One advantage
would be that someone could examine repoze.zcml and not
* 2009-10-12 08:55, Wichert Akkerman wrote:
Perhaps it is an idea to make zope.component an extension for
repoze.zcml? repoze.zcml already exists and works well, and people who
want the extra zope magic can keep using zope.component. I suspect that
is less work than trying to split up
Fabio Tranchitella wrote:
* 2009-10-12 08:55, Wichert Akkerman wrote:
Perhaps it is an idea to make zope.component an extension for
repoze.zcml? repoze.zcml already exists and works well, and people who
want the extra zope magic can keep using zope.component. I suspect that
is less work than
Hello,
* 2009-10-09 15:37, Martijn Faassen wrote:
I'm okay with *not* doing the split up and going with your idea, but I
think eventually such a split up would simplify things. One advantage
would be that someone could examine repoze.zcml and not see distracting
ZCML implementations in
* 2009-10-07 22:40, Martijn Faassen wrote:
I think it would be interesting to review zope.component.zcml and see how
it depends on security, and see whether we cannot make the dependency
optional too.
I fully agree with this, and the main reason why I use a package like
repoze.zcml is to get
Fabio Tranchitella wrote:
[snip]
All the proxying stuff can be made optional with conditional imports.
I think the only solution to make zope.security optional without
removing the permission attribute is to do something like:
try:
from zope.security.zcml import Permission
except
* 2009-10-09 13:59, Martijn Faassen wrote:
I propose we create a new zope.componentzcml package that contains the
zope.component.zcml code. This package is *optionally* dependent on
zope.security as well as zope.proxy. It should work with just a
dependency on zope.i18nmessageid and
Fabio Tranchitella wrote:
[snip]
Anyway, I'm fine with what Martijn proposed if nobody else supports my
idea.
I'm okay with *not* doing the split up and going with your idea, but I
think eventually such a split up would simplify things. One advantage
would be that someone could examine
Martijn Faassen wrote:
Thomas Lotze wrote:
IMO it would be interesting to have the concept of the current site
available separately from the rest of zope.site with its 30
dependencies. (For example, zope.browserresource demonstrates how with
the present zope.site the need to know the current
Thomas Lotze wrote:
I thought about that one briefly, but I don't like it because it
introduces at least some knowledge about the security concept to
zope.component.
The more I think about it, the less evil this appears to me, though. After
all, the zope.component.zcml module has been
GAE users and repoze.bfg users as repoze.bfg doesn't use zope.security at all
I did a quick grep and it appears that repoze.bfg never actually loads
zope.component.zcml
so I think if the only dependancies you introduce are via zcml then
you should be ok. And given I am running repoze.bfg on app
Tim Hoffman wrote:
GAE users and repoze.bfg users as repoze.bfg doesn't use zope.security
at all
I did a quick grep and it appears that repoze.bfg never actually loads
zope.component.zcml
so I think if the only dependancies you introduce are via zcml then you
should be ok. And given I am
Tim Hoffman wrote:
On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli optilude+li...@gmail.com
wrote:
Martijn Faassen wrote:
Please don't add new dependencies to zope.component. Even optional ones,
IMHO. It makes it harder to re-use for others and more complex to
understand. Many people (e.g.
Hey,
Thomas Lotze wrote:
[snip]
I mentioned the zcml extra only because that's how zope.component has to
do with the security concept already, as a motivation of why I'm letting
go of my opposition to introducing more of that concept into
zope.component.
I think it would be interesting to
Hey,
Thomas Lotze wrote:
zope.site.hooks is a rather light-weight module that is concerned with
the concept of a current site, where the notion of a site is used in the
same sense as in zope.component, which actually prefers to only talk
about a component registry. In contrast, the rest of
Martijn Faassen wrote:
We could investigate two options:
* just removing that code that remove proxies and sees what happens to
significant Zope 3 code bases. Risky.
* alternatively, putting in an optional dependency on zope.security in
zope.component. If zope.security proxy is
Hi
On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli optilude+li...@gmail.com wrote:
Martijn Faassen wrote:
Please don't add new dependencies to zope.component. Even optional ones,
IMHO. It makes it harder to re-use for others and more complex to
understand. Many people (e.g. those wanting to
21 matches
Mail list logo
