[Zope-dev] Re: repoze.bfg
Chris McDonough wrote: I've been working on a new web framework named (provisionally) repoze.bfg. This looks very interesting; I'd be curious to see if this could be useful for Vudo. I'd like it very much if Vudo could sit on top of a more general framework (not just the Zope 3 libraries). Early on, the idea was that this could be Grok, but it quickly turned out that Grok makes too many assumptions for our use. I recently pasted a basic Pylons application and it gives you something that I think would be attractive in a Zope/Vudo/Bfg-based setup: A canonical directory structure, e.g. ./templates ./routers ./config etc. (can't remember the details) Perhaps this could benefit the following scenario: -- Set me up with a new Zope/Vudo/Bfg-application and give me some starting points. If Bfg can provide the lower layer, then I think Vudo will be great for providing the higher layers, e.g. -- skinning -- content types and widgets -- authoring -- admin \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: repoze.bfg
Hey, Chris McDonough wrote: [snip] It's unlike Grok inasmuch as: - It doesn't try to hide ZCML for configuration. Hiding is the wrong word. Grok doesn't hide ZCML for configuration. It simply replaces ZCML with a different configuration mechanism that I for one think is an improvement. One that you could easily start using with grokcore.component, I may add. You can mix and match with ZCML-based configuration as you please. That brings me to another difference with Grok: your framework is also unlike Grok inasmuch it's incompatible with Zope 3, correct? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: repoze.bfg
Malthe Borch wrote: Chris McDonough wrote: I've been working on a new web framework named (provisionally) repoze.bfg. This looks very interesting; I'd be curious to see if this could be useful for Vudo. I'd like it very much if Vudo could sit on top of a more general framework (not just the Zope 3 libraries). Early on, the idea was that this could be Grok, but it quickly turned out that Grok makes too many assumptions for our use. You're using Zope 3, right? Zope 3 makes the same set of assumptions Grok does, with very minor differences indeed. Could you be more explicit about what exactly in Grok was making too many assumptions? Wasn't it simply a case of different tastes, instead of assumptions that get in the way? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: repoze.bfg
Martijn Faassen wrote: Hey, Chris McDonough wrote: [snip] It's unlike Grok inasmuch as: - It doesn't try to hide ZCML for configuration. Hiding is the wrong word. Grok doesn't hide ZCML for configuration. It simply replaces ZCML with a different configuration mechanism that I for one think is an improvement. One that you could easily start using with grokcore.component, I may add. You can mix and match with ZCML-based configuration as you please. Thanks for the clarification. That brings me to another difference with Grok: your framework is also unlike Grok inasmuch it's incompatible with Zope 3, correct? Correct, if you're talking about using the Z3 publisher, although repoze.bfg is based on zope.component and zope.interface internally. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: repoze.bfg
Hey, Chris McDonough wrote: [snip] Correct, if you're talking about using the Z3 publisher, although repoze.bfg is based on zope.component and zope.interface internally. I wasn't primarily thinking about the publisher, more about such things like existing utilities, events, existing content types and so on. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: repoze.bfg
Martijn Faassen wrote: Could you be more explicit about what exactly in Grok was making too many assumptions? First a word on terminology: I mean Grok, the framework, not the declarative extensions to the component architecture (which I simply haven't gotten to yet). We felt that Grok was too much about object publishing; there's a model and a view for that model (and that view has a template). This didn't fit so well into our approach. On Vudo, the view is always a layout. It's then up to the layout to provide regions in which you can plug in a region content provider. Typically, you'd plug in at least the following: -- Title provider: Renders the title of the page (in title/title) -- Content provider: Renders the content of the page as widgets There are many more options to this scheme. You could plug in a portlet manager, or a viewlet manager or a global navigation. Next, we didn't want to use ZODB, because we wanted to try something completely different. So now we've written Dobbin which pretty much emulates ZODB, but on a SQL storage (so much for trying something new). I like Grok and I think it's great for writing Zope *applications*; but we didn't find it such a good match for Vudo. I still want to try grokcore.component because there are some obvious candidates for declarative component setup in a system like ours (content-types, widgets, forms, etc.). \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Repoze-dev] [Zope-dev] Re: repoze.bfg
Martijn Faassen wrote: Hey, Chris McDonough wrote: [snip] Correct, if you're talking about using the Z3 publisher, although repoze.bfg is based on zope.component and zope.interface internally. I wasn't primarily thinking about the publisher, more about such things like existing utilities, events, existing content types and so on. Most of those would work. We don't implement local site managers, but we do use a normal component registry, so if you've got a global utility that you'd like to use, you'd just put its registration into the configure.zcml, make sure you had the right package on the filesystem to handle that registration. ... Speaking of site managers, if you'd like to be able to use more than one separtely-configured grok application in a process (given that you can't right now because the global registry is a singleton), you might want to steal this hack. I myself stole the idea from Stephan's z3c.baseregistry: http://svn.repoze.org/repoze.bfg/trunk/repoze/bfg/registry.py Sending events would of course work. We don't have any event *listeners*, of course, so it would be pointless to send, e.g. object events. That said, contenty stuff is not really the job of repoze.bfg, but of a higher-layer framework. repoze.bfg is about traversing the content graph and publishing views and templates. Everything else is the domain of the application. Existing content types would work to the extent that you'd just use them as data in the ZODB, allowing bfg to traverse the ZODB as the root. This is also the domain of the application in terms of bfg. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: repoze.bfg
Hi there, On Thu, Jul 17, 2008 at 9:19 PM, Malthe Borch [EMAIL PROTECTED] wrote: Martijn Faassen wrote: Could you be more explicit about what exactly in Grok was making too many assumptions? First a word on terminology: I mean Grok, the framework, not the declarative extensions to the component architecture (which I simply haven't gotten to yet). We felt that Grok was too much about object publishing; there's a model and a view for that model (and that view has a template). This didn't fit so well into our approach. [snip explanations] Thanks for those. I like Grok and I think it's great for writing Zope *applications*; but we didn't find it such a good match for Vudo. I still want to try grokcore.component because there are some obvious candidates for declarative component setup in a system like ours (content-types, widgets, forms, etc.). So basically you felt Zope 3 wasn't a good match for Vudo, in the sense that the normal browser:page wasn't really want you wanted either, right? Similar to the way you could extend Zope 3 with your own new ZCML directives to set up the way you'd like views to work (I'm not sure whether you're doing this), you could as well extend Grok with your own new grokkers. I just didn't want Grok singled out here - I don't to leave people with the impression that Grok locks them into a certain approach any more than Zope 3-the-application-framework does; I don't believe it does. Of course Zope 3-the-libraries leave the options more open, witness this thread. The various grok libraries (martian, grokcore.component) should be seen as part of this wider ecosystem as well. I hope that some of your explorations concerning layouts could be plugged into Grok as a library eventually. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: repoze.bfg
Martijn Faassen wrote: So basically you felt Zope 3 wasn't a good match for Vudo, in the sense that the normal browser:page wasn't really want you wanted either, right? Similar to the way you could extend Zope 3 with your own new ZCML directives to set up the way you'd like views to work (I'm not sure whether you're doing this), you could as well extend Grok with your own new grokkers. Correct. And we did create a new directive to define layouts. I actually think ZCML is very suitable when you're configuring stuff that hasn't to do with code. Whether it's good for configuring code is for another discussion. I just didn't want Grok singled out here - I don't to leave people with the impression that Grok locks them into a certain approach any more than Zope 3-the-application-framework does; I don't believe it does. Of course Zope 3-the-libraries leave the options more open, witness this thread. The various grok libraries (martian, grokcore.component) should be seen as part of this wider ecosystem as well. That's a good point. Certainly Grok proves to be quite flexible, but it's still very centralized on defining a set of components and have them automatically glued together. I think Grokkish ideas will make much sense in Vudo *applications*. For the framework code I'm a bit more conversative. I hope that some of your explorations concerning layouts could be plugged into Grok as a library eventually. The layout stuff is definitely easy to reuse and I think Brandon already has a good grasp on how it might fit in. The key idea with ``vudo.layout`` is that you can just plug in HTML and have it work. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
