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 conditi
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 t
* 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, whi
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?
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 wo
* 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 zope.
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
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 zop
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 repoz
* 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 zope.co
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
> e
* 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
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
Tim Hoffman wrote:
> On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli
> 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 wanti
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 gi
> 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
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 depen
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
Hi
On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli 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 use GAE) object to t
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 i
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
21 matches
Mail list logo
