Re: [Zope-dev] No feedback for SOAP patch ?

2000-06-23 Thread Evan Simpson

- 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?

2000-06-23 Thread Evan Simpson

- 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__?

2000-06-25 Thread Evan Simpson

- 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__?

2000-06-25 Thread Evan Simpson

- 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?

2000-07-10 Thread Evan Simpson

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

2000-07-20 Thread Evan Simpson

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

2000-07-31 Thread Evan Simpson

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

2000-08-01 Thread Evan Simpson

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

2000-08-02 Thread Evan Simpson

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

2000-08-08 Thread Evan Simpson

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

2000-08-14 Thread Evan Simpson

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 ;-)

2000-08-17 Thread Evan Simpson

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

2000-08-17 Thread Evan Simpson

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

2000-08-18 Thread Evan Simpson

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

2000-08-30 Thread Evan Simpson

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

2000-09-05 Thread Evan Simpson

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

2000-09-05 Thread Evan Simpson

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 ?

2000-09-09 Thread Evan Simpson

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?

2000-09-11 Thread Evan Simpson

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

2000-09-18 Thread Evan Simpson

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 _

2000-09-18 Thread Evan Simpson

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__ ...

2000-09-26 Thread Evan Simpson

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__ ...

2000-09-26 Thread Evan Simpson

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

2000-10-10 Thread Evan Simpson

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

2000-11-03 Thread Evan Simpson

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

2000-11-07 Thread Evan Simpson

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

2000-11-13 Thread Evan Simpson

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?

2000-11-13 Thread Evan Simpson

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

2000-11-14 Thread Evan Simpson

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?

2000-12-14 Thread Evan Simpson

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?

2000-12-15 Thread Evan Simpson

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

2000-12-15 Thread Evan Simpson

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?

2000-12-15 Thread Evan Simpson

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?

2000-12-16 Thread Evan Simpson

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?

2000-12-17 Thread Evan Simpson

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

2000-12-18 Thread Evan Simpson

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. :-)

2000-12-18 Thread Evan Simpson

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?

2001-01-03 Thread Evan Simpson

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?)

2001-01-04 Thread Evan Simpson

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

2001-01-04 Thread Evan Simpson

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

2001-02-04 Thread Evan Simpson

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

2001-02-13 Thread Evan Simpson

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

2001-02-13 Thread Evan Simpson

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

2001-02-13 Thread Evan Simpson

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__

2001-02-19 Thread Evan Simpson

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__

2001-02-19 Thread Evan Simpson

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

2001-02-20 Thread Evan Simpson

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

2001-02-20 Thread Evan Simpson

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

2001-02-20 Thread Evan Simpson

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

2001-02-28 Thread Evan Simpson

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)

2001-03-02 Thread Evan Simpson

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?

2001-03-03 Thread Evan Simpson

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

2001-03-16 Thread Evan Simpson

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?

2001-03-16 Thread Evan Simpson

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

2001-03-21 Thread Evan Simpson

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

2001-03-27 Thread Evan Simpson



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

2001-04-01 Thread Evan Simpson

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?

2001-04-02 Thread Evan Simpson

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?

2001-04-03 Thread Evan Simpson

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

2001-04-10 Thread Evan Simpson

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

2001-04-10 Thread Evan Simpson

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

2001-04-11 Thread Evan Simpson

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

2001-04-12 Thread Evan Simpson

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

2001-04-27 Thread Evan Simpson

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

2001-04-29 Thread Evan Simpson

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

2001-05-07 Thread Evan Simpson

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

2001-05-11 Thread Evan Simpson

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

2001-05-31 Thread Evan Simpson

> - 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

2001-06-08 Thread Evan Simpson

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)

2001-06-13 Thread Evan Simpson

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?

2001-06-15 Thread Evan Simpson

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?

2001-06-18 Thread Evan Simpson

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)

2001-06-14 Thread Evan Simpson

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

2001-07-01 Thread Evan Simpson

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

2003-07-23 Thread Evan Simpson
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

2003-07-29 Thread Evan Simpson
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

2003-07-29 Thread Evan Simpson
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

2003-07-30 Thread Evan Simpson
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)

2003-07-30 Thread Evan Simpson
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)

2003-07-30 Thread Evan Simpson
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

2003-07-30 Thread Evan Simpson
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

2003-07-31 Thread Evan Simpson
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

2003-09-08 Thread Evan Simpson
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

2003-09-10 Thread Evan Simpson
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

2003-09-11 Thread Evan Simpson
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?

2003-09-11 Thread Evan Simpson
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

2003-09-22 Thread Evan Simpson
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

2003-09-22 Thread Evan Simpson
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

2003-12-03 Thread Evan Simpson
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

2003-12-03 Thread Evan Simpson
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

2003-12-07 Thread Evan Simpson
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]

2003-12-09 Thread Evan Simpson
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]

2003-12-10 Thread Evan Simpson
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]

2003-12-11 Thread Evan Simpson
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....

2003-12-15 Thread Evan Simpson
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

2004-01-02 Thread Evan Simpson
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

2004-01-21 Thread Evan Simpson
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

2004-02-03 Thread Evan Simpson
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

2004-02-03 Thread Evan Simpson
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.

2004-02-03 Thread Evan Simpson
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 )


  1   2   >