Re: [Zope-dev] No feedback for SOAP patch ?
- Original Message - From: "Petru Paler" <[EMAIL PROTECTED]> >I received zero feedback on the SOAP support patch I sent a few days ago... > I no one is interested I guess I should just forget about it and find something > else more interesting ? I've barely had a free second with functioning brain capacity this past week, but I'm interested. More so now that Secret Labs has announced their SOAP client library at http://www.pythonware.com/products/soap If you haven't already popped your patch into the Collector, please do! Cheers, Evan @ 4-am & 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] SiteAccess in 2.0.0b2?
- Original Message - From: T.J. Mannos <[EMAIL PROTECTED]> > I'm having trouble getting SiteAccess 2.0.0b2 to work with Zope 2.2.0b2. > The first odd thing that happens is when I create a new SiteRoot, it says > that this object already has a SiteRoot (which it doesn't), but creates it > anyway. The second is: it doesn't seem to work at all! The value of URL1 > still has the :9080 port and the wrong virtual server. Any ideas? What's your platform (win, linux, *bsd)? Is this a Zope database which has been upgraded from an earlier version of Zope? If so, were you using SiteAccess 1.x with that earlier version? 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: The new SiteAccess and __no_before_traverse__?
- Original Message - From: "Christian Scholz" <[EMAIL PROTECTED]> > I am playing around with SiteAccess and Zope 2.2b1 right now and I wonder > if it's still possible to disable SiteAccess (actually an AccessRule) by > using __no_before_traverse__? > It seems not to and I am a bit trapped right now.. ;-) This has changed, and I need to make it clearer in the documentation. There is no longer a global "disable all __before_traverse__ hook" URL. Instead, there are specific SiteAccess object-disabling environment variables. You need to start Zope with environment variable SUPPRESS_ACCESSRULE set. There is a similar SUPPRESS_SITEROOT variable for SiteRoots. Fire up a command shell and type (*nix): SUPPRESS_ACCESSRULE=1 export SUPPRESS_ACCESSRULE or (Windows): set SUPPRESS_ACCESSRULE=1 ...and then whatever command you use to start Zope > Even deleting SiteAccess from the Products-Directory didn't work as then > Zope encountered a missing doc string error for the directory when trying > to access it. That's because the fundamental mechanism is built into Zope 2.2, rather than grafted on by SiteAccess 2. It does look like we'd better wrap the hook call in a try..except pass, though. Cheers, Evan @ 4-am & 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: The new SiteAccess and __no_before_traverse__?
- Original Message - From: "Martijn Pieters" <[EMAIL PROTECTED]> > This is because the README still points to SiteAccess version 1 > documentation... Add a '2' to the word SiteAccess in the URL.. > > Ethan, could you also use Structured Text in the README? IIRC this should be > possible, you can then actually click on the link instead of having to copy > and paste it. Or you could add Help files =) I'm definitely planning on adding Help files. I don't know if you can do structured text in a README. Cheers, Evan @ 4-am & 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] NASTY error. Why?
From: Chris Withers <[EMAIL PROTECTED]>
>
> Error Type: TypeError
> Error Value: read-only character buffer, Python Method
Looks like the 'id' of something along the line is a method rather than a
string. Try "_.getitem('id', 1)".
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] getting request variables values
The value you're after is stored in the 'environ' section of the request. Unlike 'other' and 'cookies' keys, 'environ' keys can't generally be fetched as attributes or keys of REQUEST. You need to access them as REQUEST.environ['keyname']. 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] Acquisition Confusion :S
From: Chris Withers <[EMAIL PROTECTED]> > In anser to 'What is A.B.C.D?' I can't see how you can get: > ((D o (C o A)) o (B o A)) > > Here's my working: > > A.B.C.D = (B o A) : .C.D > = ((C o A) o (B o A)) : .D > = ((D o C) o ((C o A) o (B o A))) This last line should be (((D o C) o (C o A)) o ((C o A) o (B o A))), which simplifies to ((D o (C o A)) o ((C o A) o (B o A))) and then (D o ((C o A) o (B o A))). In this case aq_inner is the entire expression, since aq_self is not a wrapper. The IPC8 slides are in error, and need to be fixed. 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] Acquisition Confusion :S
From: Chris Withers <[EMAIL PROTECTED]> > I still don't get this :( Here are the two and a half rules for deriving acquisition from a dotted expression: 1. A.B == (B o A), where A is an unwrapped object 2. (self o parent).B == a. (self.B o (self o parent)), if B is found in 'self' b. (parent.B o (self o parent)), if B is found in 'parent' > A has attributes B and C, C has attribute D > > A.B.C.D = (B o A) : .C.D by rule 1 > now, since C is found in A: > > = ((C o A) o (B o A)) : .D by rule 2b, then rule 1 = ((C o A).D o ((C o A) o (B o A))) by rule 2a = ((C.D o (C o A)) o ((C o A) o (B o A))) by rule 2a = (((D o C) o (C o A)) o ((C o A) o (B o A))) by rule 1 and then simplification, applied upwards, gives: = ((D o (C o A)) o ((C o A) o (B o A))) = (D o ((C o A) o (B o A))) > > In this case aq_inner is the entire > > expression, since aq_self is not a wrapper. > > I still don't get this at all :( If A==(self o parent), then If self is an unwrapped object, then aq_inner(A) == A else aq_inner(A) == aq_inner(self) In other words, aq_inner is the left-inner-most wrapper. Find the leftmost 'o' in the expression, and you've got 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] Acquisition Confusion :S
From: Chris Withers <[EMAIL PROTECTED]> > Who decided these rules and why are they like they are? They follow directly from the way the Acquisition machinery works, which was set up by Jim Fulton. > So, is the working below now correct? (I feel like I'm back in School > doing maths ;-) Yes. > Where is the order of simplification defined? In the Acquisition machinery, which simplifies upwards because that's the way it constructs the wrappers. 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] Acquisition Confusion :S
From: Chris Withers <[EMAIL PROTECTED]> > Who would be best to ask why it was set up the way it is? > > I'm sure there are very good reasons for it but the search order in all > but the simple cases is very confusing and not as useful as it could be. > > How much more work would it be to implement the following algorithm, > regardless of how the actual containment is? [snip] I haven't got the whole reason, but here are some of the pieces: - never expose a "bare" object, or even one with an incomplete context - allow the user to backtrack along the context chain These two together give you the part about aq_parent always being the previous acquisition result. - allow recovery of containment information - base security on containment These two motivate the simplification of raw acquisition. With the simplification, you get containment-first search and aq_inner.aq_parent gives you your fully-wrapped container. The current acquisition implementation is thus a weird hybrid of containment and context. It retains both sorts of information while providing the search semantics we want security to have. It isn't hard to convert a standard acquisition wrapper into either of the other sort. I'm going to propose adding something like the following functions: def aq_context(ob): context = [] while ob is not None: context.append(ob.aq_base) ob = ob.aq_parent ob = context.pop() while context: ob = context.pop().__of__(ob) return ob def aq_containment(ob): context = [] while ob is not None: context.append(ob.aq_base) ob = ob.aq_inner.aq_parent ob = context.pop() while context: ob = context.pop().__of__(ob) return ob ... so that you could write something like or &dtml-bar;. In the meantime, they make fine External Methods. 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] Acquisition Confusion :S
From: Chris Withers <[EMAIL PROTECTED]> > > - never expose a "bare" object, or even one with an incomplete context > > Why? You can get at it through aq_base anyway, surely? Only from unrestricted code. DTML and (CVS) Python Methods only let you access aq_parent. This only applies to objects that are part of the containment hierachy, of course. Brand new objects aren't wrapped, nor are simple non-persistent types like lists and dicts. > > - allow the user to backtrack along the context chain > > I take it this is the reason for wrappers? Would it matter if the > wrappers were structured differently to provide a different search > order? Only to anyone who depends on the current behavior :-) Also, there is a very limited range of "natural" ways to construct the wrappers. Once contructed, of course, we can fool with them in arbitrary ways. > > - allow recovery of containment information > > Urm, didn't quite follow that :S We want to be able to find out what an object's container is, regardless of what we acquired it from. In raw acquisition, there's no straightforward way to do this. In simplified acquisition, aq_inner.aq_parent is the container. The simplification is the rule (A o B) o (B o C) => A o (B o C). > Okay, so taking our long-running example: > > > A / > > I > > B/ > > I > > C/ > > D > > > > (A contains B and C, C contains D). > > (A contains an I, as does B) > > A.B.C.D > > Which I, if any, would each of the following return: > All of these would search the dotted expression from right to left, so they would give you B's I. > > > All of these would search the containers of the right-most object, so the first two would give you A's I, and the third B's I. > > > 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: Acquisition ( slightly less Confusion ;-)
From: Chris Withers <[EMAIL PROTECTED]> > Ah, okay... so really, prettymuch all Zope objects should be wrapped > with only one or two exceptions, most of which aren't actually objects > as such but simple data types? Yes. > > Also, there is a > > very limited range of "natural" ways to construct the wrappers. Once > > contructed, of course, we can fool with them in arbitrary ways. > > So I see, does this reduce efficiency at all? Sure, but the question is, does it reduce efficiency *unacceptably*, and I can't answer that. > > container. The simplification is the rule (A o B) o (B o C) => A o (B o C). > > I don't see how this simplification actually makes a difference... In the next step, if we ask for a D and it's found in B, we get: (A o (B o C)).D => (B o C).D o (A o (B o C)) => ((D o B) o (B o C)) o (A o (B o C)) => (D o (B o C)) o (A o (B o C)) instead of ((A o B) o (B o C)).D => (A o B).D o ((A o B) o (B o C)) => ((D o B) o (A o B)) o ((A o B) o (B o C)) The search order with simplification is D, B, C, A (containment first), while without it's D, B, A, C (just plain weird). 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] Still no safe seperators :P
From: "Chris Withers" <[EMAIL PROTECTED]> > Looks like the colon it is then, there's even a patch now ;-) There a patch sitting around waiting for DTML syntaxgeddon which allows slash-separated paths in object names everywhere, not just in entity syntax. That could easily be extended to also allow colons as separators. Cheers, Evan @ 4-am & 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: /, XML, DTML syntaxgeddon
From: Chris Withers <[EMAIL PROTECTED]> > I suggested the / thing to Steve who pointed out that > &dtml-/folder/object; is bad XML/SGML and so 'Not a Good thing (tm)' Yes, well, making DTML compatible with XML is explicitly *not* a current goal, although having ':' as an alternative separator should make folks who have to deal with it happy. In all other naming areas, especially indirect reference (ie. expr="_['/folder/object']") I much prefer slashes. > What's this DTML syntaxgeddon then? ;-) > This sounds like something I'd really be interested in as you can see > from my ZTL proposal on dev.zope.org. There are so many ideas for revising DTML that the whole thing ought to be done as a single large change (the syntaxgeddon) rather than dribbling out new features and spellings over time. That can easily make people feel that they can't keep up with "all these crazy changes". > However, I'm pretty confident that when say DTML is a mess right now, > I'm not far wrong. How can I get involved in the process to try and > rectify this? Just keep giving feedback on those proposals. 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] PythonMethod-related mini-proposal
I have a mini-proposal at http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/NamespaceObjectInte rface which I hope will take care of the last major barrier to the new version of PythonMethods. Jim asked me to put it in the fishbowl and get some feedback on it, so please comment if you have an interest. 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: Virtual Hosting in 2.2 - a Bestiary of Buglets
From: Itamar Shtull-Trauring <[EMAIL PROTECTED]>
> Problem 1: HTTP and HTTPS (more of a proxypass issue)
> ===
> I want to be able to serve both http and https versions of a site from
> Apache. Problem is, because of the way proxying works, there is no way
for
> Zope to know if it is origially being accessed via http or https. My
> solution? Add a folder in top level of Zope called "ssl". If we see our
> path as proxied by Apache is /ssl/websites/example, we know we are being
> accessed via SSL. Because of the magic of acquisition, this works, but
it's
> still an ugly hack, and slows things down.
If you think that's an ugly hack, you'll probably hate what I do ;-) I have
Apache RewriteRules that look like these:
RewriteRule ^/(.*) http://localhost:8080/_proxy/http/%{HTTP_HOST}/example/$1
[P,L]
(with https instead of http in secure virtual hosts, of course)
...and an Access Rule in my root folder (stack is the traversal stack):
if stack and stack[-1] == '_proxy':
stack.pop()
base = "%s://%s" % (stack.pop(), stack.pop())
request.setURL(base=base)
request.set('SiteRootPATH', '/')
Finally, I have blank SiteRoots in my site folders.
> Problem 2: ZCatalog
> =
> All the objects in /websites/example are being catalogged with paths such
as
> /websites/example/folder/myObject. However, when I gets the objects path
> using getpath(), it's not adjusted based on the virtual hosting settings -
> it's still /websites/example/folder/myObject, not /folder/myObject as it
> should be.
This is one of the many ZCatalog problems that Chris P. is now valiantly
tackling.
> Problem 3: Management interface
> =
> The breadcrumbs in the folder management screen (e.g. "/ folder1 /
> folder2"), still show the "/ websites / example", with links, when using
the
> virtual hosting. That is, the managemnt interface shows folders that we
are
> not supposed to be able to access when we are using virtual hosting.
As Chris Withers points out, this is due to deprecated data passed in calls
to tabs_path_info. I'll see that it gets fixed.
> Problem 4: Access to other virtual hosts (security issue?)
>
> When using virtual hosting, it is still possible to access the /websites
> folder for example, using acquistion. So I can view the contents of one
> website from the other: www.example.com/websites/example2, and
> www.example2.com/websites/example.
Unless this is a real security concern for you, and can't be address within
the standard Zope security framework, I wouldn't worry about it. As you
noticed, the optional 'hard' parameter to setVirtualRoot was a weak stab in
this direction, but I never spent enough time on it to really get it
working. That would involve (at least) providing some kind of replacement
Application instance to root acquisition in.
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 2 Questions
From: Chris Withers <[EMAIL PROTECTED]> > It looks like REQUEST.steps is the replacement for PARENTS? > Is that so? Actually, REQUEST.steps has always been there -- it's the list of *ids* that were traversed. This may or may not correspond to the ids of the PARENTS, depending on whether an object with a __bobo_traverse__ inserted extra objects or replaced itself in PARENTS. Then there is REQUEST._steps, which is new, and which is (as the _ implies) for internal use only. It's a pre-url-quoted list of steps, affected by virtual hosting, which is used to construct URLn and BASEn. Right now, I've working in a CVS branch on new REQUEST variables called URLPATHn and BASEPATHn, which are analagous to URLn and BASEn but only contain the path portion of the URL. Then all SCRIPT_NAME uses should be replaced with BASEPATH1, etc. > Small grumble: > REQUEST['TraversalRequestNameStack'] is a bit of a long-winded name :P Agreed. Jim pretty much mandated a name that (1) lives in 'other', rather than being an attribute, and therefore (2) is very, very unlikely to clash with other people's REQUEST variable names. > So now you have to restart Zope to undo a screwup? > I guess __no_before_traverse__, or whatever it was, was a security > whole, or something? No, it's just not specific enough. Now that the before-traversal hook is part of Zope, other services may want to use it, and so it shouldn't have a global on/off switch. As of SiteAccess 2.0b3, you can insert "_SUPPRESS_SITEROOT" and/or "_SUPPRESS_ACCESSRULE" into your URL in order to turn off a single SiteAccess object (the one which would have triggered at that point in the URL). > Hmm, the example for Multiple Sites isn't very robust :-( > http://www.zope.org/Members/4am/SiteAccess2/vhosting I didn't spend a whole lot of time fortifying it. It's just meant to be an example, after all. I wasn't expecting so many people to paste it into their applications without understanding what it does. :-) 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] PATH_TRANSLATED delimted with backslash ?
From: "Steve Alexander" <[EMAIL PROTECTED]> > obj = self.restrictedTraverse(REQUEST.PATH_TRANSLATED) > > This stopped working when I tried the software on Windows. > > Bug or feature? I'm not sure, but I'm *very* curious what you're trying to accomplish with this code. A better equivalent would probably be obj = self.getPhysicalRoot().restrictedTraverse(REQUEST.steps). 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] is INSTANCE_HOME broken on Win32?
From: Chris Withers <[EMAIL PROTECTED]>
> I'm trying to make Squishdot work with INSTANCE_HOME nicely.
> However, the testing is going wrong on a normal Win32 Install...
>
> I had lots of lines that went something like:
>
> f=open('%s/Products/%s.dtml' % (SOFTWARE_HOME,file))
>
> Which generates:
>
> E:\Zope\2.2.0\lib\python/Products/Squishdot/validArticle.dtml
>
> That's not very nice in itself but seems to work with Python's open...
>
> However, when I change them all to be like, for example:
>
>f=open('%s/Products/%s.dtml' % (INSTANCE_HOME,file))
>
> I then get:
>
> 'E:\\Zope\\2.2.0/Products/Squishdot/validArticle.dtml'
This looks correct to me. If no explicit INSTANCE_HOME is set, it defaults
to SOFTWARE_HOME minus '/lib/python'.
On the other hand, I wonder why you're constructing '%s/Products/' paths
explicitly like this. If this code is inside the Product to which you would
like the path, the proper way to get the path is:
from Globals import package_home
path = package_home(globals())
# path now probably equals
'E:\\Zope\\2.2.0\\lib\\python\\Products\\Squishdot' in your example.
I have no idea if or where this is documented, sadly. I'll definitely put
it in my 'writing INSTANCE_HOME-friendly Products' howto, as soon as I get
around to writing such a thing :-/ Or perhaps you could? ;-)
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] HiperDOM & xmlc
From: Phillip J. Eby <[EMAIL PROTECTED]> [snip description] > The effective external behavior of these two attributes, would be to let a > web designer load and save any page or template they wished in the site, > freely making changes to the header, footer, or various embedded elements > thereof, and then save that *one* page, and have those style changes > propagated throughout the relevant areas of the site. Exactly. You've just described the "components" aspect of this idea, which was left out of the Paul's original post. A component is just a tag marked with a special attribute that names it (and its path, if it has been saved). It can contain other components, and can have "slots" -- subtags whose contents are not part of the component. There is also the concept of "modes", which allows you to have different versions of a template for different system states (shopping cart empty vs. non-empty) that radically affect presentation. > This could potentially be a "killer feature" for web designers. Yep :-) 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] Adding functions to _
From: Itamar Shtull-Trauring <[EMAIL PROTECTED]>
> However, when I call the function, I get an error about DocumentTemplate,
> from which I discovered that when I call _.logvis('a_string'), instead of
> the string being passed as the first parameter, _ is passed as the first
> parameter to my function, forcing me to truncate it when calling log2vis:
> Any idea what could cause this strange behaviour? it doesn't happen for
> other functions inserted into _ in DT_Util.py.
When you stuff a function into "d", you're adding it to the class dictionary of
DocumentTemplate, so
it effectively becomes a method of that class. The first argument gets treated as
"self", just like
in any other class method.
All of the functions in DT_Util are either builtins (which never get turned into bound
methods) or
functions with a leading "self" parameter.
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: more __call__ ...
From: "Jim Fulton" <[EMAIL PROTECTED]> > > > We are going to provide an alternate interface, so that if > > > an object has a special method, then this will be called instead. > > > > okay... which proposal/project is this in? > > I don't remember. Evan? PythonMethods, essentially, unless you'd really like me to make this a separate project. It's *such* a small change, tho. 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] Re: more __call__ ...
From: Chris Withers <[EMAIL PROTECTED]> > Evan Simpson wrote: > > PythonMethods, essentially, unless you'd really like me to make this a > > separate project. It's *such* a small change, tho. > > No, not at all, just where I can find some docs for this specific bit > would be more than sufficient :-) http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/NamespaceObjectInterface ...has the details, such as they are. 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] Help, please!!! __call__ problems with DTML templates
From: Stephen Simmons <[EMAIL PROTECTED]>
> 1.) How do you magically get the DTML context from '' without
> having to resort to '' in the templates?
A.isDocTemp = 1 # or make it a shared class attribute
> 2.) How to convert an arbitrary text string into rendered DTML inside a
> python product method?
Here's what I use:
from Globals import HTML
from AccessControl import getSecurityManager
class DTML(HTML):
"""DTML objects are DocumentTemplate.HTML objects that allow
dynamic, temporary creation of restricted DTML."""
def __call__(self, client=None, REQUEST={}, RESPONSE=None, **kw):
"""Render the DTML given a client object, REQUEST mapping,
Response, and key word arguments."""
security=getSecurityManager()
security.addContext(self)
try:
return apply(HTML.__call__, (self, client, REQUEST), kw)
finally: security.removeContext(self)
def validate(self, inst, parent, name, value, md):
return getSecurityManager().validate(inst, parent, name, value)
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] BASEPATH
From: Brian Lloyd <[EMAIL PROTECTED]> > BASEPATHx (and its converse URLPATHx) are analogous to the > current BASEx and URLx variables of the REQUEST object, > except that they take any fiddling of the path (such as > that done by SiteAccess) into account. They will be > introduced in the next feature release (2.3). BASEx and > URLx will continue to work, but will be deprecated in > favor of the new BASEPATHx and URLPATHx. Whoa there! BASEPATHx and URLPATHx are the path portion of BASEx and URLx respectively. That is, if BASE1 == "http://www.foo.com/x/y/z" then BASEPATH1 == "/x/y/z". All of these take path manipulation into account. It's SCRIPT_NAME, REQUEST.script, and the various surgical contortions which try to extract the path part of URLs that are deprecated by these newcomers. Any place SCRIPT_NAME used to appear, it should be replaced with BASEPATH1. 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] SiteAccess + ZCatalog Project
Those of you who use SiteAccess, or any other virtual hosting solution, with ZCatalog (including Squishdot, ZUBB, and other ZCatalog-dependent products) should check out this new project: http://dev.zope.org/Wikis/DevSite/Projects/ZCatalogVirtualHostFix This proposes a set of changes and an upgrade path for ZCatalog to make it robust in the presence of virtual hosts. We really want to get this resolved, so this project won't be open for long. Contribute soon, if you can. 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] PythonMethods: Can't Slice context.REQUEST.PARENTS
From: The Doctor What <[EMAIL PROTECTED]> > Using context.this().id, self.this().id, m_self.this().id all get me > the same things: > Folder, Zope, and my method. None give me the DTML Document > foo_html. > > This would seem to be an important thing. The only information about your caller that you can get is the contents of their namespace. So, in the final release, you would be able to bind the caller's namespace to "_" and write _.this().id. That requires a change to Zope, though, so it doesn't work yet. You *could* work around this by explicitly passing the namespace (or this(), for that matter). 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] Aquisition: who know how it does?
From: Coi Giovanni <[EMAIL PROTECTED]> > Why the acquisition get (correctly) Folder1/Folder2/img2 and the get (???) > Folder1/doc_include_html instead of Folder1/Folder2/doc_include_html ? Your index_html is a DTML Document, right? Make it a DTML Method and all should work as you expect, since Methods operate as though they are contained where they are found. Documents don't, and acquisition searches the direct path to the root before anything else. When you write DTML that you plan to acquire, you almost always want to use DTML Methods. 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] PythonMethods: Can't Slice context.REQUEST.PARENTS
From: "Dieter Maurer" <[EMAIL PROTECTED]> > > The only information about your caller that you can get is > > the contents of their namespace. So, in the final release, > > you would be able to bind the caller's namespace to "_" and > > write _.this().id. That requires a change to Zope, though, > > so it doesn't work yet. You *could* work around this by > > explicitly passing the namespace (or this(), for that > > matter). > Why can't I get the acquisition context as with External Methods? > (if they are called directly via the Web, namespaces are not > yet build and the acquisition context obtained via a "self" > parameter is everything I have). I don't understand. If the method is called directly via the Web, "context" *is* your acquisition context, and there is no caller to get information about. 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: [Zope] IE5 / Medusa bug?
From: seb bacon <[EMAIL PROTECTED]> > I imagine the fact that I can make it work by adding index_html is the > most telling point, but it's not telling me anything ;) Leaving off index_html causes Zope to add a to the head. That's the only difference I can think of. Your page doesn't get cut short in my IE 5.00.2314.1003 (128 bit encryption). 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] urllib not available in Python Scripts?
From: Itai Tavor <[EMAIL PROTECTED]> > In Python Methods I could do urllib.quote(...). This doesn't work in > Python Scripts. Is quote considered a security risk? No, but only the modules available to DTML are importable by default. You would need to provide security declarations in order to import anything from urllib. 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] A couple of possible Python Scripts bugs
From: Itai Tavor <[EMAIL PROTECTED]>
> First, when trying to add a Python Script, I sometimes get:
>
> Error Type: AttributeError
> Error Value: tx
Thanks! Fixed in CVS.
> return container.domains
>
> returns AttributeError.
>
> This does not occur if I try to read a property on the first
> propertysheet in the ZClass. Also, getProperty('domains') works in
> the Python Script. And this Python Script:
Sorry, I can't replicate this on Zope 2.3 alpha 1.
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] Re: [Zope] IE5 / Medusa bug?
From: seb bacon <[EMAIL PROTECTED]>
> As Martijn correctly pointed out, there seems to be a Content-length
> problem going on here. I did a lot more tests on two different 2.2
> servers, and have come closer to isolating the bug.
It's a ZPublisher/HTTPResponse.py bug. When you render a Folder, it inserts
the and adjusts the content-length. When the RESPONSE is
rendered, it notices that the is missing and tries to fix your HTML
(adding precisely 14 bytes), but doesn't bother to re-adjust the
content-length.
I've fixed this in CVS by removing the code that attempts to fix HTML, since
that is *wrong* behavior. You can do the same by removing the following
lines:
else:
isHTML = split(headers.get('content-type', ''),
';')[0] == 'text/html'
if isHTML and end_of_header_search(self.body) < 0:
lhtml=html_search(body)
if lhtml >= 0:
lhtml=lhtml+6
body='%s\n%s' % (body[:lhtml],body[lhtml:])
elif contHTML:
body='\n' + body
else:
body='\n' + body + '\n\n'
self.setBody(body)
body=self.body
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] urllib not available in Python Scripts?
From: "Itai Tavor" <[EMAIL PROTECTED]>
> The reason I could do urllib.quote in Python Methods was that I
> implemented the MoreBuiltins trick someone described here a while
> ago.
That would be me :-)
> Is there anything that can be done so that adding modules continues
> to work?
Sure. Since you've already got a MoreBuiltins module, that's probably a
fine place to put this. In MoreBuiltins/__init__.py (or a brand new Product
directory of your choice) put the following lines:
import urllib
urllib.__allow_access_to_unprotected_subobjects__ = 1
...and similarly if you want to declare other modules PS-importable. As of
2.3, the proper way to do this will be:
from AccessControl import ModuleSecurityInfo
ModuleSecurityInfo('urllib').setDefaultAccess(1)
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] urllib not available in Python Scripts?
From: "Itai Tavor" <[EMAIL PROTECTED]>
> > import urllib
> > urllib.__allow_access_to_unprotected_subobjects__ = 1
> Ok, this is simple enough, and it works. But... it opens access to
> everything in urllib.
For now, the best way is to use a dictionary of names, like this:
import urllib
urllib.__allow_access_to_unprotected_subobjects__ = {
'quote': 1, 'unquote': 1,
}
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] Changing hostname and port without SiteAccess
From: Martin Winkler <[EMAIL PROTECTED]> > I cannot use SiteAccess (because I need multiple ZCatalogs) To the extent that you can't use SiteAccess with ZCatalogs, you will also not be able to use any other solution (until ZCatalogs are fixed, hopefully in 2.3). The problem with ZCatalogs is not SiteAccess-specific, it is with virtual hosting in general. 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] Product Authors: If you use ZCatalog, READ! (that means you, Chris W. :-)
From: The Doctor What <[EMAIL PROTECTED]> > I would happy to, it looks like it does what I need (having > siteaccess). However, I don't see a clear cut description what's > changing and how. What needs to be done (in easy to understand > language) to make sure it all goes smooth, etc. It's one step off the link given before, and really the one page you need to read: http://dev.zope.org/Wikis/DevSite/Projects/ZCatalogVirtualHostFix/UpgradeFAQ > It's a big update, with lots of files. Will this work with 2.2.4? > Is it dangerous? If you're asking for guinea pigs (bweep!) then I'm > not sure I should be it, as I'm still trying to figure out what's > going on in many ways. If you run a copy of your site on this code, it will be evident immediately whether you have problems or not. If that's hard to do, you may want to at least set up a mini-site and export some test data to it. Authors of Products that use ZCatalog: PLEASE give feedback and try to document any problems or workarounds for your Product on the AffectedProducts page (linked from UpgradeFAQ in several places). 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] Import with INSTANCE_HOME?
From: BS <[EMAIL PROTECTED]> > Can anyone tell me how to do a "from Products.ZPatterns import anything" > when using INSTANCE_HOME? > Do I have to add the INSTANCE_HOME path to sys.path? As long as Python has already imported Zope (i.e. you're in another Product) you don't need to do anything special. All Product directories' contents can be imported with "import Products.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 )
[Zope-dev] Re: [Zope] Lobbying (was: [Zope] html_quote in python methods?)
From: Chris Withers <[EMAIL PROTECTED]>
> > Only if you add security declarations to expose functionality from
> > xmlrpclib.
>
> Is that hacky and nasty? :-S
In Zope 2.3, you place the following code somewhere that it will get
executed at startup (a custom Product's __init__ is the best bet):
from AccessControl import ModuleSecurityInfo
security = ModuleSecurityInfo('xmlrpclib')
security.declarePublic('Server')
# or security.setDefaultAccess(1), if you feel lucky.
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] Python Scripts update
Python Scripts have gone through a fair number of changes and bugfixes recently. They should now work properly as methods of ZClasses. When you download the source of a Python Script, the title, parameter list, and bindings are added to the source in the form of specially formatted comments. If source with these comments is uploaded or pasted into a Python Script, it will properly set the properties mentioned in the comment block. The default bindings have been changed to be more sensible. If you want to give Python Scripts a try, you can go to http://ps.4-am.com:9000/ , pick a password, and you'll get your own private area in a trunk CVS checkout of Zope in which to play. I promised examples when I first announced this site, and haven't gotten around to writing any. If you have created a script or set of objects on the demo site that you would like to share as an example, please mail me the URL. 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-dev] ProxyPass and SiteAccess getting REMOTE_ADDR
From: "Chris Withers" <[EMAIL PROTECTED]> > We're actually phasing this hack out in favour of a Virtual Host Monster which > seems like a much cleaner solution... Sorry, Chris, VHM is irrelevent to this problem. If you want to know the original remote IP, you have two choices: 1. Use one of the Apache patches that have been posted. 2. Mangle it into URLs and extract it with an AccessRule. Neither one of these is really satisfactory at the moment, since medusa doesn't know either solution, and so z2.log doesn't get the proper IP addresses. I'm hoping that one of these days we can standardize on #1 and provide support in medusa. 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] 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] 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] 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] TransWarp preview release (AOP tools only)
From: Shane Hathaway <[EMAIL PROTECTED]> > I don't see how persistent modules can work unless they are highly > restricted. The idea is that modules would be "executed" only once then > the result of that execution would be stored in the ZODB. Alternatively, you compile the module and store the marshalled code, and you execute it in a special environment every time the Module object is loaded. 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] 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] 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] 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 )
[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 developers in which the programming and page/site design tasks are handled by separate people.  Cheers,  Evan @ digicool
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 )
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: 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 )
[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 )
[Zope-dev] Ann: ZPT and TAL 1.1.0 released
Several bug fixes and a few minor features later, ZPT and TAL 1.1.0 are ready. See http://dev.zope.org/Wikis/DevSite/Projects/ZPT for more information. 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] 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 )
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] 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] 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: [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] 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: 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] 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 )
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 )
[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 > ) 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 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] 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 )
[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: 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:
...produces:
arg
3.40
My Title
My Title
foo
skeleton
yes
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: 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
Jim Penny wrote:
And why would I expect a ZPT person to have a basic knowledge of data
structures?
In my view, this whole idea is primarily aimed at programmers. I fully
expect that non-programmer ZPT people will be able to ignore this stuff,
apart from being handed a small set of idioms by the programmer. Paths
that can make use of these features are going to be constructed by
programmers, and used as black boxes by ZPT people.
The driving rationale behind most of the prefixes that I implemented is
to provide explicit spellings for things that have bitten myself and
other programmers in practice. 'key', 'item', and 'attr' let us specify
access methods when traversal magic fails (eg. method names clashing
with keys, no way to access sequence items), and 'call' lets us traverse
through simple data-access methods. 'var' is just a less-cryptic
version of '?'-prefixed path elements.
Several of your objections/suggestions involve the distinction between a
string and a name, as in:
x/index:'foo' --> x['foo']
x/index:span_of_int ->x[span_of_int]
x/index:foo--> x[foo]
I'd rather not introduce additional punctuation (quotes or parens) if I
can help it -- TAL and TALES both have a tradition of minimalist syntax,
and it keeps parsing simple. Also, as soon as you add delimiters, you
add quoting issues, and TALES has enough of those already.
call: well, you have said that arguments are allowed, and must be only
variable names. What is the reason for this?
To keep things simple. There's a clearly visible slippery slope here,
and I hope to stay off of it, since it leads to full-on Python in the
middle of a path, which would be a nightmare. Names-only takes care of
the most common case, while allowing for dead-simple parsing
(arg.split(',') then validate each name).
Does using call: explicitly erase all magic name bindings (I hope so)?
I don't know what you mean, here.
fmt: is most irregular. First, it reverses the pattern of all the
others and makes the stuff to the left the parameter. This may be OK
for your intended audience. It may also confuse them totally. Why
x/fmt:%.2f and not x/fmt:'%.2f'? As it stands, it takes either
expression fragments starting with % or function names. Can I define my
own functions, if so, how/where?
'fmt' is a quick-and-dirty implementation, and most likely to change.
It was almost certainly a mistake to conflate the standard formatting
functions with Python string formatting. I don't agree that it reverses
the pattern, though -- to me, it's "apply *this* formatting operation to
the current object", much like 'key' is "fetch *this* key from the
current object".
One of my to-do's on this idea is syntax allowing prefix strings to be
associated with an implementation within a template, possibly overriding
the default associations. In particular, this would allow you to make a
prefix for a collection of your own functions.
Finally, can we come up with a better term than prefix. In conventional
terminology, most of these are infix operations, except call, which may
be a purely postfix.
'prefix' refers to the syntax, not the operations. In my source code
comments, I refer to "prefixed path elements". A better name would be
welcome :-)
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
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] 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: PythonLibraries Product
Seb Bacon wrote: So AFAICT it's a convenience which allows you (a) to keep related functions together; and (b) to store local variables in a convenient place. It definitely sounds useful but also a lot of work for something it's possible to manage without quite easily at the moment..? Could you provide a brief summary of why this is better than a folder of python scripts? Perhaps a use case which illustrates the problems of the current way of doing things? It isn't *better* than a Folder of Scripts, it's *different* :-) I have two weak use-cases, a longstanding "I'm going to write that some day" itch, and some aesthetic arguments. One of the more frequently stated complaints about ZPTs is that to properly remove non-presentation logic and ugly little Python expressions from a template, you either need a pile of little Scripts, or a single "controller" Script that precalculates everything and passes it to the template. I've settled, fairly happily, on the second solution. Both of these solutions suffer from the "two or more objects to accomplish one task" management problem. I usually combine the objects in a dedicated Folder, which is still a bit awkward, and doesn't solve everything. One drawback is that the individual components are all published, despite the fact that I only intend one of them to be web-addressable. It would be very handy to attach the Scripts directly to the template, but the straightforward way of doing that means making the template a container, and opens a whole can of worms. Instead, what if templates had a Library tab, and it worked with External Editor? It would actually be easier to *just* write this, and not have independent Library objects, but generalizing this capability feels right to me. From an aesthetic viewpoint, a Library looks and works more like regular Python than a Script. Even though a Library is not a "*.py" file, it uses a subset of that syntax, so dedicated editor modes will like it better. Multi-line triple-quoted strings will not get extra spaces added to them. The "##" header hack won't be necessary, so line numbers in External Editor will match error message line numbers. On the other hand, Libraries don't support 'traverse_subpath', require an extra path step to address, and don't allow permission and proxy settings at individual function granularity. 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] 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 )
[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: 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: 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 )
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]
Yuppie wrote: Today I built Zope 2.7 from a new checkout. And all icons in the ZMI are broken :-( They have src paths starting with // Argh. A bug in my refactoring of the tests made them all pass without really testing. I *think* it's fixed now. Sorry, 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 )
[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: 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: 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)')
> (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: bug in 2.6.2, 2.6.1 , and probably others.
Romain Slootmaekers wrote: I just stumbled on a bug in the python scripting parameter passing. Actually, it's a bug in the "test" tab support code. The parameter fields in the form are set to "a ", "b ", and "c " instead of "a", "b", and "c". I'm fixing it in CVS for 2.7. Normal parameter passing is unaffected. 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 )
