Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Martijn Faassen wrote: It would be very nice if we could make that work! Zope as a drop-in Apache extension would certainly help wider adoption. Yes indeed :-) We're not a "normal" pythonish Apache thing though, 'cos we need to rigidly limit the number of app server threads because of the zodb object cache. That said, I'm pretty sure Apache could be tickled to support this... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Jim Fulton wrote: Does the Zope 2 server need that much work? It seems to do a pretty good job... I don't know. It does seem to do a pretty good job. But I'm not aware of any one else who's in a position to fix it if it breaks or needs to be enhanced. Anyone else apart from who? I'm sure if there was a need, volunteers (or people made volunteers out of necessity) would likely soon dive in... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Update on proposals for Zope 3.4 (was: [SpringCleaning07])
Hi, I've updated the spring cleaning proposal with the suggestions (and additional votes from people posting in this thread). Please have a look at: http://wiki.zope.org/zope3/SpringCleaning07 There still is an open sub-task, to check for packages that are in src/ but not distributed with a release nowadays. @Jim: I put the buildout integration onto the prospective features list and I guess this is quite a bit of a project. I picked up your idea for buildout integration from a mailing list thread in the archive, but didn't see any more specifics. Would be nice if you could give a few sentences of input about the idea so we can relate to it. I'm not sure we should target it for Zope 3.4, but I have the feeling that SpringCleaning, Eggification and buildout integration kind of go together. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Weird package in Zope 3 core: "optionstorage"
On Dec 20, 2006, at 2:42 AM, Christian Theune wrote: Hi again, Christian Theune wrote: Hi, I just stumbled over the package "optionstorage". The checkin message when this was added reads: "This is a generic solution for including editable and multi-lingual vocbulary-like information in any annotatable object." I'm not sure what that means. Does anybody remember? FWIW, I glanced at this too. This is another part of the initial checkin information to which Christian referred; seems like Gustavo or Stephan might know about it. r28445 | niemeyer | 2004-11-12 13:49:40 -0500 (Fri, 12 Nov 2004) | 5 lines Adding "optionstorage" product to src/, as requested by Stephan Richter. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Cleaning up the widget mess a little bit: bug or feature
On Dec 19, 2006, at 2:34 AM, Christian Theune wrote: Hi again, Gary Poster wrote: I don't have a very strong feeling about it, but lean towards "bug fix". It didn't break any of our code (or at least any of our tests :-) ) so it seems safe from my perspective. I was trying to apply the patch to the 3.3 branch and noticed that the patch isn't compatible, as it requires a restructuring that happened on the trunk a while ago. This refactoring (r70331) introduces a very small feature, but the broken behaviour (trying to put anything into _toFormValue) exists in the old variant as well. It's a bit murky, since 70331 only changes internal APIs, but unfortunately the widget subclass API is effectively public in IMO. I don't think 70331 is ok to push back, unfortunately. A shame, but then the easiest thing to do is treat 71548 as a feature too; the other option would be to revise the fix in 71548 for pre-70331. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [SpringCleaning07]
Roger Ineichen wrote: Hi Martijn Subject: [Zope3-dev] Re: [SpringCleaning07] By the way, I'm quite interested in seeing whether we can integrate Genshi into Zope 3 and Grok as a templating language. It has some interesting ways to do things, and there's quite a bit of momentum behind it. I saw the Grok package but what is Genshi? Can you point me to a link? http://genshi.edgewall.org Inspired by Kid (in turn among others inspired by ZPT), the main template language of TurboGears, written by the people who also created Trac, and it seems to be getting traction. TurboGears among others is going to adopt it, but also things like the creator of SQLAlchemy (and Myghthy) spending time optimizing it, etc. It's close enough to ZPT to be palatable to me, and has some nice features for reuse. If we're going to get out of the server business we could also consider getting out of the template language business. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Update on proposals for Zope 3.4
Christian Theune wrote: Hi, I've updated the spring cleaning proposal with the suggestions (and additional votes from people posting in this thread). I think it's a good idea to let anything that has any vote *against* removing from the core stay in the core for now (unless someone goes insane on power and votes everything into the core :). That would mean that zope.app.renderer stays in core. I think that's good for another reason too: something that has dependencies elsewhere (apidoc in this case) is a lot harder to remove than something that doesn't. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Cleaning up the widget mess a little bit: bug or feature
Hi, Gary Poster wrote: > On Dec 19, 2006, at 2:34 AM, Christian Theune wrote: > >> Hi again, >> >> Gary Poster wrote: >>> I don't have a very strong feeling about it, but lean towards "bug >>> fix". It didn't break any of our code (or at least any of our >>> tests :-) ) so it seems safe from my perspective. >> I was trying to apply the patch to the 3.3 branch and noticed that the >> patch isn't compatible, as it requires a restructuring that >> happened on >> the trunk a while ago. This refactoring (r70331) introduces a very >> small >> feature, but the broken behaviour (trying to put anything into >> _toFormValue) exists in the old variant as well. > > It's a bit murky, since 70331 only changes internal APIs, but > unfortunately the widget subclass API is effectively public in IMO. > I don't think 70331 is ok to push back, unfortunately. A shame, but > then the easiest thing to do is treat 71548 as a feature too; the > other option would be to revise the fix in 71548 for pre-70331. I've had the same feeling initially. I'm looking at 70331 again and don't think it's too bad. Agreed, the potential for an incompatibility is there, because some client code might have used _getCurrentValue already in a subclass. (But then again, we would face the same problem when introducing _getCurrentValue in general.) The interface for _getFormValue remains stable and the code didn't change. The only thing that changed is that the responsibility of retrieving the value and converting it to it's form representation was split over two methods instead of a single. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Cleaning up the widget mess a little bit: bug or feature
On Dec 20, 2006, at 7:15 AM, Christian Theune wrote: Hi, Gary Poster wrote: On Dec 19, 2006, at 2:34 AM, Christian Theune wrote: Hi again, Gary Poster wrote: I don't have a very strong feeling about it, but lean towards "bug fix". It didn't break any of our code (or at least any of our tests :-) ) so it seems safe from my perspective. I was trying to apply the patch to the 3.3 branch and noticed that the patch isn't compatible, as it requires a restructuring that happened on the trunk a while ago. This refactoring (r70331) introduces a very small feature, but the broken behaviour (trying to put anything into _toFormValue) exists in the old variant as well. It's a bit murky, since 70331 only changes internal APIs, but unfortunately the widget subclass API is effectively public in IMO. I don't think 70331 is ok to push back, unfortunately. A shame, but then the easiest thing to do is treat 71548 as a feature too; the other option would be to revise the fix in 71548 for pre-70331. I've had the same feeling initially. I'm looking at 70331 again and don't think it's too bad. Agreed, the potential for an incompatibility is there, because some client code might have used _getCurrentValue already in a subclass. (But then again, we would face the same problem when introducing _getCurrentValue in general.) The interface for _getFormValue remains stable and the code didn't change. The only thing that changed is that the responsibility of retrieving the value and converting it to it's form representation was split over two methods instead of a single. Hm, ok. That does sound more workable than the skim of the diff appeared. (FWIW, we also have the internal evidence of backwards compatibility that our private and public packages didn't need to be adjusted for this change.) I'll +1 this. :-) Thanks, Christian! Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
Martijn Faassen wrote: http://genshi.edgewall.org Inspired by Kid (in turn among others inspired by ZPT), the main template language of TurboGears, written by the people who also created Trac, and it seems to be getting traction. TurboGears among others is going to adopt it, but also things like the creator of SQLAlchemy (and Myghthy) spending time optimizing it, etc. It's close enough to ZPT to be palatable to me, and has some nice features for reuse. If we're going to get out of the server business we could also consider getting out of the template language business. :) Martijn I'm a big fan of using lxml.etree for templating. Very pythonic, very easy to refactor, very explicit. It's premature to announce (we plan to have eggs on pypi soon) , but take a look at zif.xtemplate at zif.sourceforge.net . It's pretty alpha at the moment, but it uses a DTD and some xpath to get around the "tags that shouldn't be minimized" issue, and it includes a first stab at an HTML sanitizer, to use when snippets of untrusted HTML are to be included on a page. In addition, the entire page DOM is available for postprocessing right up until serialization. Of course, those with better lxml knowledge are encouraged to point out issues with the implementation. -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [SpringCleaning07]
Jim Washington wrote: Martijn Faassen wrote: http://genshi.edgewall.org Inspired by Kid (in turn among others inspired by ZPT), the main template language of TurboGears, written by the people who also created Trac, and it seems to be getting traction. TurboGears among others is going to adopt it, but also things like the creator of SQLAlchemy (and Myghthy) spending time optimizing it, etc. It's close enough to ZPT to be palatable to me, and has some nice features for reuse. If we're going to get out of the server business we could also consider getting out of the template language business. :) I'm a big fan of using lxml.etree for templating. Very pythonic, very easy to refactor, very explicit. Cool! It's premature to announce (we plan to have eggs on pypi soon) , but take a look at zif.xtemplate at zif.sourceforge.net . It's pretty alpha at the moment, but it uses a DTD and some xpath to get around the "tags that shouldn't be minimized" issue, and it includes a first stab at an HTML sanitizer, to use when snippets of untrusted HTML are to be included on a page. In addition, the entire page DOM is available for postprocessing right up until serialization. Of course, those with better lxml knowledge are encouraged to point out issues with the implementation. I just took a brief look at this. Do I understand that this templating solution basically generates the entire template from Python? There is no actual textual template present at all, right? I understand you could add them back and use XPath, the elementtree API and even XSLT to generate templates, but in the default there is no template? I have used this approach when I needed to generate very particular XML, but for web templating I generally expect there to be a textual template. This way it becomes more easy to take a template created by a designer and integrate it into ones system. What are your thoughts about this? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
Martijn Faassen wrote: Jim Washington wrote: Martijn Faassen wrote: http://genshi.edgewall.org Inspired by Kid (in turn among others inspired by ZPT), the main template language of TurboGears, written by the people who also created Trac, and it seems to be getting traction. TurboGears among others is going to adopt it, but also things like the creator of SQLAlchemy (and Myghthy) spending time optimizing it, etc. It's close enough to ZPT to be palatable to me, and has some nice features for reuse. If we're going to get out of the server business we could also consider getting out of the template language business. :) I'm a big fan of using lxml.etree for templating. Very pythonic, very easy to refactor, very explicit. Cool! It's premature to announce (we plan to have eggs on pypi soon) , but take a look at zif.xtemplate at zif.sourceforge.net . It's pretty alpha at the moment, but it uses a DTD and some xpath to get around the "tags that shouldn't be minimized" issue, and it includes a first stab at an HTML sanitizer, to use when snippets of untrusted HTML are to be included on a page. In addition, the entire page DOM is available for postprocessing right up until serialization. Of course, those with better lxml knowledge are encouraged to point out issues with the implementation. I just took a brief look at this. Do I understand that this templating solution basically generates the entire template from Python? There is no actual textual template present at all, right? I understand you could add them back and use XPath, the elementtree API and even XSLT to generate templates, but in the default there is no template? I have used this approach when I needed to generate very particular XML, but for web templating I generally expect there to be a textual template. This way it becomes more easy to take a template created by a designer and integrate it into ones system. What are your thoughts about this? The current implementation allows you to start with an HTML file. That's the "template" class parameter, which is the full path to an initial (well-formed) document, which is parsed on __init__ into an ElementTree. If it has "id" attributes in tags, all the better for hooking-in dynamic content. At the moment, there is a bit of an issue with namespaces / namespaced elements and attributes, but a file with standard, non-namespaced HTML will work just fine. -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: [SpringCleaning07]
Hi Martijn > > I saw the Grok package but what is Genshi? > > Can you point me to a link? > > http://genshi.edgewall.org > > Inspired by Kid (in turn among others inspired by ZPT), the > main template language of TurboGears, written by the people > who also created Trac, and it seems to be getting traction. > TurboGears among others is going to adopt it, but also things > like the creator of SQLAlchemy (and > Myghthy) spending time optimizing it, etc. It's close enough > to ZPT to be palatable to me, and has some nice features for reuse. > > If we're going to get out of the server business we could > also consider getting out of the template language business. :) Looks great in a first overview. Let me know if you or somebody else starts to port it to z3. I'm interessted to using another template language in z3 too. Thanks for the hint Roger > Regards, > > Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: [SpringCleaning07]
Hi Jim, > It's premature to announce (we plan to have eggs on pypi > soon) , but take a look at zif.xtemplate at > zif.sourceforge.net . It's pretty alpha at the moment, but > it uses a DTD and some xpath to get around the "tags that > shouldn't be minimized" issue, and it includes a first stab > at an HTML sanitizer, to use when snippets of untrusted HTML > are to be included on a page. In addition, the entire page > DOM is available for postprocessing right up until > serialization. Of course, those with better lxml knowledge > are encouraged to point out issues with the implementation. What's up with jsonserver? Did you move the package to a new repository? Can you offer a mailinglist for the zif packages? I'm very interested in observing the state of jsonserver since we use it most projects. Can you give a short statement about the zif and jsonserver repo? Regards Roger Ineichen > -Jim Washington > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] z3+squid+Unauthorized = weirdness
Hello, Just happened the following: zope3 server | | squid proxy / \ / \ / \ userA userB Both my users are sitting behind a squid proxy/firewall. That is a usual out-of-the-box SuSe linux firewall/proxy config. Each request goes through the squid proxy. userA does NOT have permission to http://zope3/ap_test/folder1. userB has permission to everything, including http://zope3/ap_test/folder1, he might even be a zope.manager. 1. userA accesses http://zope3/ap_test/folder1 2. userA gets the usual "Unauthorized, You are not authorized" message 3. userB accesses http://zope3/ap_test/folder1 4. BANG!, userB gets also the "Unauthorized, You are not authorized" message Investigating further, the request at 3. does not get to the zope3 server. It got served by squid. Adding the "no-store, no-cache, must-revalidate" etc. headers to the Unauthorized page solves the problem. Any opinions about that? Is it my mistake, a squid bug, a Z3 bug? -- Best regards, Adam mailto:[EMAIL PROTECTED] -- Quote of the day: Reality is for people who can't cope with fantasy. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] z3+squid+Unauthorized = weirdness
On Wed, Dec 20, 2006 at 02:36:59PM +0100, Adam Groszer wrote: > Hello, > > Just happened the following: > >zope3 > server > | > | > squid proxy > / \ >/ \ > / \ > userA userB > > Both my users are sitting behind a squid proxy/firewall. > That is a usual out-of-the-box SuSe linux firewall/proxy config. > Each request goes through the squid proxy. > userA does NOT have permission to http://zope3/ap_test/folder1. > userB has permission to everything, including http://zope3/ap_test/folder1, > he might even be a zope.manager. > > 1. userA accesses http://zope3/ap_test/folder1 > 2. userA gets the usual "Unauthorized, You are not authorized" message > 3. userB accesses http://zope3/ap_test/folder1 > 4. BANG!, userB gets also the "Unauthorized, You are not authorized" message > > Investigating further, the request at 3. does not get to the zope3 > server. It got served by squid. > > Adding the "no-store, no-cache, must-revalidate" etc. headers to the > Unauthorized page solves the problem. > > Any opinions about that? Is it my mistake, a squid bug, a Z3 bug? Er, more like a squid feature, see negative_ttl. Not sure what the best way is to get around this though, "no-cache" is probably reasonable. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
Roger Ineichen wrote: Hi Jim, It's premature to announce (we plan to have eggs on pypi soon) , but take a look at zif.xtemplate at zif.sourceforge.net . It's pretty alpha at the moment, but it uses a DTD and some xpath to get around the "tags that shouldn't be minimized" issue, and it includes a first stab at an HTML sanitizer, to use when snippets of untrusted HTML are to be included on a page. In addition, the entire page DOM is available for postprocessing right up until serialization. Of course, those with better lxml knowledge are encouraged to point out issues with the implementation. What's up with jsonserver? Did you move the package to a new repository? Can you offer a mailinglist for the zif packages? I'm very interested in observing the state of jsonserver since we use it most projects. Can you give a short statement about the zif and jsonserver repo? Hi, Roger There has been interest in a namespace for the packages I have been offering. And a public repository. And eggs. David Pratt and I have been working on this on sourceforge for less than a week, so I was definitely a bit premature in pointng anyone to the SourceForge site. Unfortunately, I just could not help saying something about xtemplate while templating was being discussed here. So, a short statement about zif and jsonserver: zif.jsonserver on sourceforge is the same as jsonserver on codespeak, except for a bit of an update for a zif namespace. There will be some kind of announcement after we are satisfied with an upcoming release. Additional contributors will, of course, be welcome. Roger, I acknowledge your interest in a mailing list. I think it would be a good idea, though I am a bit hesitant ATM to start YAFML. I think it may be just a matter of throwing a switch on SF, so it is certainly doable. For the moment, the Zif Collective is all "alpha" and experimental on SourceForge. Nothing released. Nothing to be alarmed about. Nothing decided about other repositories. -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: [SpringCleaning07]
Hi Jim, > Subject: Re: [Zope3-dev] Re: [SpringCleaning07] > > What's up with jsonserver? [...] > Hi, Roger > [...] > For the moment, the Zif Collective is all "alpha" and > experimental on SourceForge. Nothing released. Nothing to > be alarmed about. Nothing decided about other repositories. That's ok for me. Just keep it going and tell us if you have more such nice packages like jsonserver. Regards Roger Ineichen > -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [SpringCleaning07]
On Wed, 2006-20-12 at 12:52 +0100, Martijn Faassen wrote: > http://genshi.edgewall.org > > Inspired by Kid (in turn among others inspired by ZPT), the main > template language of TurboGears, written by the people who also created > Trac, and it seems to be getting traction. TurboGears among others is > going to adopt it, but also things like the creator of SQLAlchemy (and > Myghthy) spending time optimizing it, etc. It's close enough to ZPT to > be palatable to me, and has some nice features for reuse. > > If we're going to get out of the server business we could also consider > getting out of the template language business. :) To be quite frank, the templating language doesn't really mean a whole lot to me. I could use just about anything. I would certainly support having Zope getting out of the template language business. But I think it would be import for Zope to include a default templating language (if that's kid, genshi, whatever). Regards, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [SpringCleaning07]
Rocky Burt wrote: On Wed, 2006-20-12 at 12:52 +0100, Martijn Faassen wrote: http://genshi.edgewall.org Inspired by Kid (in turn among others inspired by ZPT), the main template language of TurboGears, written by the people who also created Trac, and it seems to be getting traction. TurboGears among others is going to adopt it, but also things like the creator of SQLAlchemy (and Myghthy) spending time optimizing it, etc. It's close enough to ZPT to be palatable to me, and has some nice features for reuse. If we're going to get out of the server business we could also consider getting out of the template language business. :) To be quite frank, the templating language doesn't really mean a whole lot to me. I could use just about anything. Even if it's slow, doesn't offer reuse functionality and is supported by just me, say? :) It matters to me especially when we're talking about reuse. Template languages differ significantly in their approach. I also prefer to pick something that has a certain momentum and a certain performance. As a side topic, I'm also slowly coming to the conclusion that tales path expressions are a waste of time and effort. We spent a lot of time making sure that we can express something as a path expression, and a Python expression would be just as easy to read and explain. We're not stopping people from writing more complicated python expressions anyway, and there are real cases where they're needed. A very different templating mechanism where there is no Python at all and data is always pregenerated before rendering is still attractive for other reasons, but in the ZPT case I've become less and less convinced it's worth the hassle. The nice thing then about something like Genshi is that instead of: python:foo.bar I can simply write: foo.bar Python expressions in TAL are cumbersome in part because they're simply hard to type, not because they're necessarily *complicated*. I would certainly support having Zope getting out of the template language business. But I think it would be import for Zope to include a default templating language (if that's kid, genshi, whatever). Hm, with 'getting out of the web server business' I at least always meant that we should still offer a default web server. We should also offer a default templating language. We should just not have to maintain that web server or templating language ourselves anymore. "Getting out of the X business" doesn't mean we don't evaluate and choose X. It just means we stop maintaining and developing X all by ourselves. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [SpringCleaning07]
On Wed, 2006-20-12 at 16:47 +0100, Martijn Faassen wrote: > Rocky Burt wrote: > > On Wed, 2006-20-12 at 12:52 +0100, Martijn Faassen wrote: > >> http://genshi.edgewall.org > >> > >> Inspired by Kid (in turn among others inspired by ZPT), the main > >> template language of TurboGears, written by the people who also created > >> Trac, and it seems to be getting traction. TurboGears among others is > >> going to adopt it, but also things like the creator of SQLAlchemy (and > >> Myghthy) spending time optimizing it, etc. It's close enough to ZPT to > >> be palatable to me, and has some nice features for reuse. > >> > >> If we're going to get out of the server business we could also consider > >> getting out of the template language business. :) > > > > To be quite frank, the templating language doesn't really mean a whole > > lot to me. I could use just about anything. > > Even if it's slow, doesn't offer reuse functionality and is supported by > just me, say? :) Haha. Sure... as long as at least Martijn Faassen supports it I'm fine with it *grin* > It matters to me especially when we're talking about reuse. Template > languages differ significantly in their approach. I also prefer to pick > something that has a certain momentum and a certain performance. A strong +1 > As a side topic, I'm also slowly coming to the conclusion that tales > path expressions are a waste of time and effort. We spent a lot of time > making sure that we can express something as a path expression, and a > Python expression would be just as easy to read and explain. We're not > stopping people from writing more complicated python expressions anyway, > and there are real cases where they're needed. A very different > templating mechanism where there is no Python at all and data is always > pregenerated before rendering is still attractive for other reasons, but > in the ZPT case I've become less and less convinced it's worth the hassle. As days go by I care less and less about this. I hate writing HTML which obviously means I hate writing any page template that generates HTML :) And I find these days there is generally no lesser of any evils in this regard. > Hm, with 'getting out of the web server business' I at least always > meant that we should still offer a default web server. We should also > offer a default templating language. We should just not have to maintain > that web server or templating language ourselves anymore. "Getting out > of the X business" doesn't mean we don't evaluate and choose X. It just > means we stop maintaining and developing X all by ourselves. +10 Regards, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [SpringCleaning07]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Rocky Burt wrote: >> On Wed, 2006-20-12 at 12:52 +0100, Martijn Faassen wrote: >>> http://genshi.edgewall.org >>> >>> Inspired by Kid (in turn among others inspired by ZPT), the main >>> template language of TurboGears, written by the people who also created >>> Trac, and it seems to be getting traction. TurboGears among others is >>> going to adopt it, but also things like the creator of SQLAlchemy (and >>> Myghthy) spending time optimizing it, etc. It's close enough to ZPT to >>> be palatable to me, and has some nice features for reuse. >>> >>> If we're going to get out of the server business we could also consider >>> getting out of the template language business. :) >> To be quite frank, the templating language doesn't really mean a whole >> lot to me. I could use just about anything. > > Even if it's slow, doesn't offer reuse functionality and is supported by > just me, say? :) > > It matters to me especially when we're talking about reuse. Template > languages differ significantly in their approach. I also prefer to pick > something that has a certain momentum and a certain performance. > > As a side topic, I'm also slowly coming to the conclusion that tales > path expressions are a waste of time and effort. We spent a lot of time > making sure that we can express something as a path expression, and a > Python expression would be just as easy to read and explain. We're not > stopping people from writing more complicated python expressions anyway, > and there are real cases where they're needed. A very different > templating mechanism where there is no Python at all and data is always > pregenerated before rendering is still attractive for other reasons, but > in the ZPT case I've become less and less convinced it's worth the hassle. That is effectively the usecase for pushpage, which uses ZPT but binds *no* top-level names other than those supplied by the caller. > The nice thing then about something like Genshi is that instead of: > > python:foo.bar > > I can simply write: > > foo.bar Somebody still has to set up the top-level names; unless that is done by "trusted" code, you have security issues to consider. > Python expressions in TAL are cumbersome in part because they're simply > hard to type, not because they're necessarily *complicated*. I don't find them hard to type: I find them hard to *maintain*, becuase they are "arbitrarily complicated" in the sense that they have access to an almost unlimited universe of objects: it is this access which seduces people into using them to implement application logic. If they can't "pull" in the whole ZODB, then their intrinsic complexity goes down, and they can be used for doing real "presentation logic", as they were originally intended. >> I would certainly support >> having Zope getting out of the template language business. - -1. I don't mind making it easy to add other TLs, but don't have any urge to abandon ZPT (or even DTML). > But I think >> it would be import for Zope to include a default templating language (if >> that's kid, genshi, whatever). > > Hm, with 'getting out of the web server business' I at least always > meant that we should still offer a default web server. We should also > offer a default templating language. We should just not have to maintain > that web server or templating language ourselves anymore. "Getting out > of the X business" doesn't mean we don't evaluate and choose X. It just > means we stop maintaining and developing X all by ourselves. I'm actually -1 on "getting out of the server business" as well, at least in terms of the Zope2 ZServer: I don't see it as requiring much maintenance, and there *are* folks in the community (I can think of five or six, at least) who know Medusa / ZServer well enough to go forward. I *don't* know the Z3 version of ZServer well, however. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFiWf2+gerLs4ltQ4RAi3aAKCgYjbOP2X2Tn7wZWIcdZNXE3aUnwCfQHJ8 kD1In94y6C6a/l1LRW/pD9s= =Eo2M -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
On 12/20/06, Tres Seaver <[EMAIL PROTECTED]> wrote: I'm actually -1 on "getting out of the server business" as well, at least in terms of the Zope2 ZServer: I don't see it as requiring much maintenance, and there *are* folks in the community (I can think of five or six, at least) who know Medusa / ZServer well enough to go forward. From looking at the ZServer from Zope 3, I had the impression that it had significant improvements over the version from Zope 2, in that it's not so much of a complete rewrite than it's a cleanup/reorg. The few issues I have with the Zope 2 ZServer could be easily fixed by someone with a bit of time and Medusa knowledge. They are mainly due to the fact that handling 'streams' and 'gzip compression' are done inside the ZServer with some not so nice workarounds, instead of using the producers that medusa provides which would simplify ZServer a lot. The impression I had was that the person that added streaming and gzip did not know about the medusa producers. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] IProcessStartingEvent
Hi, Garanin Michael wrote: > Hello! > I not found raise "zope.app.appsetup.IProcessStartingEvent". Is it > deprecated? A quick check on the trunk tells me that it is triggered. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Z3d] 721/ 8 Comment "Handling of empty prefixes in zope.formlib and zope.app.form"
Hi Jacob, Jacob Holm wrote: > I don't have time to check it in now, but I will do it in a few days > unless i hear otherwise. I didn't see any change on this, if there is anything I can do to help or support your, I'd be happy to do so. No worries if you're just short on time (we're all on Christmas preparations!), I just wanted to follow up and keep this on the radar. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Removing SSL/SSH-Keys from Skeleton
Hi Christian, On Monday 18 December 2006 21:32, Christian Theune wrote: > Michael Kerrin wrote: > > Suppose I could merge some of the changes that from that branch to get > > rid of ssh_* and sftp code which should be independent of any twisted > > upgrade. Then a SSL cleanup is also independent of an upgrade, come to > > think about it. > > Did you have any chance to look into this? I am doing this now. Really sorry about the delay. > I also guess that the twisted upgrade could be documented on the road > map for Zope 3.4 so everybody knows that this is currently happening and > maybe someone wants to join you. Want to put a short page in there? Good point, I will do this now. Thanks, Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Removing SSL/SSH-Keys from Skeleton
Hi, Michael Kerrin wrote: > On Monday 18 December 2006 21:32, Christian Theune wrote: >> Michael Kerrin wrote: >>> Suppose I could merge some of the changes that from that branch to get >>> rid of ssh_* and sftp code which should be independent of any twisted >>> upgrade. Then a SSL cleanup is also independent of an upgrade, come to >>> think about it. >> Did you have any chance to look into this? > I am doing this now. Really sorry about the delay. Don't worry, I'm not trying to annoy people or make someone feel sorry. I know that sometimes those things sometimes just get lost somehow and just want to check that things stay on the radar in general. Don't feel sorry. I'm happy that you're contributing! >> I also guess that the twisted upgrade could be documented on the road >> map for Zope 3.4 so everybody knows that this is currently happening and >> maybe someone wants to join you. Want to put a short page in there? > Good point, I will do this now. BTW: I did a quick check on the SSL/SSH keys and didn't find any test cases break, just for you to know. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
On 12/19/06, Stephan Richter <[EMAIL PROTECTED]> wrote: On Tuesday 19 December 2006 06:16, Roger Ineichen wrote: > > Here is a list of candidates for removal (please verify!): I'm only commenting on the ones that I use, think have some use, or just have questions about. > > zope.fssync +1 0 It's too bad that this seems to have gone unfinished. The biggest pain (well, one of the big pains) we experience with Zope 3 is the lack of anything like Zope 2's export/import. Or, going further back, 'manage_exportHack'. :). This is a side topic and I'm not going to elaborate further except to beg for some low to medium level export/import capability. It seems that fssync was one of the alternatives, or could be, if I recall correctly. > > zope.modulealias +1, though I might think some people still use it. So we have to be careful. 0 Another side topic: even after cleaning out all deprecation warnings in our code to make it run under Zope 3.3, I still get deprecation messages bubbling up from the ZODB, claiming to come from ZODB's "broken.py". It dawned on me just yesterday that there are probably references to the deprecated/moved modules in our ZODB databases. I don't want Zope 3.5 to roll around and have our databases blow up because of permanent removal of the old 'zope.app' packages that have been moved to 'zope.*'. Is this a legitimate fear? Is there something we can do to repair these references? I don't know if zope.modulealias supports that or not. > > zope.app.file -1, I use it all the time in combination with zope.app.image to have quick file support. This is acceptable, if you do not plan to store thousands of large documents. BTW, I would welcome a conversion to use blobs. Also -1. We use zope.app.file quite a bit ourselves, for better or worse. I haven't seen any plausible alternatives. BTW: In my 3.3 release, I don't see 'zope.app.image', but I do see 'zope.app.file.image'. Is that what you meant? Or is there a 'zope.app.image' package that hasn't been included in the distribution? I believe that storing binary data in the ZODB - especially in content management situations - is of high interest to many. Doing it well, however, is the hard part. I think that the main Zope distribution should definitely provide helpful base classes and/or tools for storing and reading the data efficiently and easily. The current 'zope.app.file' code feels a bit scattered. Also important is good HTTP support for binary data. Additional Request / Response support for cache headers, 'If-Modified-Since', etc. - zope.app.sqlscript This package has for me the same importance as zope.app.dtmlpage and zope.app.zptpage. It contains some nice code that shows how to use RDB connections correctly, but I doubt that anyone is seriously using them. SQLObject and ZAlchemy are just better options. I would leave it in the repository, but remove it from the core tree. 0 We use this, but in a strange way. We don't use sqlscript's like these in the ZODB, but use them on some classes, ala:: from zope.app.sqlscript.sqlscript import SQLScript class ECards(...): sql_search = SQLScript( CONNECTION_NAME, """ SELECT * FROM ecard WHERE """, 'ecard_id' ) But I want to move this code to our SQLAlchemy based system anyways. So, sqlscript could go and I wouldn't shed many tears. - zope.app.undo Is anyone using this? I am certainly not. I think it can be removed. Phllip, you put a lot of work into it, what do you think? However, I think the code has a place in the repository, though there it runs in danger of quickly being outdated. -1 We depend on it. We don't use any of the UI pieces that are in it, but we do use the IUndoManager utility. I think that having fairly easy access to 'undo' is important: it's one of the distinguishing features of the ZODB. We use it to provide an "undo last" feature. "Deleted 'foo' (undo)" (with 'undo' being a link), like you get with GMail. Heck, this could be a good pitch point or article for Zope development. "Ever wanted to do an easy-undo feature like you see in GMail? With the ZODB, FileStorage, and the Undo Manager utility, it's easy!" Without a suitable replacement utility or set of tools for finding / undoing historical transactions, I'm against losing this. - zope.app.renderer You can safely remove it from the base tree. It was not such a big success as I was hoping for. Other approaches are easier. Note that wiki and bugtracker still use this code, so it should be still available for those packages. -1 We use this *quite* heavily, with Textile and Markdown renderers in place as well. Many of our CMS customers are using this (although I hope to move them to HTML w/ TinyMCE or Kupu if I can ever get Kupu to actually do something useful). Our Knowledge Base application also uses zope.app.renderer. It's been invaluable to be able to move documents from Wri
Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Jim Fulton wrote at 2006-12-19 17:27 -0500:
>Dieter Maurer wrote:
>> Jim Fulton wrote at 2006-12-19 11:54 -0500:
>>> ...
>>> I made a mistake several years ago when I decided to (have Amos)
>>> implement FTP over ZPublisher. The Zope publisher is a CGI-inspired
>>> HTTP-based and thus stateless API. It is a poor fit for FTP and I
>>> overgeneralized.
>>
>> Why do you think so?
>
>Because FTP is a stateful protocol and HTTP isn't.
Yes, but with a minimal state...
>> I implemented a ZServer based NNTP server over ZPublisher
>> within a few days -- and did not have the feeling that
>> I need to stress ZPublisher.
>
>I don't know anything about NNTP.
It is as stateful as FTP, having a minimal state, too.
> ...
>> Instead, I was pleased that I could use authentication, request logging,
>> request profiling, transaction handling, error handling -- all
>> features either in core ZPublisher or added by us.
>
>One could still use and benefit from many of the frameworks in Zope
>without using ZPublisher.
We moved from a ("papercut" based) dedicated NNTP server implemented
as a ZEO client (the type of solution, you currently seem to prefer)
over to a ZServer based NNTP server on top of ZPublisher.
And we were very pleased with the transition: both with respect
to maintenance as with respect to performance
Yes, we have to maintain a minimal state (for NNTP, this is,
user identity, selected group and selected article) outside
of ZPublisher and provide access to it via request and response.
This is managed within a few dozens lines of code.
--
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
On 12/20/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
Rocky Burt wrote:
> On Wed, 2006-20-12 at 12:52 +0100, Martijn Faassen wrote:
>> http://genshi.edgewall.org
>>
>> Inspired by Kid (in turn among others inspired by ZPT), the main
>> template language of TurboGears, written by the people who also created
>> Trac, and it seems to be getting traction. TurboGears among others is
>> going to adopt it, but also things like the creator of SQLAlchemy (and
>> Myghthy) spending time optimizing it, etc. It's close enough to ZPT to
>> be palatable to me, and has some nice features for reuse.
I both like and dislike ZPT and other such languages these days.
They're great when working on some design-heavy sites. But in other
situations, it's an awful lot of useless typing and structuring.
It matters to me especially when we're talking about reuse. Template
languages differ significantly in their approach. I also prefer to pick
something that has a certain momentum and a certain performance.
If TAL / Page Templates isn't really made available to anyone else,
how could it get momentum? 'zope.tal', 'zope.tales' and
'zope.pagetemplate' could probably be combined into a nice
world-usable egg. With the right extras and entry points, they could
be used with Buffet and then available to TurboGears, Pylons, web.py,
whatever.
Performance is also a strange game, as template languages differ
significantly in how (or even if) they compile, and how/where they
store that compiled manifestation.
Pylons uses Buffet, or at least a customized version of Buffet,
alongside 'Beaker'. 'Beaker' is a WSGI middleware thing that uses
Myghty's containers (which I guess basically make up the heart of
Myghty's supposedly powerful caching system) to cache templates,
fragments, all in a template-language-neutral way apparently. It would
be nice to be able to use things like that with Zope. Keep TAL, allow
for use of Buffet or something like it (perhaps something using the
same entry point) so that any other supported template language could
be plugged in.
http://projects.dowski.com/projects/buffet
http://pylonshq.com/project/pylonshq/browser/Pylons/trunk/pylons/templating.py
As a side topic, I'm also slowly coming to the conclusion that tales
path expressions are a waste of time and effort. We spent a lot of time
making sure that we can express something as a path expression, and a
Python expression would be just as easy to read and explain. We're not
stopping people from writing more complicated python expressions anyway,
and there are real cases where they're needed. A very different
templating mechanism where there is no Python at all and data is always
pregenerated before rendering is still attractive for other reasons, but
in the ZPT case I've become less and less convinced it's worth the hassle.
The nice thing then about something like Genshi is that instead of:
python:foo.bar
I can simply write:
foo.bar
Python expressions in TAL are cumbersome in part because they're simply
hard to type, not because they're necessarily *complicated*.
It's not TAL's fault - path expressions are just configured to be the
default for the engine used by Page Templates.
It should certainly possible to set Python Expressions as the default
for your ZPT Page Templates. I did a simple-stupid string template
language that basically looked for the following pattern::
{{ expr }}
and ran the TALES expression inside. For that setup, I set Python
expressions to be the default. This was used for generating emails,
etc. Kindof a slightly fancy mail merge::
Dear {{customer.name or 'customer'}},
But I could use string, path, whatever as well.
Doesn't Genshi allow for {{ expr }} type things in its templates? Or
was that Kid? Anyways, I hate having to type a whole bunch of TAL to
generate a fake tag and all of that to do a simple insertion in cases
where I could really do without that overhead::
Featured?
'view/featuredFlag' renders lots of fancy HTML on its own, so I don't
need a span or div or anything right there.
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
On 12/20/06, Jeff Shell <[EMAIL PROTECTED]> wrote: If TAL / Page Templates isn't really made available to anyone else, how could it get momentum? 'zope.tal', 'zope.tales' and 'zope.pagetemplate' could probably be combined into a nice world-usable egg. zope.pagetemplate is used in JOTWeb: http://jotweb.tummy.com/ I'm sure there are others using zope.pagetemplate & friends. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Chris Withers wrote at 2006-12-20 09:15 +: >Martijn Faassen wrote: >> >> It would be very nice if we could make that work! Zope as a drop-in >> Apache extension would certainly help wider adoption. > >Yes indeed :-) > >We're not a "normal" pythonish Apache thing though, 'cos we need to >rigidly limit the number of app server threads because of the zodb >object cache. Someone already worked on this and reported success. He integrated a ZEO client via "mod_python". -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Z3d] 721/ 8 Comment "Handling of empty prefixes in zope.formlib and zope.app.form"
Christian Theune skrev: Hi Jacob, Jacob Holm wrote: I don't have time to check it in now, but I will do it in a few days unless i hear otherwise. I have now checked it in on the trunk, and backported to the 3.3 and 3.2 branches. I didn't see any change on this, if there is anything I can do to help or support your, I'd be happy to do so. You can tell me if there is anything else I need to do. No worries if you're just short on time (we're all on Christmas preparations!), I just wanted to follow up and keep this on the radar. Thank you for reminding me. In the rush to get everything done before Christmas I almost forgot. -- Jacob Holm CTO Improva ApS ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Weird package in Zope 3 core: "optionstorage"
On Wednesday 20 December 2006 06:26, Gary Poster wrote: > FWIW, I glanced at this too. This is another part of the initial > checkin information to which Christian referred; seems like Gustavo > or Stephan might know about it. > > r28445 | niemeyer | 2004-11-12 13:49:40 -0500 (Fri, 12 Nov 2004) | 5 > lines > > Adding "optionstorage" product to src/, as requested by Stephan Richter. right, I asked Gustavo back then to check it in there, since we did not have a namespace policy. I am okay with moving it out of the core and into the z3c namespace. The functionality is still pretty cool, but it definitely needs documentation and tests; Gustavo did not know about this requirement. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Experimental implementation of Loading Configuration from the zope.app Egg
Hi Jim, I tried to implement your Loading Configuration from the zope.app Egg proposal [1] in one svn branch (baijum-zope-app-zcmlfiles) [2]. If you are not yet started it's implementation can you review this branch? [1] http://wiki.zope.org/zope3/LoadingConfigurationFromTheZopeAppEgg [2] svn://svn.zope.org/repos/main/Zope3/branches/baijum-zope-app-zcmlfiles Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Z3d] 721/ 8 Comment "Handling of empty prefixes in zope.formlib and zope.app.form"
Hi, Jacob Holm wrote: > I have now checked it in on the trunk, and backported to the 3.3 and 3.2 > branches. Yay! > You can tell me if there is anything else I need to do. From the perspective of the collector issue, this is all good. I'll close the issue. (Looks like you even were lucky and the patch applied cleanly to all three branches, cool!) > Thank you for reminding me. In the rush to get everything done before > Christmas I almost forgot. Thank you, for taking the time and getting it in! Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
On 2006-12-19 16:12:47 +0100, Martijn Faassen <[EMAIL PROTECTED]> said: I think only Michael Kerrin actively supports Twisted. I'm not sure what the status of that is. The last time I made time to pay attention to this, at the time we released Zope 3.2, the Twisted WSGI integration had a lot of problems. I tried to address the most urgent ones, but ended up with a server that was much slower than ZServer, which was much slower than the Zope 2 server. I was also alarmed that we were maintaining our own Twisted WSGI integration. I don't know if the Twisted community has gotten behind WSGI. If not, I'm not sure we gained anything from using Twisted. I'm having second thoughts about the Twisted integration for a number of reasons: * Twisted people actively dislike eggs. They won't eggify Twisted any time soon. *gaah* * Twisted async approach doesn't really match Zope's threaded approach. I'm not sure how the twisted integration works at all. But combining both worlds in a way seems good. Twisted's callLater would be very handy for instance. The zc.async package allows some support for asynchronous calls. All that would be gone w/o using twisted. and your reason: * Who is maintaining Twisted's WSGI integration? If that's us, then that sucks. That's true. Especially because the Zope people think differntly than Twisted people ;) -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
