On Dec 20, 2008, at 1:59 PM, Chris McDonough wrote:
> As a result of messing around with the ZCA + ZCML outside the
> context of Zope,
> I've found that it may be possible to significantly reduce the
> number of egg
> dependencies of BFG by replacing the code that allows the following
> ZCM
Paul Everitt wrote:
>
> On Dec 20, 2008, at 1:59 PM, Chris McDonough wrote:
>
>> As a result of messing around with the ZCA + ZCML outside the context
>> of Zope,
>> I've found that it may be possible to significantly reduce the number
>> of egg
>> dependencies of BFG by replacing the code that a
On Dec 20, 2008, at 2:12 PM, Chris McDonough wrote:
> Paul Everitt wrote:
>>
>> On Dec 20, 2008, at 1:59 PM, Chris McDonough wrote:
>>
>>> As a result of messing around with the ZCA + ZCML outside the
>>> context
>>> of Zope,
>>> I've found that it may be possible to significantly reduce the
Paul Everitt wrote:
>> zope.configuration doesn't provide any decorator syntax, but if you
>> mean the
>
> Sorry, I meant repoze.bfg.convention. I believe that, under the hood,
> it's doing the same configuration work as ZCML.
It is but it's a separate issue. We could choose to make parallel
ut
Chris McDonough wrote:
> Creating parallel "adapter", "utility" and "subscriber" handlers is really
> how I
> should have started things out, but I didn't, and given that there are people
> using the system in the wild that this would cause problems for in a new
> release, I wanted to ask for com
Martin Aspeli wrote:
> Chris McDonough wrote:
>
>> Creating parallel "adapter", "utility" and "subscriber" handlers is really
>> how I
>> should have started things out, but I didn't, and given that there are people
>> using the system in the wild that this would cause problems for in a new
>> re
> Maybe there's some potential to create a set of core ZCML registration
> handlers
> for utility, adapter, subscriber, and interace that are not actually part of
> BFG, but on which BFG and other non-Zope apps could depend. I suspect this is
> the only realistic way to go forward: I don't think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris McDonough wrote:
> As a result of messing around with the ZCA + ZCML outside the context of Zope,
> I've found that it may be possible to significantly reduce the number of egg
> dependencies of BFG by replacing the code that allows the following
Chris McDonough wrote:
>> Maybe there's some potential to create a set of core ZCML registration
>> handlers
>> for utility, adapter, subscriber, and interace that are not actually part of
>> BFG, but on which BFG and other non-Zope apps could depend. I suspect this
>> is
>> the only realistic w
Chris McDonough wrote:
> That package is now done...
>
> http://static.repoze.org/zcmldocs
>
> and
>
> http://pypi.python.org/pypi/repoze.zcml/0.1
>
> I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML
> declaration implementations from this rather than using the "stock"
Previously Martin Aspeli wrote:
> Chris McDonough wrote:
>
> > That package is now done...
> >
> > http://static.repoze.org/zcmldocs
> >
> > and
> >
> > http://pypi.python.org/pypi/repoze.zcml/0.1
> >
> > I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML
> > declaration
Chris McDonough wrote:
> Maybe there's some potential to create a set of core ZCML registration
> handlers
> for utility, adapter, subscriber, and interace that are not actually part of
> BFG, but on which BFG and other non-Zope apps could depend. I suspect this is
> the only realistic way to go
Hanno Schlichting wrote:
> Chris McDonough wrote:
>> Maybe there's some potential to create a set of core ZCML registration
>> handlers
>> for utility, adapter, subscriber, and interace that are not actually part of
>> BFG, but on which BFG and other non-Zope apps could depend. I suspect this
>>
Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> Chris McDonough wrote:
>>
>>> That package is now done...
>>>
>>> http://static.repoze.org/zcmldocs
>>>
>>> and
>>>
>>> http://pypi.python.org/pypi/repoze.zcml/0.1
>>>
>>> I've adjusted the trunk of bfg and the trunk of chameleon.zpt to u
repoze.bfg has a core concept of "pay only for what you eat", so, as Paul put it
(with a 30 point word no less!), "fidelity" with Zope is not a goal; where we
don't need things that Zope offers, we explicitly get rid of them. This helps
keep things honest and understandable, particularly in places
Summary: there isn't really a problem, because BFG is not Repoze.
People that want the side-effects in BFG can still get them.
Everybody wins.
On Dec 21, 2008, at 6:06 AM, Martin Aspeli wrote:
> I realise Plone isn't your main concern here, but this is basically
> what's going to happen to
Paul Everitt wrote:
> That seems like a false leap.
I freely admit to using hyperbole in my original email to draw out a
debate. :-)
It does bother me a little, though, that the "fix" seems to be to
fork/re-implement rather than to try and push something downstream.
No-one in Zope is disagree
Martin Aspeli wrote:
> Paul Everitt wrote:
>
>> That seems like a false leap.
>
> I freely admit to using hyperbole in my original email to draw out a
> debate. :-)
>
> It does bother me a little, though, that the "fix" seems to be to
> fork/re-implement rather than to try and push something d
On Dec 21, 2008, at 9:31 AM, Chris McDonough wrote:
> But one thing won't happen: bfg is not going to live
> with four inappropriate dependencies forever to service a goal of
> fidelity.
Repoze is the place where we co-habitate with the goals of other
projects, such as Zope and Plone. BFG,
On Dec 21, 2008, at 11:36 AM, Martin Aspeli wrote:
> Paul Everitt wrote:
>
>> That seems like a false leap.
>
> I freely admit to using hyperbole in my original email to draw out a
> debate. :-)
>
> It does bother me a little, though, that the "fix" seems to be to
> fork/re-implement rather than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris McDonough wrote:
> Hanno Schlichting wrote:
>> Chris McDonough wrote:
>>> Maybe there's some potential to create a set of core ZCML registration
>>> handlers
>>> for utility, adapter, subscriber, and interace that are not actually part of
>>> BF
Mmmm... I didn't mean for this to get quite so emotional. :)
Chris (and Agendaless) is of course free to do whatever he wants with
BFG. And as I've shown many times, I'm very supportive of the great work
coming out of the Repoze project.
However, if Repoze is aiming to bridge the gap between th
Tres Seaver wrote:
> Note that one change I would make to the docs is to make using the 'bfg'
> namespace *not* the default in the examples; marking each non-Zope
> directive with 'bfg:' (in the examples, not necessarily in a real-world
> config) would remind people, "this is not your father's Ol
Previously Martin Aspeli wrote:
> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package
> that should be re-usable and may be useful to BFG if it ever wants to
> serialise Zope 3 schema interfaces to/from an XML representation) well,
> it uses zope:* ZCML directives. Are you goi
On Dec 22, 2008, at 6:36 AM, Martin Aspeli wrote:
> Chris (and Agendaless) is of course free to do whatever he wants with
> BFG. And as I've shown many times, I'm very supportive of the great
> work
> coming out of the Repoze project.
>
> However, if Repoze is aiming to bridge the gap between t
Martin Aspeli wrote:
> repoze.zcml is a symptom that an improvement is needed further down the
> stack. In the Plone world, we've learned the hard way that rolling your
> own to avoid having to push something deeper into the stack is a costly
> strategy in the long run. Paul should certainly kn
Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package
>> that should be re-usable and may be useful to BFG if it ever wants to
>> serialise Zope 3 schema interfaces to/from an XML representation) well,
>> it uses zope:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
> Wichert Akkerman wrote:
>> Previously Martin Aspeli wrote:
>>> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package
>>> that should be re-usable and may be useful to BFG if it ever wants to
>>> serialise Zope
Paul Everitt wrote:
> On Dec 22, 2008, at 6:36 AM, Martin Aspeli wrote:
>
>> Chris (and Agendaless) is of course free to do whatever he wants with
>> BFG. And as I've shown many times, I'm very supportive of the great
>> work
>> coming out of the Repoze project.
>>
>> However, if Repoze is aimin
Martin Aspeli wrote:
> Wichert Akkerman wrote:
>> Previously Martin Aspeli wrote:
>>> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package
>>> that should be re-usable and may be useful to BFG if it ever wants to
>>> serialise Zope 3 schema interfaces to/from an XML representati
On Dec 22, 2008, at 1:06 PM, Martin Aspeli wrote:
> Wichert Akkerman wrote:
>> Previously Martin Aspeli wrote:
>>> If you want to pull in, say, plone.supermodel (a "pure Zope 3"
>>> package
>>> that should be re-usable and may be useful to BFG if it ever wants
>>> to
>>> serialise Zope 3 sche
Martin Aspeli wrote:
> Paul Everitt wrote:
>> On Dec 22, 2008, at 6:36 AM, Martin Aspeli wrote:
>>
>>> Chris (and Agendaless) is of course free to do whatever he wants with
>>> BFG. And as I've shown many times, I'm very supportive of the great
>>> work
>>> coming out of the Repoze project.
>>>
>
Paul Everitt wrote:
> On Dec 22, 2008, at 1:06 PM, Martin Aspeli wrote:
>
>> Wichert Akkerman wrote:
>>> Previously Martin Aspeli wrote:
If you want to pull in, say, plone.supermodel (a "pure Zope 3"
package
that should be re-usable and may be useful to BFG if it ever wants
Previously Martin Aspeli wrote:
> Wichert Akkerman wrote:
> > Previously Martin Aspeli wrote:
> >> If you want to pull in, say, plone.supermodel (a "pure Zope 3" package
> >> that should be re-usable and may be useful to BFG if it ever wants to
> >> serialise Zope 3 schema interfaces to/from an X
Wichert Akkerman wrote:
> If reimplementing something is easy to do (which is generally true
> considering we all have Zope's source) and allows you to drop all that
> extra baggage that - why not?
Because you have to maintain it forever. Of course, you may not mind
doing that - it'll be a case-
2008/12/23 Martin Aspeli :
> Because you have to maintain it forever. Of course, you may not mind
> doing that - it'll be a case-by-case thing.
The fundamental codebase of Zope 3 is rather stable I think. I don't
think it needs much maintainance. There's one thing I'd like to
change/maintain, whic
2008/12/22 Martin Aspeli :
> I think the fact that Chameleon now uses repoze.zcml may be. And my
> argument is that if you want to both use other parts of the Repoze stack
> that use the Zope 3 CA, and you want this minimal set of dependencies,
> then you're going to have to make the same change to
37 matches
Mail list logo
