Re: [Zope-dev] zope.app.container 3.5.4 bugfix release
Baiju M a écrit : - Christophe Combelles [EMAIL PROTECTED] wrote: I've added a tag for the 3.5.4 bugfix release of zope.app.container. Could someone please add me on the owners list on pypi so that I can upload it? Your PyPI ID ? ccomb -- Baiju M ___ 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[3]: [Zope-dev] zope.testing 3.6.0 released
Hello, Seems like 86460 breaks it. I have some idea why testrunner-coverage.txt does not detect this. I think it is doing coverage just on the tests code. There seems to be no application-like code. All code seems to come from testcases, doctests, docfiles. So far I can see. Right now I'm under some time pressure so implementation (of the test) will have to wait. -- Best regards, Adam GROSZERmailto:[EMAIL PROTECTED] -- Quote of the day: Even if you're on the right track, you'll get run over if you just sit there. - Will Rogers ___ 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
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: [Plone-developers] repoze.bfg
Previously 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. 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 templates - page templates controllers - the pylons-version of views. sort-of. config - everything related to the appplication configuration lib - all our utilities models - data models public - static web content Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Wed Jul 16 11:00:00 2008 UTC to Thu Jul 17 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Wed Jul 16 20:57:23 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009865.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jul 16 20:58:53 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009866.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jul 16 21:00:23 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009867.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jul 16 21:01:54 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009868.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Wed Jul 16 21:03:24 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009869.html ___ 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] zope.app.container 3.5.4 bugfix release
- Christophe Combelles [EMAIL PROTECTED] wrote: Baiju M a écrit : - Christophe Combelles [EMAIL PROTECTED] wrote: I've added a tag for the 3.5.4 bugfix release of zope.app.container. Could someone please add me on the owners list on pypi so that I can upload it? Your PyPI ID ? ccomb Done. -- Baiju M ___ 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] Buildout site
Hi all, Few weeks back Buildout site become live, Jens Vagelpohl setup the site at http://buildout.zope.org/ But I couldn't work further on the site. If anyone want contribute to the content please add it here: svn co svn://svn.zope.org/repos/main/buildout-website/trunk/ Regards, Baiju M ___ 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] Buildout site
On Jul 17, 2008, at 14:02 , Baiju M wrote: Hi all, Few weeks back Buildout site become live, Jens Vagelpohl setup the site at http://buildout.zope.org/ But I couldn't work further on the site. If anyone want contribute to the content please add it here: svn co svn://svn.zope.org/repos/main/buildout-website/trunk/ Just FYI, the final resting place for this information will likely be inside a more general documentation website, the address buildout.zope.org is just a temporary resting place. jens ___ 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-dev] 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. 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) Sure. I think one of us (maybe Paul?) signed up to write a PasteScript template to lay out a directory structure something like this. We don't currently provide an easy way to serve out a static directory full of content. We'd need to add that (or decide not to add it in favor of letting a separate resource server serve the static stuff). 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 Sounds good to me. The plans are to keep BFG mostly policy-agnostic save for the very basics (graph traversal, a default templating language, and a calling and response convention for views). I had planned to create another package named repoze.lemonade which: - Wired in ZODB - Defined base classes for folderish and leafish types. - Had an object add/remove/move event model. - Did indexing of content. It sounds like Vudo could either build on top of that or just *be* that. It might be better to continue layering stuff, I suppose, without going straight to the content management layer. Would it be appropriate for Vudo to build on something like that? What would Vudo need out of a framework? - 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] zope.sqlalchemy and in-memory sqlite
With an in-memory engine, I seem to lose track of the tables after the first response. Turn of events: 1. Request comes in 2. Create some tables 3. Add content and commit transaction 4. Query content 5. Return response Now... 6. New request comes in 7. Query content (OperationalError) no such table: mytable ... With a disk-based database, no errors occur. The point of my little story line was to illustrate that this does not have anything to do with transactions being committed. \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: [Zope-dev] Zope 3 on Python 2.5, Zope 3 releases
Hi there, Yeah, I share this worry. I wonder what Jim is using. If Jim is using a mingw setup too, then there seems to be no real problem, after all. :) 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] Zope 3 on Python 2.5, Zope 3 releases
On Thursday 17 July 2008, Martijn Faassen wrote: Yeah, I share this worry. I wonder what Jim is using. If Jim is using a mingw setup too, then there seems to be no real problem, after all. :) He does. :-) And I do too. I released several Windows binary eggs based on that setup as well. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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] Zope 3 on Python 2.5, Zope 3 releases
On Thu, Jul 17, 2008 at 12:54 PM, Stephan Richter [EMAIL PROTECTED] wrote: On Thursday 17 July 2008, Martijn Faassen wrote: Yeah, I share this worry. I wonder what Jim is using. If Jim is using a mingw setup too, then there seems to be no real problem, after all. :) He does. :-) And I do too. I released several Windows binary eggs based on that setup as well. Mingw compiled extensions are binary-compatible yes. Mark Hammond has confirmed that at least once to me. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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] Zope 3 on Python 2.5, Zope 3 releases
Hi there, Okay, so we can safely add Chris (and also Philipp) to the list of people maintaining our windows binary eggs. Awesome! Chris, do you think you can take it from here in getting an environment set up? Regard, 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: Buildout site
Hey, Thanks Baiju for getting it this far and Jens for helping to set it up! Jens Vagelpohl wrote: On Jul 17, 2008, at 14:02 , Baiju M wrote: Few weeks back Buildout site become live, Jens Vagelpohl setup the site at http://buildout.zope.org/ But I couldn't work further on the site. If anyone want contribute to the content please add it here: svn co svn://svn.zope.org/repos/main/buildout-website/trunk/ Just FYI, the final resting place for this information will likely be inside a more general documentation website, the address buildout.zope.org is just a temporary resting place. Just to make a discussion Jens and I were having in the background explicit. While it's good if this appears in the Zope stack documentation site, I think it's also important for there being a separate identity for the buildout project. This goes beyond documentation, but also talks about a developer community and invites people to use it in their own projects, as well as contribute. I also think an overview of recipes could be a good part of this. I think a separate website is part of such an identity. Other things that could help establish an identity are things like a logo. 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] transaction.doom() and ZPublisher
Brian Sutherland wrote at 2008-7-13 12:41 +0200: On Sun, Jul 13, 2008 at 09:05:16AM +0200, Dieter Maurer wrote: Andreas Jung wrote at 2008-7-12 07:17 +0200: ... What do you mean by higher level? I think that the check within the ZPublisher is the highest and right place. Code running after the commit() expects a new transaction and now will not get that. You refer to code executed as part of a ZODB post-commit handler? If a transaction is doomed then such handlers should never be executed - right? The problem is that a doomed transaction prevents joining. This means that any operation that causes a join during error handling will fail. Examples are: accessing a session, accessing a relational database. The bug is in the ZODB (transaction) code. A doomed transaction should not prevent joining. Do you have an example of this bug? It should be fixed. It is already tested in doom.txt like this: Thus, maybe, someone already has fixed this problem. In this case, executing the error handling in the same transaction as the main request should no longer make problems (this was where I have seen the bug). -- Dieter ___ 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: Buildout site
Baiju M wrote: Hi all, Few weeks back Buildout site become live, Jens Vagelpohl setup the site at http://buildout.zope.org/ But I couldn't work further on the site. If anyone want contribute to the content please add it here: svn co svn://svn.zope.org/repos/main/buildout-website/trunk/ One thing I wondered is whether we cannot make the buildout website, at least the documentation bits, part of the buildout SVN project itself. This way we can make release specific documentation releases as well, like for instance Python does. We do still need an entry page for the buildout site itself, though. Perhaps this could also be maintained in the buildout svn. 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
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 )
[Zope-dev] how do you run the zc.buildout test suite?
How is zc.buildout meant to have its tests run? On Mac OS X, in a checkout from svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk Doing: $ python2.4 bootstrap/bootstrap.py $ bin/buildout results in: [EMAIL PROTECTED] zc.buildout]$ bin/buildout Develop: '/Users/chrism/projects/zc.buildout/zc.recipe.egg_' Develop: '/Users/chrism/projects/zc.buildout/.' While: Installing. Getting section test2.3. Initializing part test2.3. Getting section python2.3. Error: The referenced section, 'python2.3', was not defined. And doing: $ python2.4 setup.py test -q gives me a raft of test failures, which leads me to believe the tests weren't meant to be run this way. What's the right way to run the test suite? - 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
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 )
Re: [Zope-dev] how do you run the zc.buildout test suite?
On Jul 17, 2008, at 3:00 PM, Chris McDonough wrote: How is zc.buildout meant to have its tests run? It's a bit of a mess, because of bootstrapping issues. On Mac OS X, in a checkout from svn+ssh://svn.zope.org/repos/main/ zc.buildout/trunk Doing: $ python2.4 bootstrap/bootstrap.py $ bin/buildout For working on buildout, use dev.py rather than bootstrap.py. results in: [EMAIL PROTECTED] zc.buildout]$ bin/buildout Develop: '/Users/chrism/projects/zc.buildout/zc.recipe.egg_' Develop: '/Users/chrism/projects/zc.buildout/.' While: Installing. Getting section test2.3. Initializing part test2.3. Getting section python2.3. Error: The referenced section, 'python2.3', was not defined. Gah. I'm getting a similar error. This is a result of an attempt of mine to build multiple test runners at once, but it's too brittle. I've reverted back to a simpler configuration. And doing: $ python2.4 setup.py test -q gives me a raft of test failures, which leads me to believe the tests weren't meant to be run this way. They aren't. I added the associated setup arguments before I learned how they work, What's the right way to run the test suite? Make sure you svn up to get the latest configuration, then: python dev.py bin/test Unfortunately there's a test failure in the rmtree module for me. I'll get after the author of that module. Jim -- Jim Fulton Zope Corporation ___ 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 )
[Zope-dev] Re: [Repoze-dev] repoze.bfg
Malthe Borch [EMAIL PROTECTED] writes: 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. Someone mentioned Vudo to me last week. I said that I was tempted to write an extension to Grok that lets you create a grok.Layout template that maybe is inherited throughout your whole site if you don't specify otherwise, and then a grok.View on an object would just generate content for the main pane inside of that layout, and viewlets could keep working like they do today but fill in other parts of the layout. This is kind of how people look to be doing things today with the viewlets revolution that's going on in Grok land; look at: http://svn.zope.org/Grokstar/trunk/src/grokstar/blog.py?rev=87483view=auto and note how many of the grok.View objects are specifying the same dratted template, over and over again, and then rely on viewlets to actually fill in the varying parts of each page that change with the content. It struck me as a situation that is just crying out for a grok.Layout local utility that provides the template everywhere under a part of a site automatically, so that the grok.template(...) declaration does not have to get repeated so incessantly. It really looks to me like Grok best-practices are evolving towards a layout-centric, rather than a macro-centric, approach, and that something like the Vudo approach would make this all easier to manage. Do I sound on-target, or like I'm missing something? -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ 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 )
[Zope-dev] Re: [Repoze-dev] repoze.bfg
Chris McDonough wrote: I had planned to create another package named repoze.lemonade which: ... - Did indexing of content. What were you thinking of for indexing? Just catalog stuff? More general? There's been a tension in the opencore stuff with the catalog, mostly that it's easy to setup and use for things, but it doesn't really work for things outside of the ZODB. Or, I guess theoretically you could catalog things not in the ZODB, but it's never happened. That said, there's a real need for cross-system indexing of different kinds. There's text search indexes, but other kinds of more strict indexes also make sense. It would be very handy to have an index that wasn't tied to the ZODB, a database, or anything else. (It could be implemented using the ZODB or a database, of course.) -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org ___ 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] zope.app.container 3.5.4 released
Baiju M a écrit : - Christophe Combelles [EMAIL PROTECTED] wrote: Baiju M a écrit : - Christophe Combelles [EMAIL PROTECTED] wrote: I've added a tag for the 3.5.4 bugfix release of zope.app.container. Could someone please add me on the owners list on pypi so that I can upload it? Your PyPI ID ? ccomb Done. Released! -- Baiju M ___ 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-dev] repoze.bfg
Ian Bicking wrote: Chris McDonough wrote: I had planned to create another package named repoze.lemonade which: ... - Did indexing of content. What were you thinking of for indexing? Just catalog stuff? More general? I was considering just using zope.index but I haven't really thought much about it yet. There's been a tension in the opencore stuff with the catalog, mostly that it's easy to setup and use for things, but it doesn't really work for things outside of the ZODB. Or, I guess theoretically you could catalog things not in the ZODB, but it's never happened. IMO, mostly it's a matter of deciding what index and catalog means for searching. If you only need full-text search, some indexing systems are totally inappropriate. Likewise, if you only need field indexes that match just one particular value, it's sometimes vastly simpler just to come up with your own system based on, e.g. a relational table, than it is to try to use somebody else's indexer or catalog. That said, there's a real need for cross-system indexing of different kinds. There's text search indexes, but other kinds of more strict indexes also make sense. It would be very handy to have an index that wasn't tied to the ZODB, a database, or anything else. (It could be implemented using the ZODB or a database, of course.) Xapian seems like a good choice too. It has its own persistence mechanism and reasonable Python bindings (although from experience maybe slightly memory-leaky). - 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-dev] repoze.bfg
Chris McDonough wrote: There's been a tension in the opencore stuff with the catalog, mostly that it's easy to setup and use for things, but it doesn't really work for things outside of the ZODB. Or, I guess theoretically you could catalog things not in the ZODB, but it's never happened. IMO, mostly it's a matter of deciding what index and catalog means for searching. If you only need full-text search, some indexing systems are totally inappropriate. Likewise, if you only need field indexes that match just one particular value, it's sometimes vastly simpler just to come up with your own system based on, e.g. a relational table, than it is to try to use somebody else's indexer or catalog. They are similar in that they both need to get information about updates, and a way to reindex. Full text search can be a little lazier, as being 100% up-to-date isn't such a big issue. That said, there's a real need for cross-system indexing of different kinds. There's text search indexes, but other kinds of more strict indexes also make sense. It would be very handy to have an index that wasn't tied to the ZODB, a database, or anything else. (It could be implemented using the ZODB or a database, of course.) Xapian seems like a good choice too. It has its own persistence mechanism and reasonable Python bindings (although from experience maybe slightly memory-leaky). Yes, once you get the documents into it. Actually, it's really a many-to-many notification system that's needed. We have one that needs documenting and review (http://www.openplans.org/projects/cabochon/project-home) but while it handles notifications and events (as do several other systems), that doesn't cover reindexing the site. And then you also need a set of useful endpoints, but those can grow over time. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org ___ 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-dev] repoze.bfg
Ian Bicking wrote: Chris McDonough wrote: There's been a tension in the opencore stuff with the catalog, mostly that it's easy to setup and use for things, but it doesn't really work for things outside of the ZODB. Or, I guess theoretically you could catalog things not in the ZODB, but it's never happened. IMO, mostly it's a matter of deciding what index and catalog means for searching. If you only need full-text search, some indexing systems are totally inappropriate. Likewise, if you only need field indexes that match just one particular value, it's sometimes vastly simpler just to come up with your own system based on, e.g. a relational table, than it is to try to use somebody else's indexer or catalog. They are similar in that they both need to get information about updates, and a way to reindex. Full text search can be a little lazier, as being 100% up-to-date isn't such a big issue. I'd typically handle the info about updates bit by sending an event (which I suspect cabochon is all about). That said, there's a real need for cross-system indexing of different kinds. There's text search indexes, but other kinds of more strict indexes also make sense. It would be very handy to have an index that wasn't tied to the ZODB, a database, or anything else. (It could be implemented using the ZODB or a database, of course.) Xapian seems like a good choice too. It has its own persistence mechanism and reasonable Python bindings (although from experience maybe slightly memory-leaky). Yes, once you get the documents into it. Actually, it's really a many-to-many notification system that's needed. We have one that needs documenting and review (http://www.openplans.org/projects/cabochon/project-home) but while it handles notifications and events (as do several other systems), that doesn't cover reindexing the site. And then you also need a set of useful endpoints, but those can grow over time. Stuff that I'm not sure about above: many-to-many notification system reindexing the site That said... I guess what you're saying is that it's hard to send an event that makes it clear what needs to be done as a result of the event being sent. In the case where you have a content node that holds data, that node would be attched to the event. it's pretty clear that you need to do.. that thing changed, and the indexing code needs to inspect it and reindex whatever indexes you've got sitting around that are willing to index data about those types of nodes. In the case where you need to deal with the simultaneous case that some row in an RDB was changed, it's not quite as clear. What does it mean and who should do what with that event? It's all policy at that point. I'm not sure any framework helps. It's just block-and-tackle event reception and reaction, do the needful, isn't it? - 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: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond
On Wed, Jul 16, 2008 at 10:20:58AM +0200, Hermann Himmelbauer wrote: Am Mittwoch, 16. Juli 2008 05:48 schrieb Florian Friesdorf: InternalPrincipal is a persistent object used to store the data of principals in a PrincipalFolder, PrincipalInfo is returned upon successfull authentication and handed to FoundPrincipalFactory, which extracts some information and returns Principal objects. Ok, this is how I see it, too. But let me describe my understanding more specific: I see it that way that applications with authentication will normally have something like a user object, which stores all related authentication/user information. This user object may reside in a RDB, a text file, or, as here, in a PrincipalFolder (as an InternalPrincipal). I would put the object in quotation, too, as for example in RDB it isnt an object at all, but simply authentication data + properties and, yes, this corresponds to InternalPrincipal. If I understand it right, a Principal is an entity that is the result of an authentication process and holds all needed information for authorization. However, it is not designed to store user specific information, e.g. login names, user names and the like. And PrincipalInfo is somehow a specific aggregation of user data, which can be used throughout the application. This object may have to be inherited to an extended MyPrincipalInfo object, as many applications may need extra info from this object. So, both the Principal and PrincipalInfo objects have to be created out of the user object, it is not possible to create a Principal out of a PrincipalInfo and reverse. I think you are wrong here: zope.app.authentication.authentication.PluggableAuthentication.authenticate is the place to look at. 1. a PrincipalInfo object is got by calling authenticateCredentials from an authplugin 2. this is handed to an AuthenticatedPrincipalFactory, which returns a Principal object So, PrincipalInfo is internal to PAU and as far as I figured does not leave it. Objects that leave PAU are those created by AuthenticatedPrincipalFactories, for authentication, and by FoundPrincipalFactories, for searches - In case of PrincipalFolder that is Principal objects in both cases. Throughout my application, I have the following scenarios: - I need to display some user data (e.g. in a logged in viewlet): I'd use PrincipalInfo. I would use the principal object - I need to check for authorization somewhere in my application: I'd use the Principal. yes - I need to administer the user, e.g. change password etc.: I'd use the user object (InternalPrincipal) for that. I would again use the principal object, which transparently performs the changes wherever they are necessary, i.e all properties of the user are available from the Principal object and changes to them will happen on their actual source. - ??? In my application, all I have is the principal (request.principal). So I need a viable way to retrieve PrincipalInfo and User/internalPrincipal objects. How would I do that? principal is all you need, if it does not carry what you want, you can subscribe to FoundPrincipalCreated and AuthenticatedPrincipalCreated events and stuff on it whatever you need. - user object: There seems to be no zope3 support for that yet - so it seems I have to do this manually (some getUser(login) function, get the login from request.principal.id[lenAUTH_PREFIX):], not very pretty, though.). principal is the user object - PrincipalInfo: Don't really know - perhaps by somehow getting the PAU object and iterating over the authentication modules, calling some getPrincipalInfo method? I personally would favour some adapters, e.g.: InternalPrincipal = IInternalPrincipal(request) PrincipalInfo = IPrincipalInfo(request) In case you store your userdata in RDB, you do not need InternalPrincipal at all. I currently see to options: 1. custom AuthenticatorPlugin, AuthenticatedPrincipalFactory and FoundPrincipalFactory from principalfolder.py. Your AuthenticatorPlugin would need to return PrincipalInfo objects. Further, you write an event handler that listens for FoundPrincipalCreated and AuthenticatedPrincipalCreated, which puts all needed/wanted properties onto the Principal object, which was created by one of the factories. Those properties can be real python properties with get,set,del methods, which you can use to get,set,del the actual propety values wherever they may come from, e.g. an RDB. 2. you could further write your own factories and return whatever object you would like to represent your user in case of searches and in case of authentication. I think option1 is optimal for your use case, based on what you described so far. The current documentation leaves many of the above points open, or at least, did not describe them in a way so that I could understand them. Read the README.txt, look at the doctest in authentication.py and
[Zope-dev] Re: Buildout site
On Thu, Jul 17, 2008 at 2:17 PM, Martijn Faassen [EMAIL PROTECTED] wrote: Just FYI, the final resting place for this information will likely be inside a more general documentation website, the address buildout.zope.org is just a temporary resting place. Just to make a discussion Jens and I were having in the background explicit. While it's good if this appears in the Zope stack documentation site, I think it's also important for there being a separate identity for the buildout project. This goes beyond documentation, but also talks about a developer community and invites people to use it in their own projects, as well as contribute. I also think an overview of recipes could be a good part of this. I think a separate website is part of such an identity. Other things that could help establish an identity are things like a logo. I think this is a really fantastic idea. To speak broadly, it's great that you're so mindful of the real importance of identity -- in both a branding sense and simply in the sense of being a self-contained entity -- for the development of software communities and software itself. Buildout is a standalone product independent of the Zope framework or libraries, but that's only meaningful if it actively establishes an independent identity in people's minds. I think you're doing a really great thing for the community by paying attention to these issues. So, in short, thanks. :) Cheers, Ethan 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 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 )
