On 5/9/09 11:45 AM, Chris Withers wrote:
> Chris McDonough wrote:
>> People are often confused about the duality of zope.interface
>> Interface objects being used as markers during adaptation as well as
>> being used as a mechanism to describe an API.
>
> I've found the use of interfaces as markers
Chris McDonough wrote:
> People are often confused about the duality of zope.interface Interface
> objects
> being used as markers during adaptation as well as being used as a mechanism
> to
> describe an API.
I've found the use of interfaces as markers pretty limited.
Most of the time now, I
2009/5/8 Chris Rossi :
> Among the more obvious use cases, to me, is the case Zope/Plone programmers
> run into all the time where they want to apply different components to
> different branches of their object graph--ZCA just doesn't really handle
> this at all, and yet it's very common to want to
On 5/7/09 8:53 PM, Chris Rossi wrote:
> I haven't sat down and pieced together how you'd do it
> in repoze.plugin, but it seems to that the fact that you can really use
> anything as a marker for your lookups, means you *ought* to be able to make
> this work in a bit more intuitive way.
FTR, I o
On Thu, May 7, 2009 at 7:01 PM, Chris McDonough wrote:
>
> People are often confused about the duality of zope.interface Interface
> objects
> being used as markers during adaptation as well as being used as a
> mechanism to
> describe an API. Personally, I think it should be possible to keep th
On 5/7/09 6:17 PM, Shane Hathaway wrote:
> Chris McDonough wrote:
>> On 5/7/09 5:28 PM, Shane Hathaway wrote:
>>
Or just make it simple, and return a tuple of (callback,
discriminator). Or a sequence of like [(callback, discriminator),
(callback, discriminator), ], as you say.
>>>
>>
Chris McDonough wrote:
> On 5/7/09 5:28 PM, Shane Hathaway wrote:
>
>>> Or just make it simple, and return a tuple of (callback,
>>> discriminator). Or a sequence of like [(callback, discriminator),
>>> (callback, discriminator), ], as you say.
>>
>> True. Is it time to write repoze.configuration?
On 5/7/09 5:28 PM, Shane Hathaway wrote:
>> Or just make it simple, and return a tuple of (callback,
>> discriminator). Or a sequence of like [(callback, discriminator),
>> (callback, discriminator), ], as you say.
>
> True. Is it time to write repoze.configuration? ;-)
Ha.. sadly, already done,
Chris McDonough wrote:
> On 5/7/09 3:44 PM, Shane Hathaway wrote:
>> Chris McDonough wrote:
>>> c) handlers actually just *returned* something rather than being
>>> called for their side effects.
>>
>> The thing the handler returns could implement the IConfigurationAction
>> interface described her
On 5/7/09 3:44 PM, Shane Hathaway wrote:
> Chris McDonough wrote:
>> c) handlers actually just *returned* something rather than being
>> called for their side effects.
>
> The thing the handler returns could implement the IConfigurationAction
> interface described here:
>
> http://wiki.zope.org/zop
Chris McDonough wrote:
> I think it would be more approachable (and therefore "better" on some axis)
> if
> a) ZCML didn't use schemas (declarative is not a win here, as you still need
> to
> write imperative code in the handler, and if you *did* want declarative
> stuff,
> just let the handl
On 5/7/09 3:01 PM, Shane Hathaway wrote:
> Martin Aspeli wrote:
>> Well... in any case, this discussion is somewhat moot since only
>> framework authors should ever need to write directives or grokkers.
>
> In that case, you're disagreeing with my position. Let me state it
> differently: if only f
Martin Aspeli wrote:
> Well... in any case, this discussion is somewhat moot since only
> framework authors should ever need to write directives or grokkers.
In that case, you're disagreeing with my position. Let me state it
differently: if only framework authors write ZCML handlers / grokkers,
Shane Hathaway wrote:
> Martin Aspeli wrote:
>> The grok approach is unfamiliar at first, for sure, and could do with
>> more documentation. But then so could the writing of ZCML directives.
>> Grok (and martian) do have some really nice abstractions, including good
>> testing support.
>
> I ha
Martin Aspeli wrote:
> The grok approach is unfamiliar at first, for sure, and could do with
> more documentation. But then so could the writing of ZCML directives.
> Grok (and martian) do have some really nice abstractions, including good
> testing support.
I have not found documentation for w
> Previously Martin Aspeli wrote:
>> You're sure about that? I find it easier to write a new grokker (whether
>> for a decorator or a more generic class grokker that looks for a base
>> class) than a new ZCML directive (and I've done plenty of both).
Ideally a grokker and a ZCML directive handler
Previously Martin Aspeli wrote:
> Shane Hathaway wrote:
> > Fernando Correa Neto wrote:
> >> Adding new template engines to BFG require you to know python while in
> >> GROK, it'd require you to grok grok first (which in would then
> >> introduce the developer to ZCA) which is definitely a Zope3 th
On 5/6/09 8:50 PM, Martin Aspeli wrote:
> Shane Hathaway wrote:
>> Fernando Correa Neto wrote:
>>> Adding new template engines to BFG require you to know python while in
>>> GROK, it'd require you to grok grok first (which in would then
>>> introduce the developer to ZCA) which is definitely a Zope
Shane Hathaway wrote:
> Fernando Correa Neto wrote:
>> Adding new template engines to BFG require you to know python while in
>> GROK, it'd require you to grok grok first (which in would then
>> introduce the developer to ZCA) which is definitely a Zope3 thing.
>
> You hit on a point that I consid
On 5/6/09 3:33 PM, Shane Hathaway wrote:
> Fernando Correa Neto wrote:
>> Adding new template engines to BFG require you to know python while in
>> GROK, it'd require you to grok grok first (which in would then
>> introduce the developer to ZCA) which is definitely a Zope3 thing.
>
> You hit on a p
Fernando Correa Neto wrote:
> Adding new template engines to BFG require you to know python while in
> GROK, it'd require you to grok grok first (which in would then
> introduce the developer to ZCA) which is definitely a Zope3 thing.
You hit on a point that I consider important. One of the inter
On 5/6/09 10:11 AM, Yves Moisan wrote:
> Well for someone like me (more or less familiar with Plone, already
> installed TG but not played very much with it and ended up installing
> Pylons for a project) a "what's the best tool matrix" would be neat.
>
> I see that matrix as some form of use case
> but to someone like me who is experienced in
> Pylons/TG/Django style stuff but new to Zope, I'm pretty confused about
> whether I should learn zope by trying out Zope 3, Grok, or Repoze.bfg
> and what the pros and cons of each approach are.
Well for someone like me (more or less familiar with P
On Tue, May 5, 2009 at 3:47 AM, Malthe Borch wrote:
> I think of BFG as a microkernel; you can plug into it using WSGI and a
> few other interfaces. These are simple and so writing libraries for
> them is easy. Contrast this with Zope where libraries have to be
> written against an entire framewor
2009/5/4 Hanno Schlichting :
> Our gut feeling told us to either stick with a very-much known beast
> like Zope 2.12 or go for repoze.bfg. Grok or the Zope Toolkit didn't
> strike us as particular interesting with any of its offerings. I do have
> a feeling that we might miss out some of the good f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Iain Duncan wrote:
> On Mon, 2009-05-04 at 17:58 -0500, Ian Bicking wrote:
>> It's only a small piece of Zope 3 or BFG, but a WebOb/Zope API
>> comparison: http://pythonpaste.org/webob/differences.html#zope-3
>> I actually had to complain some to get a
On Mon, 2009-05-04 at 17:45 +0200, Martijn Faassen wrote:
> Hey,
>
> Chris McDonough wrote:
> > On 5/4/09 1:21 AM, Iain Duncan wrote:
> >> Hi folks, I'm new here and was wondering if there is a good Repoze.bfg
> >> to Grok comparison page anywhere. If not, I'd like to recommend that it
> >> would
On Mon, 2009-05-04 at 17:58 -0500, Ian Bicking wrote:
> It's only a small piece of Zope 3 or BFG, but a WebOb/Zope API
> comparison: http://pythonpaste.org/webob/differences.html#zope-3
> I actually had to complain some to get a published reference doc for
> Zope 3 request and response, which is to
Iain Duncan wrote:
> Hi folks, I'm new here and was wondering if there is a good Repoze.bfg
> to Grok comparison page anywhere. If not, I'd like to recommend that it
> would be a great addition to the docs. I know there is a brief
> comparison up there, but to someone like me who is experienced in
Hey,
Chris McDonough wrote:
> On 5/4/09 1:21 AM, Iain Duncan wrote:
>> Hi folks, I'm new here and was wondering if there is a good Repoze.bfg
>> to Grok comparison page anywhere. If not, I'd like to recommend that it
>> would be a great addition to the docs. I know there is a brief
>> comparison u
On 5/4/09 1:21 AM, Iain Duncan wrote:
> Hi folks, I'm new here and was wondering if there is a good Repoze.bfg
> to Grok comparison page anywhere. If not, I'd like to recommend that it
> would be a great addition to the docs. I know there is a brief
> comparison up there, but to someone like me who
Hi folks, I'm new here and was wondering if there is a good Repoze.bfg
to Grok comparison page anywhere. If not, I'd like to recommend that it
would be a great addition to the docs. I know there is a brief
comparison up there, but to someone like me who is experienced in
Pylons/TG/Django style stuf
32 matches
Mail list logo
