Re: [Repoze-dev] repoze grok comparison
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 thing. You hit on a point that I consider important. One of the interesting things about ZCML (and hence BFG) is it's easy for any Python developer to write their own directives. ZCML doesn't violate DRY, as I once thought it did, because if you find yourself writing repetitive directives, you can just create a custom directive in Python instead. Unfortunately, Grok obscures that simplicity. It seems much harder to add new kinds of decorators than it is to add new kinds of ZCML directives. 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). Approaching this from another point of view: debugging a grokker that does not behave as you expect is much harder than debugging a zcml statement or a python imperative statement. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 would be the same. 2009/5/7 Wichert Akkerman wich...@wiggy.net: Approaching this from another point of view: debugging a grokker that does not behave as you expect is much harder than debugging a zcml statement or a python imperative statement. If they were the same, you'd be able to debug a grokker just as you would a ZCML-directive. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 writing either a ZCML handler or a grokker. When I wrote some ZCML handlers, I didn't bother to look for documentation: I just found some examples and modified them. It was really easy. When I looked at writing a grokker, though, I found myself buried in a pile of new abstractions. Still, I imagine I'll learn the Martian abstractions sometime and change my view. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 have not found documentation for writing either a ZCML handler or a grokker. When I wrote some ZCML handlers, I didn't bother to look for documentation: I just found some examples and modified them. It was really easy. When I looked at writing a grokker, though, I found myself buried in a pile of new abstractions. Still, I imagine I'll learn the Martian abstractions sometime and change my view. Well... in any case, this discussion is somewhat moot since only framework authors should ever need to write directives or grokkers. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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, then application authors will be forced to violate DRY in various situations. To solve that, the invitation to write new kinds of configuration directives should be extended to application authors, not just framework authors. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 framework authors write ZCML handlers / grokkers, then application authors will be forced to violate DRY in various situations. To solve that, the invitation to write new kinds of configuration directives should be extended to application authors, not just framework authors. I agree. I think both writing a grokker and writing a ZCML directive are probably both a little too hard for the casual application developer. In particular, writing a ZCML directive is actually quite hard; there are no docs and you need to understand the way zope.schema works. The way ZCML works is far too overdesigned, and the overdesigned pieces are *badly* designed. 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 handler call it), b) writing a simple handler was documented better and more availably and c) handlers actually just *returned* something rather than being called for their side effects. It's also completely bizarre that a ZCML handler has no easy access to the registry being populated except via getSiteManager(). It's a mess. Writing a grokker is easier (at least the first one you write) than writing a ZCML directive because you don't need to understand zope.schema to write a grokker. But typically grokkers will just turn around and call an existing ZCML handler if one exists for the same purpose, I think. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 handler call it), That's true. The handler could use a schema for validation if it wants to. 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/zope3/ReusableActions I'm not sure the order attribute is appropriate, but the rest of Christian's proposal seems good. Perhaps the proposal would be better with your suggestion to return the configuration action from the handler, plus one more enhancement: I think the handler should return an iterable of configuration actions, to make it easy to compose handlers. It's also completely bizarre that a ZCML handler has no easy access to the registry being populated except via getSiteManager(). Well, the purpose of a handler is to populate some global registry, not necessarily the component architecture registry, so I can see the reasoning behind that. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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/zope3/ReusableActions Or just make it simple, and return a tuple of (callback, discriminator). Or a sequence of like [(callback, discriminator), (callback, discriminator), etc], as you say. It's also completely bizarre that a ZCML handler has no easy access to the registry being populated except via getSiteManager(). Well, the purpose of a handler is to populate some global registry, not necessarily the component architecture registry, so I can see the reasoning behind that. But it would have been easy for the ZCML support in zope.component to use a different kind of context that just had the registry as an attribute. Then you could actually use ZCML configuration to populate a *particular* registry, instead of whatever happens to be returned by getSiteManager(). Use of getSiteManager() causes apps to need to do a number of suspect thread locking hacks now if they want to run two otherwise unrelated zope.configuration+zope.component-using packages in the same process. It's becoming more frequent that there isn't one global registry (it should have never been zope.component's job to advertise one, but instead an application that *uses* zope.component might choose to do so). - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 here: http://wiki.zope.org/zope3/ReusableActions Or just make it simple, and return a tuple of (callback, discriminator). Or a sequence of like [(callback, discriminator), (callback, discriminator), etc], as you say. True. Is it time to write repoze.configuration? ;-) It's also completely bizarre that a ZCML handler has no easy access to the registry being populated except via getSiteManager(). Well, the purpose of a handler is to populate some global registry, not necessarily the component architecture registry, so I can see the reasoning behind that. But it would have been easy for the ZCML support in zope.component to use a different kind of context that just had the registry as an attribute. Then you could actually use ZCML configuration to populate a *particular* registry, instead of whatever happens to be returned by getSiteManager(). Use of getSiteManager() causes apps to need to do a number of suspect thread locking hacks now if they want to run two otherwise unrelated zope.configuration+zope.component-using packages in the same process. It's becoming more frequent that there isn't one global registry (it should have never been zope.component's job to advertise one, but instead an application that *uses* zope.component might choose to do so). I agree. However, I hesitate to give up the idea of using the configuration machinery to populate other kinds of registries in addition to the zope.component registry. If we gain the ability to populate the zope.component registry in a non-global way, I want to be able to populate other registries in a non-global way too. :-) One way to do that would be to add one more indirection to your plan. Instead of storing the zope.component registry as an attribute of the configuration context, the configuration context could hold an attribute with a dictionary of named registries. So handlers would grab the component registry as context.registries['zope.component']. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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), etc], as you say. True. Is it time to write repoze.configuration? ;-) Ha.. sadly, already done, mostly: http://docs.repoze.org/plugin/config.html http://svn.repoze.org/repoze.plugin/trunk/ I haven't really expected it to see the light of day but it does indeed work, eschews zope.schema and returns those tuples. Oh I see... the component registry you wrote also acts as a simple mapping. That's a good solution. Your component registry is also impressively small. I actually think that maybe (like the split between zope.component and zope.configuration), repoze.plugin maybe should offer up just a *plain* dictionary on the context as something that could be used as a registry and move the adaptery bits out into some consumer package (which might construct its own context type with an explicit adapter registry on it and pass it in, etc). It looks like you chose not to use zope.interface at all, but that's too radical for me. :-) I imagine a plugin system that can rely on either zope.interface or ABCs would have a much better chance at wide adoption. Interfaces are always treated as plain-old markers during adaptation anyway in zope.component at least delta an IRO. (BTW, I actually consider an IRO an anti-use-case, at least if the MRO is also used by default by the adapter machinery, which currently in zope.component it is.) r.plugin can use zope.interface Interface objects as markers too. It doesn't require them to be anything in particular, just hashable. It could also use objects that are of a particular abstract base class. It's all just convention, r.plugin doesn't care. 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 the two concepts logically distinct in any given application. I don't really have a sense of how abstract base classes would fit in here. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
On Thu, May 7, 2009 at 7:01 PM, Chris McDonough chr...@plope.com 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 the two concepts logically distinct in any given application. I don't really have a sense of how abstract base classes would fit in here. Yeah, my thinking has been, generally, that the fact that it's fairly common for people to create interfaces purely to have a marker to use for ZCA lookups, exposes a problem with the ZCA. An interface that is not an API specification is not really an interface. So called marker interfaces, to me, abuse the idea of an interface. I find repoze.plugin intriguing, in part, because it fixes this problem. AFAICT, it does everything zope.component does but adds some new use cases and makes the solutions to a few others seem less abusive of certain basic concepts. I don't have a lot of hope for its general adoption--it's awfully abstract to be accepted outside of Zope circles and inside of Zope circles there's already the ZCA, even if it seems a bit warty in places. The Zopistas seem to be the few folks, though, interested in such high levels of abstraction and formalism. 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 do this. The canonical solution is to apply marker interfaces to different objects in your graph in order to game the adapter lookups, but that's awfully hacky and not very satisfying at all. 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. Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 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 cases for lines and the software options for columns. The cell value could be a ranking, since obviously there won't be a case where Grok or BFG or WSGIPlone or whatever will be perfect or null for use case X. [Use] case in point : we're beginning a new project and we're considering options for web presence. A quick setup is throw a Trac and build on it, but I'd rather have a nice (easier to theme) front end on top of Trac (that would play well with Trac). Would/could that front end be Plone (we might have some content to manage one day, but then maybe not that much .. or will we ?) or Grok or BFG ? I know it's very often a matter of personal preference or competence and a matrix won't be a silver bullet but it would help IMO. Ease of deployment at commercial ISP's might be important to mention, but I understand that most people on this list probably manage their own servers. Cheers, Yves Moisan ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 point that I consider important. One of the interesting things about ZCML (and hence BFG) is it's easy for any Python developer to write their own directives. ZCML doesn't violate DRY, as I once thought it did, because if you find yourself writing repetitive directives, you can just create a custom directive in Python instead. Unfortunately, Grok obscures that simplicity. It seems much harder to add new kinds of decorators than it is to add new kinds of ZCML directives. It's actually not too bad. Writing the bfg_view decorator was pretty simple (although I did find some bugs in martian that needed fixing while doing it). I mostly found writing a grokker more pleasant than writing an equivalent ZCML handler. But that may just be preference. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
2009/5/4 Hanno Schlichting hanno...@hannosch.eu: 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 features we'd might give up by going for a very minimal approach. But something that allowed us to compare our set of technical requirements against the various options would have been appreciated. 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 framework with a high level of abstraction. Contracts are easier with BFG and it makes development quick and, dare I say it, fun. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
On Tue, May 5, 2009 at 3:47 AM, Malthe Borch mbo...@gmail.com 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 framework with a high level of abstraction. Contracts are easier with BFG and it makes development quick and, dare I say it, fun. Definitely I'd add that BFG is definitely zope exploded...and it just happen to use a few bits of it to allow easy object publication (ZODB or SQL). 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. BFG is also security ready. At any time the developer can easily turn the key and make a entire app secure and then start defining fine-grained permissions. In GROK, it's going to make you understand Zope3 PAU first and then you have some work to doand there is a chance that in the end, you run away crying. Anyway, lots of key points in BFG: 1) Teeny Tiny; 2) Amazingly fast to serve and restart... If the server restarts faster, you don't need a /custom folder; 3) Few concepts to understand and easy to remember; 4) Easy security; 5) Easy templating; 6) Using ZODB or SQL is optional and covered; 7) Benefits from WSGI which allows easy extensibility and deployment; 8) You can do zope development (ZCA) inside of it but that's optional and definitely not required. In GROK, things tends to be a little harder because of it's inheritance from Zope3...but doesn't require you to know Zope3 in the beginning...which I believe is the goal of the project. Regards, -Fernando ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 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. I'm afraid there isn't much in the way of documents comparing Grok to BFG or Zope 3 to BFG as a web framework. The Repoze/Zope/Grok communities overlap a good bit so everyone is quite nice to each other about their frameworks. ;-) In general, though, these days I think it's safe to say if you want Zope3, you want Grok. Want Zope3 can be defined as want ZODB, want Zope-style form-generation, want ZPT. If you want something smaller that feels similar but doesn't make as many choices for you, BFG is probably the way to go. One set of comparisons on the axis of number of lines of profiler output were made a while back: http://www.plope.com/whats_your_web_framework_doing Today, on the same benchmark, r.bfg emits 32 lines of profiler output. It's getting cliched, but it really *is* an exciting time to be a python-wsgi-web developer. =) It is! - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 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. Actually a somewhat more detailed comparison would be valuable even for more involved people. I just had quite a bit of a discussion with Laurence on the weekend what framework / toolkit / set of packages we should use for a upcoming not-very-cms'y project. 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 features we'd might give up by going for a very minimal approach. But something that allowed us to compare our set of technical requirements against the various options would have been appreciated. Hanno ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze grok comparison
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 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 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. I'm afraid there isn't much in the way of documents comparing Grok to BFG or Zope 3 to BFG as a web framework. The Repoze/Zope/Grok communities overlap a good bit so everyone is quite nice to each other about their frameworks. ;-) In general, though, these days I think it's safe to say if you want Zope3, you want Grok. Want Zope3 can be defined as want ZODB, want Zope-style form-generation, want ZPT. If you want something smaller that feels similar but doesn't make as many choices for you, BFG is probably the way to go. Hmm, maybe I'm weird, but what I actually am intrigued by is the other stuff. I like SQLA, Genshi, and to a lesser extent ToscaWidgets. But I'm very interested in the registry based architecture of Zope from what I've read so har in Philipp's book. I do wish the book had more of an architectural overview chapter in the beginning though. Agreed. Grok's big. It has a lot of features (good), and a lot of code (a liability). It makes choices about the defaults more than BFG does. Due to its Zope 3 heritage it doesn't tend to lock you into defaults very much, but they're there and that might be trouble enough for some. Is one or the other more similar to Pylons? I *think* I'm stumbling towards something like Zope Component Architecture on Pylons call style. Thanks for the feedback. Iain ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
