[Zope-dev] DateTime iso8601 bad handling of dates
This has been brought up and (rather cavalierly) dismissed before. I
challenge anyone to justify the following DateTime behavior:
DateTime('2005-01-01').strftime('%Y-%m-%d')
'2004-12-31'
DateTimes are actually timestamps, and the current implementation
assumes that a date in ISO8601 format without a timezone specifier is
UTC rather than local.
It was asserted, last time this came up, that this is compliant with the
ISO8601 spec, but my own research shows this to be false. If someone
can point me to a truly authoritative source that supports the current
behavior, I would appreciate it, but that would not change the fact that
the manifested behavior is *broken*.
This is a simple two-line fix, folks. I've already done it on my
production systems.
Cheers,
Evan @ 4-am
___
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: ZPT: defer expression fix
Christian Heimes wrote: That's an interessting use case. Do you want me to keep the code and make up a new expression? I'm thinking about lazy:. If you have a particular use for defer: that would justify the split, please go ahead. I have no particular interest in keeping it. Cheers, Evan @ 4-am ___ 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: ZPT: defer expression fix
Christian Heimes wrote: * DeferWrapper didn't cache the result of the expression like ordinary vars do. This was intended, though you couldn't know that since I never documented this. Consider the following terrible example: div tal:define=xis defer:string:x is $x p tal:repeat=x python:range(3) tal:content=xis/p /div This should evaluate to: div px is 0/p px is 1/p px is 2/p /div Why?? I don't remember why I wanted this behavior; it was an experiment, and I can't find any code of mine that uses it. Cheers, Evan @ 4-am ___ 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] ZopeGuards iterator problems
I just created issue #1656 and checked in a fix, so looping over enumerate(xrange(9)) is now possible, among other things. Should we add entries for the various iterator types to the security machinery so that iterators returned by the itertools module can be used without lots of tedious wrapping? Cheers, Evan @ 4-am ___ 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: Conditional imports in ZTUtils/__init__.py
Stefan H. Holek wrote:
ZTUtils/__init__.py contains code like this:
if sys.modules.has_key('Zope'):
# import things
This is causing me repeated headaches when writing tests, because it
assumes/dictates a certain module import order. Can this go away,
please? I mean we know we are running Zope, don't we?
This is part of my attempt to allow the various bits of ZPT to work
outside of Zope. It assumes that the presence of the 'Zope' module is a
reliable test. Perhaps this is a YAGNI, or perhaps there's a better way
of accomodating non-Zope users.
Cheers,
Evan @ 4-am
___
Zope-Dev maillist - [EMAIL PROTECTED]
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: [ZPT] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: Given that, I still prefer context#dc to context/##dc. +1 I like the idea that '/' and '#' are both path separators, and that the semantics of each path segment depend on the preceding separator. Cheers, Evan ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: IMO, if we take this route, we should think of the notation as providing an alternate traversal operator. That is, there is syntax that either modifies or replaces /, so of the examples above, only: context/*dc/title In that case, I'd be happy to consider adaptation as orthogonal to my path prefixes. Might as well drop the slash and go with the previous suggestion: context*dc/title I can easily read the star as an adaptation operator, even with multiple applications. Cheers, Evan ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: One disadvantage I see with the cast notation is that it's a bit jarring in: a/b/(adapter)c/d as the adapter is applied to a/b/c. The order just doesn't seem quite right. Unless I'm misunderstanding something fundamental here, in the TALES context an adapter is essentially a function accepting a single argument. The adapted object that results from applying the adapter function is either used directly or further traversed. All of the other qualities that make up an Adapter (how it's registered, that it supports ITALESAdapter, etc.) are irrelevant to its use in a TALES expression. Given all that, why do we need to shoehorn the adapter's name into the same path segment as one of the traversal names? The above looks much more natural to me as one of: a/b/c/(adapter)/d a/b/c/*adapter/d a/b/c/adapter()/d a/b/c/adapter:/d Note that the latter two forms allow for additional arguments. While not applicable to single-argument adapters, this is certainly a useful feature if we don't restrict the syntax to adapters only. In particular, evan-pathprefix-branch uses the colon syntax to allow applications such as a/b/c/index:2/d and a/b/c/call:x,y/d. This same scheme can easily subsume adapters in either or both of two ways: adapter as prefix, and adapter name as argument to a prefix. tal:define=prefix foobar adapter:foo.bar tal:content=a/b/c/foobar:/d ...or... tal:define=prefix A builtin:adapters tal:content=a/b/c/A:foo.bar/d Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: I thought you had proposed this, but I couldn't find a proposal or documentation. You say this is implemented in Zope 2? Where is it documented? Actually, it's only implemented on evan-pathprefix-branch. It has been quite a while since I had a chance to work on it, so I had forgotten that it was never merged, or properly documented for that matter. Pretty much all the information about it that isn't in the source code is in the ZPT list archives from August and September (e.g. http://mail.zope.org/pipermail/zpt/2003-August/004902.html) So, no worries if you decide to take a completely different direction -- it was never released. Cheers, Evan ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: I don't inderstand what motivated the special expression types for this namespace. For example, to get at file-system based code, couldn't you have used the modules variable? I started there, but went with the special expression types because the set of things that are valid to define as prefixes is completely disjoint from those that you would use in other TAL statements. I've grown wary of tying abstract object names to Python package and module structure. Also, while I find it difficult to describe precisely, I have a strong intuition that arbitrary objects should not be available for use as prefixes. Of course, the idea of prefixes as Zope 3 adapters intead of custom-made prefix implementations may change things. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces
Jim Fulton wrote: I've posted two proposals: http://dev.zope.org/Zope3/TALESPathExpressionAdapters Proposes a mechanism for easily using adapters in TALES expressions. I'm not at all clear on how the proposed mechanism is superior to the implementation of path segment prefixes that exists in Zope 2. This differs from the namespace proposal that you cite, in that the object named on the left of the colon is not a namespace or adapter. It is simply a registered name that is associated with code that interprets the text to the right of the colon. This allows constuctions such as a/sequence/index:2 (a.sequence[2]), a/bag/var:x/call: (a.bag[x]()), and an/object/adapt:foo.bar (foo.bar(an.object)). http://dev.zope.org/Zope3/ZPTVariableNamespaces proposes a mechanism for qualifying names defined in TAL and used in TALES expressions. This would of course conflict with prefixes as currently defined, and seems weakly motivated. I can imagine getting a similar effect with a more consistent syntax by allowing tal:define=x/y foo when x supports an ITALESNamespace interface. The path x/y/z then does exactly what the user would expect. A namespace x can be created without any new TAL syntax by providing a built-in constructor, as in tal:define=x namespace, that creates an empty dictionary-like object with support with ITALESNamespace. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] test.py
Jeremy Hylton wrote: Make sure App.Product is imported first, so that test.py can work. This change does not affect the old utilities/testrunner.py. This checkin message caused me to notice 'test.py' for the first time. Can you point me to any discussion/docs on it? When did/will it replace testrunner? Shouldn't the python2.2 in the #! line be python2.3? Sorry for the flood of questions, but this and the recent doctest-style tests being checked in have made me wonder if I've been missing a significant shift in testing tech. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope 2.8
Christian Theune wrote: - Does a proposal for the post-traverse-hook have a chance for 2.8? (The code is here completely working on 2.7, I only need to write tests.) Please, write tests and merge to the HEAD. I see no reason why this shouldn't go into 2.8. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] TypeErrors during 'make test'
I'm getting several TypeErrors when I run 'make test' on the HEAD. Each of them involves a call to cAccessControl's 'validate' with 'roles' set to a PermissionRole instance, complaining that it's not iterable. Any ideas? Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope 2.7.0 rc2 + python 2.3.3 problem
Tim Peters wrote: The globals set up for running the script appear not to contain a '__file__' key, and have a '__name__' key explicitly set to None. If it set either of these to something useful, or didn't have a '__name__' key explicitly set to None, warning.warn() would have been able to make up *something* for warn_explicit's filename and/or module arguments. Argh. Scripts need a __name__ defined, or various activities choke. It can't be the Id of the Script, since that can contain '.', which screws up imports in the Script. It can't be None, since that will cause this problem. Are there hidden gotchas lurking around giving all Scripts the __name__ Script (Python)? Other suggestions? Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope 2.7.0 rc2 + python 2.3.3 problem
Tim Peters wrote:
it *looks* like you could leave name None, but set '__file__' to something
(non-None) explicitly.
Thanks! This seems to do the trick, and I have a unit test that fails
before and passes after the change.
While creating the test, though, I ran across some disturbing behavior.
In interactive mode (and when running unit tests) something is getting
confused:
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type help, copyright, credits or license for more information.
range(1.0)
__main__:1: DeprecationWarning: integer argument expected, got float
[0]
So far, so good. However:
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type help, copyright, credits or license for more information.
__name__=None
range(1.0)
[]
1+1
Traceback (most recent call last):
File /usr/lib/python2.3/warnings.py, line 57, in warn
warn_explicit(message, category, filename, lineno, module, registry)
File /usr/lib/python2.3/warnings.py, line 63, in warn_explicit
if module[-3:].lower() == .py:
TypeError: unsubscriptable object
...and...
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type help, copyright, credits or license for more information.
import warnings
warnings.simplefilter(error, category=DeprecationWarning)
range(1.0)
[]
1+1
Traceback (most recent call last):
File /usr/lib/python2.3/warnings.py, line 57, in warn
warn_explicit(message, category, filename, lineno, module, registry)
File /usr/lib/python2.3/warnings.py, line 92, in warn_explicit
raise message
DeprecationWarning: integer argument expected, got float
...and...
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type help, copyright, credits or license for more information.
import pdb
__name__ = None
pdb.run('range(1.0)')
string(1)?()
(Pdb) s
--Call--
/usr/lib/python2.3/warnings.py(24)warn()
- def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: tp_compare didn't return
-1 or -2 for exception
i = max(0, len(stack) - 1)
[traceback snipped]
Looks like something isn't properly propagating exceptions.
Cheers,
Evan @ 4-am
___
Zope-Dev maillist - [EMAIL PROTECTED]
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: RFC: backward compatibility of PythonScript bindings for 2.6.4 / 2.7.0
Jeremy Hylton wrote: What if you used a special object that would produce a useful error message if the user tries to access the container. I like this. Make it a singleton, and put it in the global namespace for Scripts, so that we can write: if context is Inaccessible: # Do without access to context Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: RestrictedPython globalization change
Tres Seaver wrote: I was just looking with Shane at the code you added in November to address http://collector.zope.org/Zope/445 . It seems to me that this bit of majyk is just confusing, and makes PythonScripts even less like normal Python functions; the actual submitter could easily fix his script by adding 'global context' at the top. I completely disagree. Part of what already makes Scripts different than normal functions is that they don't have an associated module and globals. Bound variables are simply pre-initialized -- their current globalness is an implementation detail that could change. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: On with the show....
Sidnei da Silva wrote:
If you look at FSPageTemplate, its obvious that it doesn't subclass
ZopePageTemplate, but the solution is not so obvious. Using:
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd
have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your
code works out to the same thing. I don't endorse this sort of
cross-tree method copying, but if we're going to do it on this scale, at
least we can make it tidier. Before the Globals.InitializeClass:
zpd = ZopePageTemplate.__dict__
for m in ('func_code', '_default_bindings', 'manage_FTPget',
'get_size', 'PrincipiaSearchSource', 'document_src',
'pt_getContext', 'ZScriptHTML_tryParams'):
setattr(FSPageTemplate, m, zpd[m])
A similar error also happened with FSImage.__str__ (which is assigned
Image.__str__, but FSImage just subclasses FSObject).
Any thought on those?
Yep -- it seems very silly to copy a one-line method like that.
Cheers,
Evan @ 4-am
___
Zope-Dev maillist - [EMAIL PROTECTED]
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: Post-mortem [Was: Zope 2.7.0 b3 regressions]
Brian Lloyd wrote: Good call. I think it would be best to make sure the docstring of the new method is clear on its reason for being. I think somewhere there is an interface file that is used to generate some of the api docs - ideally that can get updated too. Done and done! Cheerios, Evan ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Post-mortem [Was: Zope 2.7.0 b3 regressions]
Summary: absolute_url(1) didn't include the path to the virtual root, which broke code that assumed that it could just prepend / in all cases. I changed it to include the base path, and broke code that prepends BASEPATH1. Since the old behavior existed for two years (including part of the 2.7 beta), is arguably easier to work with, and works with existing CMF code, I will revert to it. This will leave /-prepending code broken. In line with Stefan's original suggestion, I will add a new method with alternate behavior. It's not hard to grep for broken code and use the new method to make it correct -- Product authors should do so. def absolute_url_path(self): '''Return the entire path of the absolute URL for this object. This includes the leading slash, and can be used as an absolute-path reference as defined in RFC 2396. ''' Lennart proposed additional methods, but I'm going to work on that in the post-2.7 branches, since I really want to clean up this mess properly, and beta 3 isn't the time. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope 2.7.0 b3 regressions
Yuppie wrote: Yes. getIcon() is the cause of the problem I see: To access the ZMI I use this Apache rule: ProxyPass /zope27 http://localhost:8080/VirtualHostBase/http/example.org:80/VirtualHostRoot/_vh_zope27 getIcon() for a folder in myCMFSite returns 'zope27/myCMFSite/folder_icon.gif' (was 'myCMFSite/folder_icon.gif' in Zope 2.6) OFS/dtml/main.dtml adds BASEPATH1, so the URL is '/zope27/zope27/myCMFSite/folder_icon.gif' (would be '/zope27/myCMFSite/folder_icon.gif' in Zope 2.6) Based on this, and on a lot of back-burner pondering, I'm now thinking that the proper fix for this is the one you suggest. It makes sense for the relative version of the absolute path to omit BASE1, the URL of the virtual root, returning the semantics of absolute_path(1) to path relative to the virtual root. Use cases that need a hostname-relative URL can use BASEPATH1 + absolute_url(1). Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope 2.7.0 b3 regressions
Lennart Regebro wrote: I will check this into head this evening, and unless people scream tomorrow I will check it into the 2.7 branch. Please hold off. I've been meaning to revisit this for a while, and I have a bit of time to do so today and tomorrow. Also, virtual hosting is properly the domain of the request object, not the object being traversed. This is why the modified absolute_url() uses REQUEST.physicalPathToURL. Yuppie wrote: 'relative to site object' is quoted from the API documentation of absolute_url() The API documentation is incorrect, and the docstring in the method is correct: '''Return a canonical URL for this object based on its physical containment path, possibly modified by virtual hosting. If the optional 'relative' argument is true, only return the path portion of the URL.''' Relative in this context refers to the concept of a relative path as used in rfc1808, not to a relationship with a Zope object. It is meant for use in situations such as redirection to a secure page from an insecure one (eg. 'https://example.com' + target.absolute_url(1)) where you would otherwise have to generate the complete URL and then break it apart. Current behavior looks like this: http://localhost:8080/temp_folder/test absolute_url( ): http://localhost:8180/temp_folder/test absolute_url(1): temp_folder/test http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/test absolute_url( ): http://www.example.com/temp_folder/test absolute_url(1): temp_folder/test http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/test absolute_url( ): http://www.example.com/test absolute_url(1): test http://localhost:8080/VirtualHostBase/http/www.example.com:80/temp_folder/VirtualHostRoot/_vh_foo/test absolute_url( ): http://www.example.com/foo/test absolute_url(1): foo/test This is entirely consistent, predictable, and easy to explain. The problem you are encountering is almost certainly due to a use of absolute_url where it shouldn't be used, or is used incorrectly. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Zope 2.7.0 b3 regressions
Yuppie wrote: You introduced that concept in Zope 2.7. The method docstring is part of your change. Before Zope 2.7, absolute_url was defined different, worked different and was used different in products maintained by ZC. [snip] I don't think the old API was better. I'm just saying that you changed the API in a way that is not backwards compatible. I encountered the problem with a plain new CMF Site. Gotcha. Grepping Zope's source and the Products I had to hand showed only one use of absolute_url(1), in Draft.py, so I hoped that making the implementation sane wouldn't affect too much. Looking at the 1.4 branch of CMF, I see it in three places: 1. DiscussionTool.py uses it when looking up replies. This looks like a non-issue for new or properly converted discussions in 1.4. 2. SkinsTool.py uses it to construct skin cookies. 3. Any caller of URLTool that passes 'relative=1' to it. I can only find one of these, namely getIcon() in DynamicType.py. Is #3 likely to be the cause of the problem you're seeing? Can you be more specific about the circumstances of the problem? Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: 2.7.0-b2 - Critical ZPT TAL bug when using content-type text/xml
Richard Waid wrote: Basically, if you're using a ZPT with a content-type text/xml, using a TAL path expression to access an attribute or method causes a security violation (Unauthorized). It does not happen if the ZPT is using content-type text/html. Ah, guarded_getattr is doing something wrong with Unicode attribute names, though I'm not sure exactly what. http://collector.zope.org/Zope/1034/ Thanks for the pointer -- I've updated the bug. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: 2.7.0-b2 - Critical ZPT TAL bug when using content-type text/xml
Until cAccessControl.c is fixed, you can work around the problem with a simple patch to Products/PageTemplates/Expressions.py, in restrictedTraverse(): if isinstance(name, TupleType): object = object(*name) continue + + name = str(name) if not name or name[0] == '_': # Skip directly to item access Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] PythonLibraries Product
Tres Seaver wrote: Hmm, I'm thinking about this for the CMF. In CMF 1.3.x, a template which has a cache manager, or a title, puts those values in a simple 'name=value'-formatted file, with extension '.properties'. Permission mappings go in a separate file, with extension '.security'. I wish I had been more involved when these decisions were being made -- I dislike this scheme, because it is irregular and requires you to know what sort of object you're dealing with just to be able to tell which files go together. If it's always file + ','-dir, external tools can move, rename, delete, etc safely. Then there's the potential for name clashes. It's unlikely, but not *terribly* so, that a user would create a second object named 'foo_edit_form.pt.py'. Using quote_plus avoids filesystem character set issues, and makes the simple ',' postfix clash-proof. Oh, well. Cheers, Evan ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style classes and Persistence?
What's the latest word on mixing new-style classes and Persistence? I'm finding type subclassing to be extremely useful in PythonLibraries, but so far I'm only using them for non-persistent objects. For part of what I'm doing, though, it would be nice to be able to chuck the old PersistentList and PersistentMap, and replace them with actual list and map subclasses. As far as I know, trying to mix them *directly* is a no-no, but is there any problem with making a new-style class instance an attribute of a Persistent ExtensionClass? Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] PythonLibraries Product
I'm thinking seriously about writing a Product to provide collections of
Python functions defined by a single source text -- PythonLibraries.
This would *not* be the same as Zope 3's persistent modules, although it
would provide some of the same benefits.
Here's the README.txt:
Python Libraries
The Python Libraries Product provides support for collections of
restricted Python code. A Python Library is similar to a Folder
full of Python-based Scripts, except that the functions in the
Library are more like ordinary Python functions than Scripts, and
a single persistent global variable namespace is shared among the
functions in the Library.
A Library obeys the same security restrictions, and has access to
the same set of modules, as a Script. Libraries are *not* very
much like Python modules or packages, except in that they both are
convenient places to keep groups of functions. You cannot import
a Library, define Python classes in one, or use the 'print' statement
outside of function definitions.
When changes to a Library are saved, its source code is executed.
This process, known as Library initialization, also occurs
whenever the Library is loaded into memory from the ZODB. Global
variables defined during initialization are divided into three
groups, depending on the kind of value to which they refer:
functions, simple data, and modules. There is one additional
global variable, named 'Library', that is defined both during
initialization and function evaluation, and which cannot be deleted
or rebound. It refers to the Library object itself.
Functions are made available to other Zope code as Library attributes.
A function 'do_it' contained in the Library located at '/foo/myLib'
may be called by a TALES expression such as here/foo/myLib/do_it
or the Python expression context.foo.myLib.do_it(). Function
names that conflict with methods of the Library object are syntax
errors. A Library's functions are not published by default, which
means that they cannot be accessed by URL through ZPublisher. There
is a Library method 'pl_publish()' that can be used to explicitly
publish a function.
Simple data includes Python built-in types such as numbers,
strings, lists, and dictionaries. Variables with simple data are
persistent, and their value is retained even when the Library is
changed or reloaded, although the execution of the code can remove
or overwrite them. These variables are not visible to other Zope
objects.
Modules are imported Python modules. These are not visible to
other Zope objects, and do not persist -- they are re-imported
each time the Library is changed or loaded.
Unlike Scripts, Libraries do not have a Bindings tab. In order to
access context objects, such as the Library's container, the root
Zope object, or the authenticated user, functions must use a global
variable created by a call to the 'pl_bind()' method of the Library.
This method takes two arguments: a variable name, and a TALES
expression. The TALES expression will be evaluated the first time
that the variable is used in each call to a Library function, and
the value will be cached for subsequent uses within the same call.
For example, examine the following snippet of Library code:
Library.pl_bind('user', 'user')
Library.pl_bind('thingy', 'here/thingy | nothing')
def f():
if user.has_role('Authenticated') and thingy is not None:
print user, thingy
return printed
When the function 'f' is called, the 'user' and 'thingy' variables
will be evaluated in its first line, and the values will be reused
in the second line, if the condition is true. If 'f' is called
again, in the same request or not, the bound variables will be
re-evaluated. Bound variables are not available during Library
initialization, since they are unlikely to evaluate meaningfully
when a Library is loaded from the ZODB.
___
Zope-Dev maillist - [EMAIL PROTECTED]
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: TALES idea: tuple unpacking
Chris Withers wrote: How would this interact with the Adapters stuff implements in Zope 3's TALES? It wouldn't -- this is a Zope 2 implementation. OK, I know what you mean, but I don't know enough about the Zope 3 implementation to make an informed response. Wouldn't Zope 2's lack of the whole component framework make this really hard? Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: TALES idea: tuple unpacking
Jim Penny wrote: Well, that is exactly why it will be more confusing to everyone. A python programmer is not expecting them to be different, and a non-programmer has no idea of what keys and indices are, much less how they differ. The explanation isn't that hard, at least for a user with a basic knowledge of data structures -- you usually use key: with a dictionary, and item: with a sequence. The exception is when you have an integer key in a dictionary. Eeep, gad no. The python is horrible. The prefix syntax is equally horrible, unfamiliar, and ambiguous! For example, why does call: not have an argument Because I'm not passing an argument to the SQL statement. In my implementation, the syntax is call:arg1,arg2,..., where each argument is required to be a variable name. Every prefixed path element operates upon the current traversal object, using the argument (if any) to the prefix. Here's a list that demonstrates: x/key:foo -- x['foo'] x/item:0 -- x[0] x/attr:foo -- x.foo x/call:foo -- x(foo) x/var:foo -- getattr(x, foo) or x[foo] (path traversal semantics) x/fmt:%.2f -- '%.2f' % x x/fmt:thousands_commas -- thousands_commas(x) Yes, alternative is very nice. Yes, it can be done with python:path(), or by refactoring the expression to an script. Yes, the alternatives are harder to read, or more work. Nu? I can't think of a way to implement my first example using python:path(), though you could certainly do it with a Script. The second example can be awkwardly rewritten by defining exists:data/stat and using it in a short-circuiting boolean expression such as have_stat and thousands_commas(data.stat) or 'No data.'. My point is that these prefixes allow a degree of precision, when necessary, that is not possible in current TALES without totally transforming the expression. Doesn't it strike you as odd that sometimes the prefix denotes parameterization, and sometimes it denotes application? I hope that the list above makes the consistency clearer. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: simpler TALES. (was Re: TALES idea: tuple unpacking)
Paul Winkler wrote: you don't :) it's a convenience (less stuff to type if you access the object a lot) and/or an optimization (getSomeObject might be expensive). I believe that his example referred to the case where the intermediate object must be called before path traversal can continue. Since the result of a path expression is called, if possible, the two-step define gets the job done. With prefixes, the simpler here/getSomeObject/call:/someAttribute gets the job done. * Why does tal:content=request/form/items don't get me the items object that I'm expecting you lost me there. request/form is a mapping, and traversal tries attribute access first, so you get request.form.items() rather than request.form['items']. Hm. Doesn't really matter - ObjectManager makes them equivalent anyway (except that some keys cannot be spelled as attributes, e.g. foo['bar.html']). Not quite. Attribute access invokes acquisition, while item access never does, so getattr(foo, 'bar.html') may succeed where foo['bar.html'] fails. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: simpler TALES. (was Re: TALES idea: tuple unpacking)
Shane Hathaway wrote: FWIW, I'd write this as here/call:getSomeObject/someAttribute. I suppose it's possible to support both. One interesting difference is that my syntax says both get an attribute and call it, while yours says only call it. Mine is a method call, while yours is a function call. Mine also allows simple argument lists, and supports stuff like here/key:getSomeObject/call:/someAttribute. On the other hand, it has already confounded someone's intuition :-) Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: TALES idea: tuple unpacking
OK, I've checked in a sample implementation on evan-pathprefix-branch.
It allows for registering prefixes with:
from Products.PageTemplates.PathPrefixes import registerSubPathPrefix
registerSubPathPrefix('call', call_compiler, call_handler)
It includes an implementation of 'var:', 'call:', 'key:', 'item:',
'attr:', and 'fmt:' with which the snippet:
div tal:define=foo string:*foo*;
seq python:('arg', 3.4);
map python:{'*foo*': 'yes', 'keys': 'skeleton'}
div tal:content=seq/item:0/div
div tal:content=seq/item:1/fmt:%.2f/div
div tal:content=template/attr:title/div
div tal:content=here/key:test3/title/div
div tal:content=structure foo/fmt:structured_text/div
div tal:content=map/key:keys/div
div tal:content=map/var:foo/div
/div
...produces:
div
divarg/div
div3.40/div
divMy Title/div
divMy Title/div
divpemfoo/em/p
/div
divskeleton/div
divyes/div
/div
You can try it out with the following commands in your
$ZOPE/lib/python/Products/PageTemplates/ directory:
cvs -q up -r evan-pathprefix-branch PathPrefixes.py
cvs diff -r evan-pathprefix-branch-0 -r evan-pathprefix-branch \
-u Expressions.py | patch
Cheers,
Evan @ 4-am
___
Zope-Dev maillist - [EMAIL PROTECTED]
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: TALES idea: tuple unpacking
Jim Penny wrote: But, what does all of this have to do with index:, key:, int:, etc.? index: and key: are particularly interesting, in that they use different syntax for something that python conflates syntactically. That is, an integer indexed reference looks exactly like a string indexed reference, both have form structure[key]. I proposed distinct key: and item: in order to kill some implicit magic before it was born: x/key:0 is the same as python:x['0'], while x/item:0 is the same as python:x[0]. It seems clear to me that subpath prefixes are going to be part of Zope 3, no matter how opinion on this thread goes. It wasn't hard to implement them for Zope 2, and I find them useful. While I agree that someone who can deal well with x/item:0 will have no problem with python:x[0], I also assert that many such people would join me in prefering options/lib/data/my.sql/call:/item:0/state to options['lib'].data['my.sql']()[0].state if only because the former allows me to specify access methods *only* for the exceptions to the norm, not for every path step. If that isn't valuable, what about path expressions is? I also offer for general consideration the following: options/foo/item:0 | request/foo/item:0 | default data/stat/fmt:thousands_commas | string:No data. Python expression equivalents, please? Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: TALES idea: tuple unpacking
Jim Penny wrote: Hate this. Looks like a typecast of some kind, int is way to overused for this. If you must, why not index: ? Hmmm. I hadn't thought of that before, but I've certainly wanted to tell the path traverser whether to use attribute, index, or key access on several occasions (using 'items' as a dictionary key bites me regularly). This suggests the following prefixes: 'key:' -- use item access with the prefixed string. 'index:' -- use item access with the prefixed integer. 'attr:' -- use attribute access with the prefixed string. In each case, the path traversal fails if the specified access method fails, rather than trying other access methods. This would allow options/a_mapping/key:items/index:0 rather than python:options['a_mapping']['items'][0]. There's an alternative, longer syntax that would be more consistent with the adapter concept from Zope 3. Given that prefixes are meant to be namespaces, 'key', 'index', and 'attr' should be elements of a namespace (perhaps 'by' or 'as' to keep it reasonably short) rather than prefixes themselves. In this case, we would have the path expression options/a_mapping/by:key/items/by:index/0. Note that this form has the advantage of allowing a_list/by:index/?i. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: weak examples, weak exploits
Shane Hathaway wrote: This seems like a fine idea, but what action would the user take to install examples and extras? In my initial implementation, there was a separate page that listed the names and descriptions of the various examples, with links to install them. If I recall correctly, this page was reached from a link on Folder views, much like the current Help link. Also linking from the Quick Start sounds like a fine idea. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: weak examples, weak exploits
Casey Duncan wrote: I would be in favor of making the Examples opt-in like the Zope tutorial. It seems silly to have it in evey ZODB by default. Make people add it if they want it. Many, many moons ago I created evan-examples-branch, which allows individual Products to offer sample code without (magically or otherwise) forcing them upon the user. I'd love to see it revived, perhaps as Examples/Optional Extras in order to cover the Hurt system as well. The basic idea is to look for an XML manifest file 'examples/index.xml' in each Product. It probably wouldn't be very hard to use ZConfig instead of XML. Here is the PageTemplates index.xml: example name=Assorted Examples description This is a set of examples of the use of page templates. It includes examples of batching, macros, and trees. /description payload import file=zpt_examples.zexp/ /payload view url=zpt_examples/ /example !-- This file can contain any number of examples. Each one consists of an example with a 'name' attribute, containing exactly one description. The name and description are displayed in the Examples page. description can have a 'format' attribute set to 'plain' (the default), 'stx' (structured text), or 'html'. An example can contain payload elements. Each payload can contain any number of import, execute, and call elements. These are processed in order when an example is selected from the Examples page. import must have a 'file' attribute that names a file in the 'examples' directory to be imported. execute must have a 'file' attribute that names a file to be run with execfile. call must have a 'path' attribute that gives the path to a Zope object to be called. An example can contain at most one view element. The 'url' attribute of a view is the URL to view after all payload elements have been processed. This URL can be relative to the current folder. -- Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Post-authentication hook
Dieter Maurer wrote:
We had discussed the post-authentication hook in connection
with role based skin selection but we never had it implemented.
I have, and it even fits here in the margin. Shall I pop it into the
Collector?
242a243
self._post_traverse = post_traverse = []
363a365
del self._post_traverse
434a437,439
if post_traverse:
exec_callables(post_traverse)
444a450,453
def post_traverse(self, f, args):
Set a callable object and argument tuple
to be combined if traversal succeeds
self._post_traverse.append((f, tuple(args)))
445a455,470
def exec_callables(callables):
for (f, args) in callables:
try:
f(*args)
except (ArithmeticError, AttributeError, FloatingPointError,
IOError, ImportError, IndexError, KeyError,
OSError, OverflowError, TypeError, ValueError,
ZeroDivisionError):
# Only catch exceptions likely to be logic errors.
# We shouldn't catch Redirects, Unauthorizeds, etc. since
# the programmer may want to raise them deliberately.
from zLOG import LOG, ERROR
import sys
LOG('PostTraverse', ERROR,
'Error while invoking hook: %s' % `f`,
error=sys.exc_info())
___
Zope-Dev maillist - [EMAIL PROTECTED]
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: Post-authentication hook
robert wrote: Please do Okeydoke: it's Issue #935. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Zope] Re: Proposed installation changes for review
Guido van Rossum wrote: Well, in a typical installation, you won't be running ZEO on the same machine as Zope, right? ZEO has its own install and config stuff, which is very similar to that for Zope, but ZEO is not installed as part of the main Zope install. I routinely run ZEO on all of my sites, on the same machine. I don't gain any scalability benefits this way, but it is fantastic for debugging and tweaking a live site. My creaky old zctl.py auto-starts ZEO when necessary, using the same configuration data as it uses for the associated Zope instance, so they both know to use 'var/zeo.soc' to connect. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Vote] PEP308 voting began
Guido van Rossum wrote:
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python. If you can have a
not:.. expression, surely you can have an if:..:then:..:else:..
expression.
Now that you point it out, it's not even hard. Here's a
proof-of-concept, with really awful parsing (it obviously breaks on
nested if: then: else:), that actually works:
class IfExpr:
def __init__(self, name, expr, compiler):
self._s = expr = expr.lstrip()
m = re.match('(.*) then:(.*) else:(.*)', expr)
if m is not None:
condexpr, thenexpr, elseexpr = m.groups()
self._cond = compiler.compile(condexpr)
self._then = compiler.compile(thenexpr)
self._else = compiler.compile(elseexpr)
def __call__(self, econtext):
if econtext.evaluateBoolean(self._cond):
return econtext.evaluate(self._then)
return econtext.evaluate(self._else)
(Tested with
div tal:replace=if:options/x then:string:yes else:string:no)
Is this worth a robust implementation, ZPT folks?
Cheers,
Evan @ 4-am
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] Infuriating ZClass registry Heisenbug
My trunk and 2.6 sandboxes are now behaving themselves. Thanks, guys! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Infuriating ZClass registry Heisenbug
Shane Hathaway wrote: Shot in the dark #2: Does it enter the ClassFactory function in Zope.ClassFactory? That's part of the ZClass magic... although there are two ways that the pickler tries to load classes. ZODB only tries to load Persistent instances as ZClasses. If there are things inside the pickles that are not Persistent, yet come from a ZClass, ZODB will not treat them kindly. As far as I can tell, it doesn't enter *any* Python code. Unless there's some other reason for pdb to be unable to step into it, it seems to execute only C code right up to the ImportError. By contrast, I *was* able to trace through ClassFactory when it loaded the BTree -- the trace would then fail when loading the first Bucket. Apparently small OOBTrees store their state differently, because the trace fails on the OOBTree load now, and I can do unpickler.noload() and see the state tuple with all the keys and None where the ZClasses should be. Shot in the dark #3: Unfortunately, there's one bit of ZODB that I still don't fully understand, and that's setklassstate(). You might be running into this somehow. I'd hazard a guess that the latest cPickleCache does not do the right thing with setklassstate(), since no one has committed to maintain that part. Ugh, we need unit tests for that. I had never heard of it -- I'll have to take a peek. Here's a simple suggestion: after loading the site and browsing a few pages involving ZClasses, flush the ZODB cache and see if the bug appears right away. If so, it's probably occurring as a result of deactivation. I had pretty much been assuming that that was the case, but performing this test confirms it. Flushing the cache breaks things immediately. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Infuriating ZClass registry Heisenbug
More data: It may well be loading correctly, but it seems to be storing incorrectly. I managed to grab the ZGlobals pickle string, and it has the _zclass_ stored as a plain class instead of an oid. I copied the commented-out Python persistent_id() in ZODB/Connections.py into a method called test_persistent_id(), and compared its results with coptimizations' new_persistent_id. They matched for everything except _zclass_ objects, for which test_persistent_id returned the _p_oid and new_persistent_id returned None. I have no idea why this is. It would explain why the _zclass_es are stored wrongly, but not why everyone else isn't seeing major breakage. Argh, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Infuriating ZClass registry Heisenbug
I think I've fixed my ZGlobals, but there's definitely a problem in coptimizations. I made Connections.py use the Python persistent_id, restarted twice, and ZGlobals was fine on the second restart. Whew, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Infuriating ZClass registry Heisenbug
This past weekend I migrated a bunch of ZClasses and the web site that uses them from a scratch Zope instance into my production instance. Both run off the same 2.6 CVS branch checkout, connecting to ZEO servers running from the same ZEO trunk checkout. For a while after starting the server, everything works fine. After an unpredictable time period ranging from minutes to hours, suddenly my ZClass instances become broken, and I start seeing this in my log, over and over: 2002-12-10T11:33:18 ERROR(200) ZODB Couldn't load state for '\x00\x00\x00\x00\x00\x01\x1f\xc9' Traceback (innermost last): Module ZODB.Connection, line 533, in setstate ImportError: No module named */rJ6Q2CNqMJDSN4Okpwiuw== The object that fails to load state is a BTree Bucket belonging to the ZClass registry, and /rJ6Q2CNqMJDSN4Okpwiuw== is the GUID of one of my ZClasses. If I delete that ZClass, it complains about a different one. If I restart the server, everything works again, for a while, but I get the following in my log: 2002-12-10T11:36:49 INFO(0) ZCS:2443 Connected to storage -- 2002-12-10T11:36:49 INFO(0) ZODB Opening database for mounting: '144865536_1012175858.273945' -- 2002-12-10T11:36:49 INFO(0) ZODB Mounted database '144865536_1012175858.273945' at /temp_folder -- 2002-12-10T11:36:50 ERROR(200) ZODB Couldn't load state for '\x00\x00\x00\x00\x00\x01\x1f\xc9' Traceback (innermost last): Module ZODB.Connection, line 533, in setstate ImportError: No module named */rJ6Q2CNqMJDSN4Okpwiuw== -- 2002-12-10T11:36:50 ERROR(200) Zope A problem was found when checking the global product registry. This is probably due to a Product being uninstalled or renamed. The traceback follows. Traceback (innermost last): Module OFS.Application, line 218, in checkGlobalRegistry Module ZODB.Connection, line 533, in setstate ImportError: No module named */rJ6Q2CNqMJDSN4Okpwiuw== -- 2002-12-10T11:36:50 INFO(0) Zope Beginning attempt to rebuild the global ZClass registry. -- 2002-12-10T11:36:52 INFO(0) Zope The global ZClass registry has successfully been rebuilt. -- 2002-12-10T11:36:52 INFO(0) ZServer HTTP server started at Tue Dec 10 11:36:52 2002 Hostname: server1.shackworks.com Port: 8280 Help! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Infuriating ZClass registry Heisenbug
Shane Hathaway wrote: My first recommendation would be to turn your ZClass registry into an OOBTree. OOBTree has been maintained and updated. Good thought, but no dice. Since it is rebuilding the registry on every restart anyway, I went ahead and made the changes to my OFS/Application.py. I confirmed that ZGlobals is now an OOBTree, but subsequent restarts continue to show the same problem :-( I've placed pdb.set_trace all over the DB state-loading code. When I attempt to step into the state = unpickler.load() line during the loading of the ZGlobals OOBTree, it immediately throws an ImportError on the ZClass GUID. It doesn't even seem to enter the persistent_load or classLoader methods. Tracing this has gotten me all confused. I understand (I think) that when a ZClass instance is unpickled, persistent_load gets the ZClass GUID and uses that to look up the actual _zclass_ class in ZGlobals. What I can't understand is why it would try to import the GUID when loading ZGlobals. All it has it in is strings and the _zclass_ ExtensionClasses, and they should be handled by the normal unpickling machinery, right? Thanks, Evan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: bug in mapply.py?
Tim Hicks wrote: Given a call signature like: def method(self, *args, **kw) In this way, mapply.py seems to ignore the fact that I want my method to accept an arbitrary number of arguments (line 69). When mapply was written, its only purpose was to map explicit method parameters to request variables. There was no concept of RPC of any kind, so neither '*args' nor '**kwargs' had any kind of sensible interpretation. So, yes, mapply does ignore what you want :-) Unfortunately, given the way that XML-RPC and WebDAV have been piled on top of the initial implementation, I'm not sure how this could be fixed properly in Zope 2.x. Sorry, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Strange Bug in Scripts (Python) and Python code ...
Joachim Werner wrote: These few lines brought the Zope server (and the Browser I used for testing) to a halt: html = '' for letter in 'ABCDEFGHIJKLMNOPQRSTUVWXYZ': html += '|'.join([html, letter]) return html This computes a string O(2^26) in length. Scripts make very little attempt to prevent excessive consumption of memory or CPU, since the only sure way to do this is to have hard OS-level limits on a per-thread basis, plus the ability to cleanly shut down a thread that violated the limits. If someone maliciously writes a Script to take down your Zope, you can revoke their login (unless you allow Anonymous to edit Scripts :-P). It would be nice to more protection against code such as your example that accidentally spins out of control, but your example also demonstrates just how hard this is to do. The interpreter would have to check the size of every object it constructed, at every step, in order to catch this case. This could easily drag performance down by an order of magnitude. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Only anonymous in an Access Rule?
Chris Withers wrote: How come getSecurityManager().getUser() returns the Anonymous User in access rules? Surely some checks must have been done to see whether the folder containing the access rule can be traversed to? If not, then huh? I'm confused :-( Access Rules trigger during publishing traversal, and authentication isn't performed until publishing traversal is complete. Until traversal is complete, Zope can't know which containers to check for User Folders. Also, publishing traversal only checks __roles__ on the last object in the traversal. This is very different than unrestrictedTraverse(), for instance, which checks permissions at every traversal step. This means that you can set security in a way that allows a user to access an object via ZPublisher that they could not access programmatically. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
Jim Penny wrote: I have also said that, while ZPT is not as warty as DTML, ZPT looks, on the surface, to be pretty ugly. I have said that there are three specific things I dislike about ZPT -- 0) lots of things have changed spelling again -- request v. REQUEST, here v. context v. container v. this v. ? I understand this, but ZPT design was deliberately not constrained by DTML or Script binding design. DTML has no way to spell 'here' or 'container', and 'this' is actually a method defined by one of the Zope mixin classes. REQUEST is an artifact of acquisition, an attempt to deal with a giant pile of (possibly conflicting) names that doesn't make sense in the TALES namespace. So, the only real spelling changes are acquisition's REQUEST vs. request and Scripts' context vs. here. During development, we often referred to the entire collection of standard TALES variables as contexts, so calling the current traversal object context felt peculiar. 2) the order of operations, which I think is baroque. Six levels of precendence for eight statements is pretty amazing. And it is certainly harder to explain/remember than things happen in the order you specify. As mentioned before, several decisions were made based on the constraints of XML. Process XML with XSLT, or some other standards-compliant filter, and you cannot guarantee that the order of attributes will be preserved. Frankly, I don't see the difficulty. All you need to remember is that variables are defined first and substitions happen after repetition. The only thing I would change now is to make repeat come first. I will add a fourth nit -- I cannot see why attributes should be plural when every other command is singular. Certainly it feels like attribute ought to be an acceptable spelling of the atttributes command! I suggested allowing both singular and plural versions, but it was roundly rejected by Jim and Guido (among others) on the basis of too many ways to spell things. Also, the only other TAL statement that can have multiple parts is define; define a variable and define variables both sound right. My most-missed DTML feature has not been mentioned at all -- it is not loop batching -- it is the dtml-else option of dtml-in -- which made it much easier to handle the nothing found case. Yes, TAL's constraints make else-type logic hard to do well. It's not all bad, though; if you define a variable for your list you can easily do: div tal:repeat=value seq.../div div tal:condition=not:seqelse/div I also have not found a convention that I am comfortable with on handling check-boxes and radio buttons in error processing. But I expect to! What do you mean? Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Speaking of 2.6...
Lennart Regebro wrote: There is an alternative, and that is to clean up the enhanced enhanced virtual host monster we at Torped have done. It's based on sfm@imemes enhanced VHM and just like VHF is makes it possible to have standalone virtual hosting without strange apache magic. We added an API to translate virtual to physical paths and back. Just so you know, a limited version of the imeme enhancements is in the Zope 2.5 VHM, and there is a standard REQUEST API consisting of physicalPathToVirtualPath, physicalPathToURL, and physicalPathFromURL. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: typo in HTTPResponse.py
Christian Theune wrote: Hmm. Is it possible to implement some option to turn this off? I just checked in the ability to use HTTP_TRACEBACK_STYLE to control the appearance of tracebacks in non-debug mode errors: '' (default): Place it in an HTML comment 'none': Omit it 'plain': Include it as plain text just as in debug mode. 'js': Show a sect; that expands into the traceback when clicked. Cheers, Evan @ Zope ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] User Name in python script
Sebastian Sippl wrote: I need to get the name of the current user , in a python script In a recent Zope, you should be able to use: from AccessControl import getSecurityManager user = getSecurityManager().getUser() Cheers, Evan @ Zope ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Getting Unauthorized from __bobo_traverse__.
Steve Alexander wrote: ... which you can't use from restricted things like (Script) Pythons and DTML Methods. So, the answer lies in External Methods and Python Products. If only I could remember what the question was... There was a bug, fixed in 2.4.1, with restrictedTraverse across __bobo_traverse__ when the security is controlled by the container rather than the target object. If you grab OFS/Traversal.py (I think) from the CVS root, it should fix the problem. Cheers, Evan @ Zope ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] TALES in DTML
I've been given time to work on draft documentation changes for: http://dev.zope.org/Wikis/DevSite/Proposals/DTMLplusTALES If you're interested, now is the time to comment. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] XXXPythonScripts release 1.0
After seeing the demand for this in a thread on ZopeZen, I've decided to release XXXPythonScripts, at: http://www.zope.org/Members/4am/XXXPythonScripts This Product adds a new Script meta-type: Script (Python, unsafe). You can only create or edit these objects when your Zope has been started with a special environment variable set. The envar name is whimsical, but this isn't a joke; By using this Product you add a risk to your system equivalent to using Telnet to log in as the Zope user. If somebody sniffs/guesses your login and this is turned on, they can write Scripts to do whatever the Zope process user can do! These are compatible with Zope 2.3.x only. I have no immediate plans to make them work with 2.4.x, but it shouldn't be hard. Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Where did DocumentTemplate/VSEval.py go in 2.4.0a1?
Michel Pelletier wrote: Should we make an alias for bw-compatability? This is now in the trunk, along with some other compatibility changes that allow Python Methods to continue working, courtesy of the NewZopeOrg migration project. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Where did DocumentTemplate/VSEval.py go in 2.4.0a1?
Morten W. Petersen wrote: one of my products landed flat on its face when an ImportError was raised trying to import VSEval from DocumentTemplate; is there a new class / function of some sort or simply another name for the class? See $ZOPE/lib/python/RestrictedPython. That replaces both DocumentTemplate's VSEval and PythonScripts' zbytecodehacks. It contains an Eval class that should be drop-in compatible with the old one. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: DTML-Python confusion (RE: [Zope] How to make a script return rendered dtml)
Bjorn Stabell wrote: Is it possible to append an object to the namespace? Isn't that what dtml-with does? It does, but there's some magic involved (non-mapping objects have to be wrapped in an adaptor first) and it uses an interface that isn't available in a restricted code environment such as Scripts. But the other way around, calling Python functions from DTML (via dtml-var func) the positional arguments are gotten from the namespace, right? Not for just any Python functions, no. For Scripts, yes, *if* you use the Bindings tab of the Script to give a name to the caller's namespace. The reasoning here is that a Script won't do anything with the caller's namespace unless you tell it to. Otherwise you have to use dtml-var expr=func(x,y,z) type notation. So why do so many DTML methods / documents have REQUEST as an explicit argument? It looks like a convention that has to mean something. That's just the generic call signature of DTML. If the callee is to have implicit access to the REQUEST, you have to either pass the REQUEST itself or a proper namespace as the second parameter. DTML was never really designed to be called with explicit parameters. I am a little bit confused about the fact that the acquisition path is related to how the document was called, not just to the containment relationships it is involved in. Or is it? myobj.aq_parent isn't necessarily the object that contains myobj? Correct. Acquisition is a complex subject, and a lot has been written about it on Zope.org. When you write /A/B, B could be contained in either A or / (the root), but its acquisition parent is A. Is the namespace stack basically the same as the acquisition path? Nope. Each Zope object on the namespace stack has its own acquisition wrapper. Fortunately, there usually aren't very many Zope objects on the stack. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: DTML-Python confusion (RE: [Zope] How to make a script return rendered dtml)
From: Bjorn Stabell [EMAIL PROTECTED] How do you do dtml-with and dtml-let in a Python script? (I.e. put something on the namespace) You can't. Scripts can use the DTML namespace in the same way that Python expressions in DTML can, but that's it. On the other hand, you can create (and pass along) all the local variables you want. How do you give positional (not keyword) arguments to a DTML method; is there any difference? Keyword arguments are put on top of the namespace. You can't use positional arguments, except the standard (None, _) idiom. DTML was never meant to pass arguments around, that's what the namespace is for, for what that's worth :-P When is __call__ called, when is __str__ called, and when is index_html called? When an object with a publishable 'index_html' attribute is the target of a request, that attribute is used. Failing that, or if the object is rendered by calling it from DTML or a Script, __call__ is used. DTML's var tag will try to convert whatever you give it into a string, so if you give it an object with a __str__ method, it'll get called. When does RESPONSE need to be passed; it can always be gotten from the REQUEST, right? Right. Are namespace, _, REQUEST, and context just different names for the same thing? Not quite. The namespace, accessible in DTML as _, is a pile of objects. The REQUEST is a particular object created by ZPublisher to hold information about the request, such as form variables and URL information. The context (or client, for DTML) is the object on which the method was called. If the DTML Method is the target of the request, or if you pass a client as the first argument when calling it, the Method pushes it onto the namespace. Also, the context (like any other Zope object) is acquisition wrapped. The ultimate acquisition parent of any publsihed object is a special wrapper for REQUEST. All this means that when you ask the namespace for the name foo, it will end up looking for it in the context, in the context's containers all the way to the root, and the REQUEST. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug in Zope VersionControl
From: Martijn Pieters [EMAIL PROTECTED] REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer environment, this is '/'. In a situation where the Zope server is running behind another webserver, and is not at the root of that server, SCRIPT_NAME represents the path to the Zope server. SCRIPT_NAME is not reliable in the presence of virtual hosting. Use REQUEST['BASEPATH1'] instead. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope] ANNOUNCE: Zope 2.4.0 alpha 1 released
- New restricted execution architecture A note about this for those who have run afoul of restrictions on builtins such as 'list', 'map', and 'range' in Scripts and DTML Python expressions: In the new architecture, there are (by default) no attempts to protect the system against excessive CPU or memory utilization. Unless you explicitly turn on such limits (not implemented yet), anyone who has permission to write DTML or Scripts in your Zope can accidentally or deliberately consume all available resources with infinite loops or huge data structures. Realistically, they could before, they just had to be slightly more creative. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Grrr... Python Scripts
From: Chris Withers [EMAIL PROTECTED] Could that we added to PythonScripts/standard.py so I don't have to do it all the time? This is just part of a general security review that needs to happen. I suppose we need a place to collect suggestions about objects that ought to be exposed to restricted Python. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Grrr... Python Scripts
From: Chris Withers [EMAIL PROTECTED] Where should I import CatalogError from? And _please_ don't tell me I have to go through some convoluted security process to do this :-( # After adding security decls from Catalog import CatalogError Use the same security process as providing access to anything Zope doesn't already expose. We should expose exceptions like this by default, but we haven't yet. Sorry. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT 1.2, TAL 1.2, ZTUtils 1.0 Released
From: Frank Sonnemans [EMAIL PROTECTED] This update breaks my previously working code. My site master template calls a dtml component to render a simple menu. This worked with the previous release of ZPT, but now results in a Name Error for the PARENTS[] variable. What changed in the new release to cause this and how are we now supposed to call dtml-components to avoid this problem. (Output Trace, dtml-code and object call syntax below) The most reliable way to call DTML from ZPT is using a Python expression, so that you can explicitly pass the client object and request mapping. Try something like this: tal:define=result here.my_dtml(None, request) or tal:define=result here.my_dtml(here, request) The problem that you're having is a change in the implicit DTML call code to make ZPT variables available to called DTML code. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZPT 1.2, TAL 1.2, ZTUtils 1.0 Released
Actually, I uploaded these at 5pm today, then I had to run and catch a plane. I still haven't updated the Project wiki, but if you visit: http://www.zope.org/Members/4am/ZPT ...you can pick up the latest. You need to download all three; PageTemplates goes in a Products directory, TAL and ZTUtils go in 'lib/python'. There's a trio of example Page Templates (with support data) that you can try out by copying PageTemplates/examples/zpt_examples.zexp into your import directory and importing it somewhere. One of them shows off batching, another shows how to make a tree widget, and the third calls DTML from ZPT. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Two new proposals: InstallationAndConfiguration and PrefixedTagVariables
http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration outlines a new process for installing and configuring Zope. http://dev.zope.org/Wikis/DevSite/Proposals/PrefixedTagVariables describes a variant of Tino's fix for sequence-item variables. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SiteAccess: virtual host monster and setServerURL issue
From: "Joseph Wayne Norton" [EMAIL PROTECTED] The correct virtual URL is not setup properly because the setServerURL method is always picking up the port #1080 (via oldhost,oldport) from the mod_proxy/mod_rewrite request environment even if HTTP_HOST does not contain a port number. This is deliberate. Omitting the port number means "leave it alone". If you want port 80 (the http default), you need to specify it. Generated URLs will not have ":80" in them, since it *is* the default port. Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SiteAccess: virtual host monster and setServerURL issue
From: "Joseph Wayne Norton" [EMAIL PROTECTED] The generated URLs should not have :80 in them and they do not ... rather they have :1080 included in the generated URLs although I have specifed something as follows: mod_rewrite result: proxy:http://localhost:1080/VirtualHostBase/http/www.foo.com/vtfs/www.foo.co m/vdmn/prd/vstg/VirtualHostRoot/ [OK] Exactly. You haven't specified the port. You need this: proxy:http://localhost:1080/VirtualHostBase/http/www.foo.com:80/vtfs/www.foo .com/vdmn/prd/vstg/VirtualHostRoot/ p.s. One more related question have you tried using mod_proxy/mod_rewrite with zope's webdav source port (-W) and virtual host monster? I haven't tried it, but I have no reason to expect that it wouldn't work properly. Cheers, Evan @ digicool @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Page Templates: Any plan how to use PT's for I18n and browser dependant templates etc?
From: "Johan Carlsson" [EMAIL PROTECTED] Now comes the tricky thing, case I want to render with the tal tags intact. I just tested that and they are intact after render. Jippi! This will be optional in ZPT 1.1, most likely. The next step I want to do is to save the template back to Zope and extract some of the tal:content tags and save them back to my_content. Wha? You want to parse out the rendered contents of some tags and save them? Will the user be editing the rendered page somehow? I noticed that I can access the macros of a METAL template after its been cooked (or used anyway). Is there anyway to parse a TAL template to extract part form it, preferably from Python? You could use the same code that TAL itself does, I guess. What are you trying to accomplish? Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Page Templates: Any plan how to use PT's for I18n and browser dependant templates etc?
From: "Johan Carlsson" [EMAIL PROTECTED] As fas as I can see the METAL definitions are inside the template. That would mean one would some external service to route it to the correct template. For instance: use-macro="portalskins/macros/useme" portalskin in this case would return a template based on the HTTP_USER_AGENT, REQUEST.portal_skin and HTTP_ACCEPT_LANGUAGE (and others of course). Sounds good to me! How would this effect the page cooking and template cache? Cooking isn't affected. You would naturally want to make your cache sensitive to the same REQUEST parameters as the switching script. PS. Page Templates are great but I have yet to figure out how to use them with the "Content is folderish" pattern. You can acquire a template into a content folder, then use "here/" paths to access bits of content. Is that the sort of thing you mean? Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Page Templates and nested templates
From: "Johan Carlsson" [EMAIL PROTECTED] Would it be completely stupid to be able to nest Macros. That is, you would have one MainMacroTemplate defining several Slots/SubMacros and then make several SubMacrosTemplates that inherents from the MainMacroTemplate, defining the Slots/SubMacros as new Macro definitions. This would give you an hierarcy of templates and make it possible to factor out common stuff higher up in the hierarcy and leaving the sub templates to handle specialisation. You should definitely be able to nest macros. If you can't right now, it's a bug. Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ANN: Zope Page Templates 1.0.0 beta 1
The first beta release of ZPT is ready! Come read about them at http://dev.zope.org/Wikis/DevSite/Projects/ZPT, and download from http://www.zope.org/Members/4am/ZPT. These should be especially interesting for teams of Zope developersin whichthe programming and page/site design tasks are handled by separate people. Cheers, Evan @ digicool
Re: [Zope-dev] call pythonscript from python
From: "Tim McLaughlin" [EMAIL PROTECTED] Anybody know how I can call a pythonscript from python? Currently I can call it, but I seem to have no context or security context, because it either will not let me access anything or fail with an attribute error in the context. What are the params that I NEED to pass in so that it can do its bindings (and if you know how to get them automagically, that would be incredible)? How does the Python code get executed (External Method? Product?) and how does it get access to the Script? Calling a Script should indeed automagically give it context from its acquisition wrapper. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT trials and tribulations
From: "Phil Harris" [EMAIL PROTECTED] The problem is that I'm getting a traceback (I won't bore you with the details unless I have to) to the effect of 'ui' being unknown. Mmph. That release has a problem with exposing TAL variables to Python code. There will be a *much* better one Real Soon Now. Cheers, Evan @ digicool ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] getPhysicalPath?
From: "Christian Scholz" [EMAIL PROTECTED]
And can someone explain to us where the differences between
aq_chain and getPhysicalPath() are? Actually getPhysicalPath()
seems also to walk up aq_parent. Or am I missing something?
"aq_chain" gives you a list of the objects traversed to get to your object,
in reverse order.
"getPhysicalPath" gives you a tuple of the Ids of all objects on the
shortest path from the root to your object.
So, given a hierarchy like this:
A__B__C
|_D
|_E
Object C has physical path ('', 'A', 'B', 'C') no matter how you get to it.
Its acquisition chain, on the other hand, depends completely on the path you
use to access it:
A/B/C = [C, B, A]
A/D/B/C = [C, B, D, A]
A/B/D/E/C = [C, E, D, B, A]
*WARNING*: "aq_chain" does *not* tell you the order in which acquisition
will search the objects. That is more complicated.
Cheers,
Evan @ digicool
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Site Access Rewrite Rule documentation?
From: "R. David Murray " [EMAIL PROTECTED] So, clearly I don't have a clue what stack is supposed to contain or what changing it does. Can anyone point me to docs or give me some help? You can also tell me, "that's stupid, just solve your problem this way"... You've got it almost right, you just have to know that it's called a stack because it's used that way by the publishing machinery. This means that the names on the stack are always in *reverse* order of how they appear in a URL; "stack[-1]" is the next name to be traversed, not "stack[0]". As you inferred, changing the stack will change the publishing path, and your code, suitably adjusted, should do what you wanted. Something like this (in "/", not "/Books"): stack = context.REQUEST['TraversalRequestNameStack'] if len(stack) =2 and stack[-1] == 'Books' and stack[-2][:6] != 'manage': stack[-1:] = ['marketItems', 'store'] Note that unless you need it to exist for some other reason, you don't even have to have an actual "/Books" Folder for this code to work, and you could leave out the 'manage' check. Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] REQUEST.steps
REQUEST has a lot of standard attributes and keys, some of which are
obsolete.
Deprecated attributes:
o script: URL for the root object, computed from environment variables
including SCRIPT_NAME. Replace with REQUEST['BASE1'] or REQUEST['BASEPATH1']
o base: URL for level above root object, computed from same environment
variables as script. Replace with REQUEST['BASE0'] or REQUEST['BASEPATH0']
Unaffected by virtual hosting:
o steps: list of names traversed during publishing.
o PARENTS: list of objects traversed during publishing, including objects
added by __bobo_traverse__ hooks. The order of this list is reversed once
publishing is complete.
Virtual hosting-aware keys:
o URL: URL of current traversal target relative to VirtualRoot.
o URLn: URL with n path elements removed from the end.
o URLPATHn: URLn without SERVER_URL.
o BASEn: URL including only the first n-1 elements after the VirtualRoot.
o BASEPATHn: BASEn without SERVER_URL.
o SERVER_URL: URL of the server ('http://hostname:port')
Cheers,
Evan @ digicool 4-am
o VirtualRootPhysicalPath: The physical path of the virtual root. Used to
compute absolute_url().
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python Scripts Bug Question
From: Chris Withers [EMAIL PROTECTED] The Bug: If I use an name other than 'context' to bind to context, I quite often (but not always :-S) get a KeyError on that name. I'll check this out. It's in the Collector, right? The Question: If I'm calling a Python Script from a Python Product (for example), how would I pass a namespace to the script that would get bound as the namespace argument? Treat it as a keyword argument. "Caller's namespace" is the only one of the binding names that behaves this way, since the caller has complete control over the contents of the namespace anyway. For example: myps(_=ns) Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python Scripts Bug Question
From: Chris Withers [EMAIL PROTECTED] Cool :-) And even though I pass it in as _, it'll get bound to whatever is specified on the bindings tab, right? Nope. If you called it "fred" on the bindings tab, pass it as "fred". Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python Scripts Bug Question
From: Chris Withers [EMAIL PROTECTED] I'm calling a python script with the context bound to, lets say, 'fred'. I call the python script like this: result = self.aq_acquire(variable_containing_name_of_PS)(a_dictionary) ...where self is an instance of my python product, and a_dictionary, is, well, a dictionary that's aimed at the specified parameter of the python script. "aimed at"? This will pass the dictionary as a single positional parameter. It won't do anything with bound names or keyword parameters. Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Waaagh! Python Script won't allow __setitem__
From: Chris Withers [EMAIL PROTECTED] I've got an object which implements __setitem__ in such a way that it's perfectly safe for use in Python Scripts. Sadly, it seems that Evan's Byte Code hacks won't let me do this :-( The only way that the security code can know that your __setitem__ is safe is to rename (or alias) it to __guarded_setitem__. Ditto for other such methods. If I try and do: if type(x) == type(0): Use the Script builtin "same_type" instead: if same_type(x, 0): # Whatever Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Waaagh! Python Script won't allow __setitem__
From: Chris Withers [EMAIL PROTECTED] But what's so bad about type()?! When applied to an Extension Class, it gives you access to the actual class, rather than a nice inert type. Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Virtual Host Monster Paranoia
From: "Chris Withers" [EMAIL PROTECTED] Well, it's easy enough to find out if a site is running Zope, then this becomes pretty easy attack to think of I'm not going to claim that this is perfectly harmless, but I can't think of any way in which this could be termed an "attack". You can already provide any traversal path you like in the URL; All VHM adds is the ability to manipulate generated URLs, and in fairly crude ways. These URLs come back to your browser in a page, where they have no more potential for harm than if you'd assembled them by hand. The only scenario I can imagine where this could even affect the operation of a site is one where the site uses URLs internally in some fashion. This is part of the reason that Zope has shifted from using URLs to paths when addressing objects, since paths are unaffected by URL manipulation. Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ProxyPass and SiteAccess getting REMOTE_ADDR
From: Oliver Bleutgen [EMAIL PROTECTED] Btw. with a small module it's even possible to log the usernames with apache, something medusa isn't capabable of afaik (as of zope version 2.3). Cool! What module is this, and how do you use it? Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Problem: manage_workspace redirects to index_html
From: "Dylan Jay" [EMAIL PROTECTED] I'm using IE 5.01 on w2k. The current 5.01 version of IE doesn't do basic authentication correctly (or, at least, the way nearly every other version, and browser, does it). Try getting 5.5sp1 instead. Cheers, Evan @ digicool 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope] porting from Python Methods to PythonScripts in 2.3.0; LoginManager too
From: "Fred Yankowski" [EMAIL PROTECTED] + Don't copy over SiteAccess and PythonMethods. + Delete the PythonMethods product from the Control_Panel/Products management folder. Will I have to manually convert each existing Python Method to a PythonScript, or are they essentially the same type? They are radically different types, and can therefore live in the same Zope, side-by-side, without conflicting. There is no automatic conversion process. Simply keep PythonMethods installed, and replace individual Methods with Scripts as you feel the need. Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] porting from Python Methods to PythonScripts in 2.3.0;LoginManager too
From: "Jim Washington" [EMAIL PROTECTED] Standard caveats, YMMV, etc, but it does a quick pass on the Methods in the folder where it is and makes Scripts from them when you hit the 'test' tab, saving the old ones as methodname.old. Excellent! Thanks for writing and sharing this -- it looks like a fine candidate for a HOWTO. Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Python Methods can't construct literal dictionaries?
This is one of the shortcomings of Python Methods that Scripts eliminate.
You can work around it by writing:
x = {}
x.update({y: z})
Cheers,
Evan @ digicool 4-am
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] PythonScript question
From: "Timothy Wilson" [EMAIL PROTECTED] Error Type: TypeError Error Value: argument 1: expected read-only character buffer, instance found [snip] input name="display_date:date" size="20" value=""/td [snip] D = string.split(display_date, '/') You are marshalling 'display_date' as a date, then trying to treat it as a string. You need to either convert it to a string or use date methods. Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] SiteRoot 2 errors
From: Stephan Goeldi [EMAIL PROTECTED] I want to add a SiteRoot to my domain subfolder. I installed a fresh Zope 2.2.5 and in the lib/python/Products folder I extracted SiteAccess-2.0.0b4-nonbin.tgz. After this I restarted Zope. When I click to Add SiteRoot, I get the following error message: [snip] File /usr/local/zope/lib/python/DocumentTemplate/DT_String.py, line 566, in read_raw (Object: www/SiteRootAdd) IOError: (see above) Check the file ownership/permissions on the SiteAccess directory and its subdirectories. Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Acquisition Algebra; interaction of containment and acquisition is confusing
From: Fred Yankowski [EMAIL PROTECTED] for the very last case, "a.b.c.x". I just can't follow why the equivalent expression isn't x.__of__(a).__of__(c.__of__(b.__of__(a))) rather than the more complex answer given: x.__of__(a).__of__(b.__of__(a)).__of__(c.__of__(b.__of__(a))) You can expand any access path into an acquisition expression using the following 3-1/2 rules: 1. Given an unwrapped object 'x', x.child = (child o x) 2. Given a wrapper (self o parent), a. (self o parent).child = self.child o (self o parent) if 'child' is found in 'self'. a. (self o parent).child = parent.child o (self o parent) if 'child' is found in 'parent'. 3. Reduce ((a o b) o (b o c)) to (a o (b o c)) as soon as it appears. So, a.b = (b o a). a.b.c = (b o a).c = (b.c o (b o a)) = (c o (b o a)). Finally, a.b.c.x = (c o (b o a)).x = ((b o a).x o (c o (b o a))) = ((a.x o (b o a)) o (c o (b o a))) = (((x o a) o (b o a)) o (c o (b o a))) When I run the test cases given in the document I see that the latter does match the behavior, but I find that baffling. In particular, why is the effective search order x-a-b-c rather than x-a-c-b? It almost looks like the effective search order could be described as "up through the containment heirarchy, then down through the remaining acquired path", but I'm not at all sure if that's a valid generalization. Almost. It's "up through the containment hierarchy, then the rest of it somehow". Trying to control or predict the exact search order for any but the simplest acquisition trees is a dangerous game. You can read it off directly from the algebra form, as in (((x o a) o (b o a)) o (c o (b o a))) = x, a, b, c (ignoring duplicates), but it's unlikely to be useful, as you saw. Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Acquisition Algebra; interaction of containment and acquisition is confusing
From: Fred Yankowski [EMAIL PROTECTED] Now, does that bother anyone besides me? Since acquisition is intrinsic and ubiquitous in Zope, shouldn't we be concerned that it is hard to control or predict? Keep in mind that it is only the *order after containment* that has this problem. For instance, schemes to "skin" a subfolder by changing access paths should ensure that there is always exactly one "skin" implementation in the acquisition path. It is tempting to provide a "default skin" in the containment path, but then you can't override it. Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] VirtualHostMonster, PATH_INFO and absolute_url
From: Philip Aylesworth [EMAIL PROTECTED] I would appreciate that HOWTO. :) I am going to need virtual hosting for a project I am undertaking and don't even know where to begin. Is VirtualHostMonster part of SiteAccess (which I have just discovered when I did a search on zope.org)? Do I need to use apache for it? Should I use apache rather than ZServer if I don't need any of apache's features? If you genuinely don't need Apache, ZServer is certainly good enough. Many people (such as myself) use Apache for a cheap management/performance win serving large utterly static content like images, for battle-tested SSL, and for the ability to run other back-end servers or CGI in parallel. VirtualHostMonster is a newish SiteAccess component that makes virtual hosting easy for the most common cases, where Apache or some other thin back-end is handling the incoming rewriting, and the rewriting consists of host/port renaming and path insertion (http://www.myhost.com/ = http://localhost:8080/myhost). In this case, all you need is one VirtualHostMonster and a slight, easy change to your rewrite/proxy directives. Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] VirtualHostMonster, PATH_INFO and absolute_url
From: Itai Tavor [EMAIL PROTECTED] 1. When accessing http://10.0.1.21/spam PATH_INFO is /VirtualHostBase/http/10.0.1.21:80/MySite/VirtualHostRoot/spam, which breaks any method that uses PATH_INFO (For example, the login form of LoginManager). Can this be fixed somehow? The Zope virtual hosting machinery doesn't adjust CGI variable. Applications should use URL0 or URLPATH0 instead of PATH_INFO. 2. In this setup, if I got it right, absolute_url() for /MySite/spam should return http://10.0.1.21/spam. But it returns http://10.0.1.21/MySite/spam. Something's broken? Yep, VirtualHostMonster has a bug, now fixed in CVS. Thanks! Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Add this to Wish list
From: Jerome Alet [EMAIL PROTECTED] Please could you include a button "Download Source" to the Python Script edition form ? Already done; There's a link in the paragraph below the text area, and above the upload form (in CVS). Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Did I miss some major change in Z SQL Methods ?
From: "Curtis Maloney" [EMAIL PROTECTED] A Z SQL Method ( Returner.sql.getDetails ) [snip] dtml-with "Returner.getDetails(Returner, User=12)" dtml-var fieldName /dtml-with You want either: dtml-in "Returner.getDetails(Returner, User=12)" dtml-var fieldName /dtml-in ...or... dtml-with "Returner.getDetails(Returner, User=12)[0]" dtml-var fieldName /dtml-with Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] VirtualHostMonster, PATH_INFO and absolute_url
From: "Itai Tavor" [EMAIL PROTECTED] Great, thanks for the fix. It's fine in Zope 2.3b3. I should probably write a Howto for VirtualHostMonster, and ask the folks who've written the various fine SiteAccess-related Howtos to incorporate it. It really is a lot easier and safer to use than SiteRoots 98% of the time. Cheers, Evan @ digicool 4-am ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
