[Zope3-dev] Re: Patch for testbrowser.py
On Fri, Apr 21, 2006 at 12:17:37AM +0200, Philipp von Weitershausen wrote:
Daniel Nouri wrote:
This patch adds 'Set-Cache' headers to the headers that are forwarded to
PublisherResponse. Before, these headers would be suppressed.
Index: testbrowser.py
===
--- testbrowser.py (revision 66810)
+++ testbrowser.py (working copy)
@@ -35,6 +35,7 @@
headers.sort()
headers.insert(0, ('Status', %s %s % (status, reason)))
headers = '\r\n'.join('%s: %s' % h for h in headers)
+headers += '\r\n' + '\r\n'.join(real_response._cookie_list())
content = real_response.body
return testing.PublisherResponse(content, headers, status, reason)
Brian,
since you added Five.testbrowser, perhaps you can say something about
this patch and, if you think it's sound, apply it to 1.4 and the trunk?
Thanks for kicking me on this, I've been meaning to reply a for a while.
I think the best principle for the testbrowser in Five would be to keep
it as close to the Zope3 one as possible. As we would probably want to
merge the two if Zope2 uses the Zope3 publisher.
To be honest I am not enough into the zen of publishers to know the
answer but I don't see any analogue in the Zope3 testbrowser. I'm CC'ing
Z3-dev to see if anyone there knows better.
--
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
[Zope3-dev] Re: RFC: The browser:page compromise
[EMAIL PROTECTED] schrieb: The name browser for a namespace sux IMHO ;) The idea of a namspace called browser is the following: We use the namespace browser for *presentations* (the earlier name for pages) which depends on the IBrowserRequest. This is also reflected in the package structure like: package browser For other request types like FTPRequest, XMLRPC or JSON etc we use: package ftp xmlrpc json Perhaps this is to technical and will confuse people which don't know the base concepts of request type interfaces. But since no tehchnical peple have no chance to develope with z3 I think this naming is OK. At some point it will be necessary to make the framework understandable for normal UI designers or we'll stick with ugly user interfaces forever :) How is a browser defined in Zope 3 and how are these names related to it? [...] All of this directive are based on the IBrowserRequest. Other requests like FTPRequest don't have a menu layer etc. How is a BrowserRequest different from a HTTPRequest? Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
[EMAIL PROTECTED] schrieb: Hi Tonico At some point it will be necessary to make the framework understandable for normal UI designers or we'll stick with ugly user interfaces forever :) I think it's pretty clear right now. Do you really think if soembody don't understand what a folder json or browser should contain he ever will be able to understand what he has to do in ZCML? (I guess this is really not a naming problem) I once tried to understand how the default skin works -- after that I gave up the idea of creating a new ZMI skin myself. (Especially the MacroMagic was difficult to understand, but I want to try again someday). I like Philipps proposal because it tries to remove some of that magic that makes it often difficult to understand (or to accept) the concept. Do yo have a simpler naming and/or module/package structure concept in mind? If so, is this not only a part of a project or application like a CMS etc? Do you think UI Developers should work out of the box with a Zope3 instance? Not at the moment. A browser request offers a API for collecting browser (client) releated informations like charset settings. This is done via the interface IUserPreferredCharsets. Interesting, does it also offer an API for preferred language and preferred media? A browser request also deals with form data and collects the given form input into a FieldStorage object. The most important part here is that a browser request knows how to handle file upload. Interesting. The browser request is based on the http request which does the base stuff like cookie handling etc. Thanks for explanation. Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3 common criteria security target ready
Hi everybody. It seemed like it would never really happen, but finally we are there: The Security Target document for the Zope 3 common criteria certification is finished. For everyone to enjoy reading it, see the attached PDF. I want to thank everybody who helped us over the last two years to make this actually happen. This is a huge step and I'm keen to see Zope 3.3 get certified. 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: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Reminder: Feature Freeze May 1
Don't forget that the feature freeze for the June release is May 1! That is only 10 days away! New features should be check in in a *stable* form by then. While we won't necessarily do a beta release then, anything checked in for the new release must be ready for a beta release when it is checked into the trunk. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Ok to change PAU session credentials plugin?
Am Donnerstag, 20. April 2006 19:17 schrieb Florian Lindner: Hello, I plan to change the PAU session credentials plugin to make it configurable in which form fields it looks for the credentials. My use case is that I want to use formlib to create a login form. formlib prepends form. at all IDs of the form fields. Therefore it is impossible to use these forms as login forms for that plugin (it's probably possible with some formlib subclassing but that introduces a lot effort). I don't see any negative aspects of this change. The values will default to the hard coded values that are used now, so now compatibility will be broken. Any objections? Since no one has objected I have made the change in revision 67211. Florian ___ 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: RFC: The browser:page compromise
Yes, but speaking as another Zope3 learner, consistency and simplicity (is orthogonality a word?) of the model/API is extremely important too. I am in favor of such simplifying changes, as long as they are properly documented and deprecation is properly applied. For example: a deprecation warning telling me what I should do instead is great. There should be a link in the CHANGES.txt file to the original proposal for each change. If there is no time to update it after discussions take place, then why not cut and paste an excerpt from the relevant email thread into the CHANGES file? Or at a minimum how about a URL link to the start of the dev-list discussion thread. my 2c, --Craeg Kamal Gill wrote: Stability is especially important for those of us learning Zope 3, as well as those who offer Zope 3 training. I realize Z3 is a fast-moving target, but making existing books and documentation obsolete doesn't help the adoption of such a fantastic collection of software, IMO. - Kamal Yes, I think it's very important to bring a little stability to the Zope3 framework rather then change every release such fundamental parts like directives. Regards Roger Ineichen -- Kamal Gill - [EMAIL PROTECTED] http://www.adaptivewave.com Content Management Made Simple direct: +1.916.679.4123 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/cstrong%40arielpartners.com ___ 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: RFC: The browser:page compromise
On Fri, Apr 21, 2006 at 01:03:58AM +0200, [EMAIL PROTECTED] wrote: Hi Philipp That confuses me even more. I *am* proposing changes to the browser:page directive... Hmm, never mind. I think I understand what you mean. You'd like to see new directives, instead of changing the old ones. Right? Yes, I think it's very important to bring a little stability to the Zope3 framework rather then change every release such fundamental parts like directives. FWIW, +1 on not changing the old directives. and +1 on introducing less magical directives and, eventually, deprecating and removing the old magical directives. -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! damm, I really need a new quote... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Patch for testbrowser.py
The relevant code in Zope2's ZPublisher.HTTPResponse.__str__: # ... we just built a headersl list using self.heders if self.cookies: headersl = headersl+self._cookie_list() headersl[len(headersl):] = [self.accumulated_headers, body] return '\n'.join(headersl) Maybe this can shed some light on whether we want to include that patch. Daniel ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: 64-bit BTrees
On 4/13/06, Fred Drake [EMAIL PROTECTED] wrote: I've created a feature development branch for this, and checked in my initial implementation. I've made another branch for this, with a different twist. I'm not sure it'll be interesting, but I think it'll solve my immediate need until I can get around to reasonable testing of the performance implications. The fdrake-optional-64bits branch will compile using the C int type for I keys and values by default, and using the PY_LONG_LONG type if ZODB_64BIT_INTS is defined. This allows 64-bit BTrees by building ZODB like this: python setup.py build_ext -D ZODB_64BIT_INTS build BTrees.IIBTree.using64bits will be True if ZODB_64BIT_INTS is used. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Don't let schooling interfere with your education. -- Mark Twain ___ 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: Patch for testbrowser.py
Brian Sutherland wrote: I think the best principle for the testbrowser in Five would be to keep it as close to the Zope3 one as possible. As we would probably want to merge the two if Zope2 uses the Zope3 publisher. Not being familiar with the Z2 publisher I have no idea what issue is being addressed by the quoted patch, but since the current sprint seems to have succeeded in using the Z3 publisher in Z2, the patch may be unnecessary. Either way, testbrowser (as well as all shared 2/3 code) should be kept as close together as possible, with a goal of being identical. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 common criteria security target ready
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune schrieb am 21.04.2006 14:39: Hi everybody. It seemed like it would never really happen, but finally we are there: The Security Target document for the Zope 3 common criteria certification is finished. For everyone to enjoy reading it, see the attached PDF. I didn't get an attached PDF file. Egon I want to thank everybody who helped us over the last two years to make this actually happen. This is a huge step and I'm keen to see Zope 3.3 get certified. Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/e.frerich%40nord-com.net - -- Egon Frerich, Freudenbergstr. 16, 28213 Bremen E-Mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: GnuPT 2.7.2 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESQWnuTzybIiyjvURAsROAJ4uvVjmQm23AXV/3c/wL8NYknaxOwCdFFZy X5eGSZcyzVj0DQV8lYzQkQY= =v4F7 -END PGP 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: [z3-five] Re: Patch for testbrowser.py
On Fri, Apr 21, 2006 at 04:07:43PM +0200, Daniel Nouri wrote:
The relevant code in Zope2's ZPublisher.HTTPResponse.__str__:
# ... we just built a headersl list using self.heders
if self.cookies:
headersl = headersl+self._cookie_list()
headersl[len(headersl):] = [self.accumulated_headers, body]
return '\n'.join(headersl)
Maybe this can shed some light on whether we want to include that patch.
As an aside:
What's with assigning to headersl[len(headersl):] instead of calling
headersl.extend(...)?
I've seen this idiom a couple of times and I always wonder
why, it's much less readable IMO.
I doubt it's supposed to be an optimization, since this code runs only
once per request; anyway, the two idioms are about equivalent in speed
AFAICT.
If it were in a performance-sensitive loop, a bit faster
and still quite readable would be:
headersl += [self.accumulated_headers, body]
timeit confirms this, here on python 2.4.2:
import timeit
slicer = timeit.Timer('x[len(x):] = [4,5,6]', 'x=[1,2,3]')
adder = timeit.Timer('x += [4,5,6]', 'x=[1,2,3]')
extender = timeit.Timer('x.extend([4,5,6])', 'x=[1,2,3]')
n = 100)
slicer.timeit(n)
2.6605889797210693
extender.timeit(n)
2.5256669521331787
adder.timeit(n)
1.9388060569763184
--
Paul Winkler
http://www.slinkp.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [z3-five] Re: Patch for testbrowser.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: On Fri, Apr 21, 2006 at 04:07:43PM +0200, Daniel Nouri wrote: The relevant code in Zope2's ZPublisher.HTTPResponse.__str__: # ... we just built a headersl list using self.heders if self.cookies: headersl = headersl+self._cookie_list() headersl[len(headersl):] = [self.accumulated_headers, body] return '\n'.join(headersl) Maybe this can shed some light on whether we want to include that patch. As an aside: What's with assigning to headersl[len(headersl):] instead of calling headersl.extend(...)? I've seen this idiom a couple of times and I always wonder why, it's much less readable IMO. I doubt it's supposed to be an optimization, since this code runs only once per request; anyway, the two idioms are about equivalent in speed AFAICT. If it were in a performance-sensitive loop, a bit faster and still quite readable would be: headersl += [self.accumulated_headers, body] timeit confirms this, here on python 2.4.2: I think this may be a fossil from a much earlier version of Python, in which 'list.extend' had undesirable performance (the new one is O(1)-amortized, I think). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFESVJ5+gerLs4ltQ4RAlseAKDVL5ABbRYGSzNtaLUVeu37WPTBCwCfW9pp c1gst1YN+xssxW2ZFhHWt88= =bcvP -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: RFC: The browser:page compromise
Hi Tonico I once tried to understand how the default skin works -- after that I gave up the idea of creating a new ZMI skin myself. (Especially the MacroMagic was difficult to understand, but I want to try again someday). I see, I personaly like macros, but it is true, sometimes it is very hard to fit the pices to a big picture. Perhaps it whould help if we have another directive ;-) called browser:macro .. / which whould handle the macro registration rather then use browser:page ... /. This whould let us use some concept of a explicit *philiKON* factory for macro registrations which makes the standard_macros mapping a little more transparent. What I really dislike on the browser:page registration for macros, is, that such macros are also callable as traversable views rigth now. I whould like to see a different lookup for macros in the future. This could look like: Macro lookup right now: html metal:use-macro=context/@@standard_macros/page what I like to see is something like: html metal:use-macro=macro:StandardMacros/page Such a macro could be lookuped by a ITALESExpression called *macro* similar to the IContentProvider implementation. The *StandardMacros* could be a mapping registred as a python factory. The *StandardMacros/page* knows how to lookup a registred macro called *page* in the *StandardMacros*. See also my (a little old) proposal at: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SimplifyMac roRegistration Note: the proposal is a little bit old and I whould change the directive browser:macros and make explicit use of a python factory rather then use a implicit mixin class. What do you think Philipp? I like Philipps proposal because it tries to remove some of that magic that makes it often difficult to understand (or to accept) the concept. Do yo have a simpler naming and/or module/package structure concept in mind? If so, is this not only a part of a project or application like a CMS etc? Do you think UI Developers should work out of the box with a Zope3 instance? Not at the moment. A browser request offers a API for collecting browser (client) releated informations like charset settings. This is done via the interface IUserPreferredCharsets. Interesting, does it also offer an API for preferred language and preferred media? There is a adapter providing the interface IUserPreferredLanguages which can be used on requests. This adapter reads the request value *HTTP_ACCEPT_LANGUAGE* in the method *getPreferredLanguages*. The adapter is registred for the IHTTPRequest. A browser request also deals with form data and collects the given form input into a FieldStorage object. The most important part here is that a browser request knows how to handle file upload. Interesting. The browser request is based on the http request which does the base stuff like cookie handling etc. Thanks for explanation. no problem Regards Roger Ineichen Tonico ___ 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
