[Zope-dev] DateTime iso8601 bad handling of dates

2005-11-30 Thread Evan Simpson
This has been brought up and (rather cavalierly) dismissed before.  I
challenge anyone to justify the following DateTime behavior:

 DateTime('2005-01-01').strftime('%Y-%m-%d')
'2004-12-31'

DateTimes are actually timestamps, and the current implementation
assumes that a date in ISO8601 format without a timezone specifier is
UTC rather than local.

It was asserted, last time this came up, that this is compliant with the
ISO8601 spec, but my own research shows this to be false.  If someone
can point me to a truly authoritative source that supports the current
behavior, I would appreciate it, but that would not change the fact that
the manifested behavior is *broken*.

This is a simple two-line fix, folks.  I've already done it on my
production systems.

Cheers,

Evan @ 4-am

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: ZPT: defer expression fix

2005-04-04 Thread Evan Simpson
Christian Heimes wrote:
That's an interessting use case. Do you want me to keep the code and 
make up a new expression? I'm thinking about lazy:.
If you have a particular use for defer: that would justify the split, 
please go ahead.  I have no particular interest in keeping it.

Cheers,
Evan @ 4-am
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: ZPT: defer expression fix

2005-04-01 Thread Evan Simpson
Christian Heimes wrote:
 * DeferWrapper didn't cache the result of the expression like ordinary 
vars do.
This was intended, though you couldn't know that since I never 
documented this.  Consider the following terrible example:

div tal:define=xis defer:string:x is $x
  p tal:repeat=x python:range(3)
 tal:content=xis/p
/div
This should evaluate to:
div
  px is 0/p
  px is 1/p
  px is 2/p
/div
Why??  I don't remember why I wanted this behavior; it was an 
experiment, and I can't find any code of mine that uses it.

Cheers,
Evan @ 4-am
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] ZopeGuards iterator problems

2005-01-07 Thread Evan Simpson
I just created issue #1656 and checked in a fix, so looping over 
enumerate(xrange(9)) is now possible, among other things.

Should we add entries for the various iterator types to the security 
machinery so that iterators returned by the itertools module can be used 
without lots of tedious wrapping?

Cheers,
Evan @ 4-am
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Conditional imports in ZTUtils/__init__.py

2004-10-05 Thread Evan Simpson
Stefan H. Holek wrote:
ZTUtils/__init__.py contains code like this:
  if sys.modules.has_key('Zope'):
  # import things
This is causing me repeated headaches when writing tests, because it 
assumes/dictates a certain module import order. Can this go away, 
please? I mean we know we are running Zope, don't we?
This is part of my attempt to allow the various bits of ZPT to work 
outside of Zope.  It assumes that the presence of the 'Zope' module is a 
reliable test.  Perhaps this is a YAGNI, or perhaps there's a better way 
of accomodating non-Zope users.

Cheers,
Evan @ 4-am
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: [ZPT] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-28 Thread Evan Simpson
Jim Fulton wrote:
Given that, I still prefer context#dc to context/##dc.
+1
I like the idea that '/' and '#' are both path separators, and that the 
semantics of each path segment depend on the preceding separator.

Cheers,
Evan
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: [Zope3-dev] Re: Re: RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-27 Thread Evan Simpson
Jim Fulton wrote:
IMO, if we take this route, we should think of the notation as
providing an alternate traversal operator.  That is, there is
syntax that either modifies or replaces /, so of the examples
above, only:
 context/*dc/title
In that case, I'd be happy to consider adaptation as orthogonal to my 
path prefixes.  Might as well drop the slash and go with the previous 
suggestion:

context*dc/title
I can easily read the star as an adaptation operator, even with multiple 
applications.

Cheers,
Evan
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-21 Thread Evan Simpson
Jim Fulton wrote:
One disadvantage I see with the cast notation is that it's
a bit jarring in:
  a/b/(adapter)c/d
as the adapter is applied to a/b/c. The order just doesn't
seem quite right.
Unless I'm misunderstanding something fundamental here, in the TALES 
context an adapter is essentially a function accepting a single 
argument.  The adapted object that results from applying the adapter 
function is either used directly or further traversed.  All of the other 
qualities that make up an Adapter (how it's registered, that it supports 
ITALESAdapter, etc.) are irrelevant to its use in a TALES expression.

Given all that, why do we need to shoehorn the adapter's name into the 
same path segment as one of the traversal names?  The above looks much 
more natural to me as one of:

a/b/c/(adapter)/d
a/b/c/*adapter/d
a/b/c/adapter()/d
a/b/c/adapter:/d
Note that the latter two forms allow for additional arguments.  While 
not applicable to single-argument adapters, this is certainly a useful 
feature if we don't restrict the syntax to adapters only.  In 
particular, evan-pathprefix-branch uses the colon syntax to allow 
applications such as a/b/c/index:2/d and a/b/c/call:x,y/d.  This 
same scheme can easily subsume adapters in either or both of two ways: 
adapter as prefix, and adapter name as argument to a prefix.

tal:define=prefix foobar adapter:foo.bar
tal:content=a/b/c/foobar:/d
...or...
tal:define=prefix A builtin:adapters
tal:content=a/b/c/A:foo.bar/d
Cheers,
Evan @ 4-am
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-20 Thread Evan Simpson
Jim Fulton wrote:
I thought you had proposed this, but I couldn't find a proposal
or documentation.
You say this is implemented in Zope 2? Where is it documented?
Actually, it's only implemented on evan-pathprefix-branch.  It has been 
quite a while since I had a chance to work on it, so I had forgotten 
that it was never merged, or properly documented for that matter. 
Pretty much all the information about it that isn't in the source code 
is in the ZPT list archives from August and September (e.g. 
http://mail.zope.org/pipermail/zpt/2003-August/004902.html)  So, no 
worries if you decide to take a completely different direction -- it was 
never released.

Cheers,
Evan
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-20 Thread Evan Simpson
Jim Fulton wrote:
I don't inderstand what motivated the special expression types for this
namespace.  For example, to get at file-system based code, couldn't you 
have used the modules variable?
I started there, but went with the special expression types because the 
set of things that are valid to define as prefixes is completely 
disjoint from those that you would use in other TAL statements.  I've 
grown wary of tying abstract object names to Python package and module 
structure.  Also, while I find it difficult to describe precisely, I 
have a strong intuition that arbitrary objects should not be available 
for use as prefixes.

Of course, the idea of prefixes as Zope 3 adapters intead of custom-made 
prefix implementations may change things.

Cheers,
Evan @ 4-am
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-19 Thread Evan Simpson
Jim Fulton wrote:
I've posted two proposals:
  http://dev.zope.org/Zope3/TALESPathExpressionAdapters
Proposes a mechanism for easily using adapters in TALES expressions.
I'm not at all clear on how the proposed mechanism is superior to the 
implementation of path segment prefixes that exists in Zope 2.  This 
differs from the namespace proposal that you cite, in that the object 
named on the left of the colon is not a namespace or adapter.  It is 
simply a registered name that is associated with code that interprets 
the text to the right of the colon.  This allows constuctions such as 
a/sequence/index:2 (a.sequence[2]), a/bag/var:x/call: (a.bag[x]()), 
and an/object/adapt:foo.bar (foo.bar(an.object)).

  http://dev.zope.org/Zope3/ZPTVariableNamespaces
proposes a mechanism for qualifying names defined in TAL and used in
TALES expressions.
This would of course conflict with prefixes as currently defined, and 
seems weakly motivated.  I can imagine getting a similar effect with a 
more consistent syntax by allowing tal:define=x/y foo when x supports 
an ITALESNamespace interface.  The path x/y/z then does exactly what 
the user would expect.  A namespace x can be created without any new 
TAL syntax by providing a built-in constructor, as in tal:define=x 
namespace, that creates an empty dictionary-like object with support 
with ITALESNamespace.

Cheers,
Evan @ 4-am
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] test.py

2004-03-10 Thread Evan Simpson
Jeremy Hylton wrote:
Make sure App.Product is imported first, so that test.py can work.

This change does not affect the old utilities/testrunner.py.
This checkin message caused me to notice 'test.py' for the first time. 
Can you point me to any discussion/docs on it?  When did/will it replace 
testrunner?  Shouldn't the python2.2 in the #! line be python2.3?

Sorry for the flood of questions, but this and the recent doctest-style 
tests being checked in have made me wonder if I've been missing a 
significant shift in testing tech.

Cheers,

Evan @ 4-am

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Zope 2.8

2004-02-20 Thread Evan Simpson
Christian Theune wrote:
- Does a proposal for the post-traverse-hook have a chance for 2.8? (The
code is here completely working on 2.7, I only need to write tests.)
Please, write tests and merge to the HEAD.  I see no reason why this 
shouldn't go into 2.8.

Cheers,

Evan @ 4-am



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] TypeErrors during 'make test'

2004-02-13 Thread Evan Simpson
I'm getting several TypeErrors when I run 'make test' on the HEAD.  Each 
of them involves a call to cAccessControl's 'validate' with 'roles' set 
to a PermissionRole instance, complaining that it's not iterable.

Any ideas?

Cheers,

Evan @ 4-am



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Zope 2.7.0 rc2 + python 2.3.3 problem

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)')
 string(1)?()
(Pdb) s
--Call--
 /usr/lib/python2.3/warnings.py(24)warn()
- def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: tp_compare didn't return 
-1 or -2 for exception
  i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating exceptions.

Cheers,

Evan @ 4-am

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: 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 )


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


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


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


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


[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: 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] 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-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:

div tal:define=foo string:*foo*;
 seq python:('arg', 3.4);
 map python:{'*foo*': 'yes', 'keys': 'skeleton'}
  div tal:content=seq/item:0/div
  div tal:content=seq/item:1/fmt:%.2f/div
  div tal:content=template/attr:title/div
  div tal:content=here/key:test3/title/div
  div tal:content=structure foo/fmt:structured_text/div
  div tal:content=map/key:keys/div
  div tal:content=map/var:foo/div
/div
...produces:

div
  divarg/div
  div3.40/div
  divMy Title/div
  divMy Title/div
  divpemfoo/em/p
/div
  divskeleton/div
  divyes/div
/div
You can try it out with the following commands in your 
$ZOPE/lib/python/Products/PageTemplates/ directory:

cvs -q up -r evan-pathprefix-branch PathPrefixes.py
cvs diff -r evan-pathprefix-branch-0 -r evan-pathprefix-branch \
  -u Expressions.py | patch
Cheers,

Evan @ 4-am

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: TALES idea: tuple unpacking

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-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: weak examples, weak exploits

2003-06-24 Thread Evan Simpson
Shane Hathaway wrote:
This seems like a fine idea, but what action would the user take to 
install examples and extras?
In my initial implementation, there was a separate page that listed the 
names and descriptions of the various examples, with links to install 
them.  If I recall correctly, this page was reached from a link on 
Folder views, much like the current Help link.  Also linking from the 
Quick Start sounds like a fine idea.

Cheers,

Evan @ 4-am

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: weak examples, weak exploits

2003-06-23 Thread Evan Simpson
Casey Duncan wrote:
I would be in favor of making the Examples opt-in like the Zope tutorial. It 
seems silly to have it in evey ZODB by default. Make people add it if they 
want it.
Many, many moons ago I created evan-examples-branch, which allows 
individual Products to offer sample code without (magically or 
otherwise) forcing them upon the user.  I'd love to see it revived, 
perhaps as Examples/Optional Extras in order to cover the Hurt system 
as well.

The basic idea is to look for an XML manifest file 'examples/index.xml' 
in each Product.  It probably wouldn't be very hard to use ZConfig 
instead of XML.  Here is the PageTemplates index.xml:

example name=Assorted Examples
  description
This is a set of examples of the use of page templates.
It includes examples of batching, macros, and trees.
  /description
  payload
import file=zpt_examples.zexp/
  /payload
  view url=zpt_examples/
/example
!-- This file can contain any number of examples.

Each one consists of an example with a 'name' attribute,
containing exactly one description.  The name and description
are displayed in the Examples page.  description can have a
'format' attribute set to 'plain' (the default), 'stx' (structured
text), or 'html'.
An example can contain payload elements.  Each payload can
contain any number of import, execute, and call elements.
These are processed in order when an example is selected from the
Examples page.  import must have a 'file' attribute that names
a file in the 'examples' directory to be imported.  execute must
have a 'file' attribute that names a file to be run with execfile.
call must have a 'path' attribute that gives the path to a Zope
object to be called.
An example can contain at most one view element.  The 'url'
attribute of a view is the URL to view after all payload elements have
been processed. This URL can be relative to the current folder.
--

Cheers,

Evan @ 4-am

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Post-authentication hook

2003-06-10 Thread Evan Simpson
Dieter Maurer wrote:
We had discussed the post-authentication hook in connection
with role based skin selection but we never had it implemented.
I have, and it even fits here in the margin.  Shall I pop it into the 
Collector?

242a243
 self._post_traverse = post_traverse = []
363a365
 del self._post_traverse
434a437,439
 if post_traverse:
 exec_callables(post_traverse)

444a450,453
 def post_traverse(self, f, args):
 Set a callable object and argument tuple
to be combined if traversal succeeds
 self._post_traverse.append((f, tuple(args)))
445a455,470
 def exec_callables(callables):
 for (f, args) in callables:
 try:
 f(*args)
 except (ArithmeticError, AttributeError, FloatingPointError,
 IOError, ImportError, IndexError, KeyError,
 OSError, OverflowError, TypeError, ValueError,
 ZeroDivisionError):
 # Only catch exceptions likely to be logic errors.
 # We shouldn't catch Redirects, Unauthorizeds, etc. since
 # the programmer may want to raise them deliberately.
 from zLOG import LOG, ERROR
 import sys
 LOG('PostTraverse', ERROR,
 'Error while invoking hook: %s' % `f`,
 error=sys.exc_info())
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Post-authentication hook

2003-06-10 Thread Evan Simpson
robert wrote:
Please do
Okeydoke: it's Issue #935.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: [Zope] Re: Proposed installation changes for review

2003-03-11 Thread Evan Simpson
Guido van Rossum wrote:
Well, in a typical installation, you won't be running ZEO on the same
machine as Zope, right?  ZEO has its own install and config stuff,
which is very similar to that for Zope, but ZEO is not installed as
part of the main Zope install.
I routinely run ZEO on all of my sites, on the same machine.  I don't 
gain any scalability benefits this way, but it is fantastic for 
debugging and tweaking a live site.

My creaky old zctl.py auto-starts ZEO when necessary, using the same 
configuration data as it uses for the associated Zope instance, so they 
 both know to use 'var/zeo.soc' to connect.

Cheers,

Evan @ 4-am

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: [Vote] PEP308 voting began

2003-03-04 Thread Evan Simpson
Guido van Rossum wrote:
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python.  If you can have a
not:.. expression, surely you can have an if:..:then:..:else:..
expression.
Now that you point it out, it's not even hard.  Here's a 
proof-of-concept, with really awful parsing (it obviously breaks on 
nested if: then: else:), that actually works:

class IfExpr:
def __init__(self, name, expr, compiler):
self._s = expr = expr.lstrip()
m = re.match('(.*) then:(.*) else:(.*)', expr)
if m is not None:
condexpr, thenexpr, elseexpr = m.groups()
self._cond = compiler.compile(condexpr)
self._then = compiler.compile(thenexpr)
self._else = compiler.compile(elseexpr)
def __call__(self, econtext):
if econtext.evaluateBoolean(self._cond):
return econtext.evaluate(self._then)
return econtext.evaluate(self._else)
(Tested with
div tal:replace=if:options/x then:string:yes else:string:no)
Is this worth a robust implementation, ZPT folks?

Cheers,

Evan @ 4-am

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Infuriating ZClass registry Heisenbug

2002-12-16 Thread Evan Simpson
My trunk and 2.6 sandboxes are now behaving themselves.  Thanks, guys!


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Infuriating ZClass registry Heisenbug

2002-12-11 Thread Evan Simpson
Shane Hathaway wrote:

Shot in the dark #2: Does it enter the ClassFactory function in 
Zope.ClassFactory?  That's part of the ZClass magic... although there 
are two ways that the pickler tries to load classes.  ZODB only tries to 
load Persistent instances as ZClasses.  If there are things inside the 
pickles that are not Persistent, yet come from a ZClass, ZODB will not 
treat them kindly.

As far as I can tell, it doesn't enter *any* Python code.  Unless 
there's some other reason for pdb to be unable to step into it, it seems 
to execute only C code right up to the ImportError.  By contrast, I 
*was* able to trace through ClassFactory when it loaded the BTree -- the 
trace would then fail when loading the first Bucket.  Apparently small 
OOBTrees store their state differently, because the trace fails on the 
OOBTree load now, and I can do unpickler.noload() and see the state 
tuple with all the keys and None where the ZClasses should be.

Shot in the dark #3: Unfortunately, there's one bit of ZODB that I still 
don't fully understand, and that's setklassstate().  You might be 
running into this somehow.  I'd hazard a guess that the latest 
cPickleCache does not do the right thing with setklassstate(), since no 
one has committed to maintain that part.  Ugh, we need unit tests for that.

I had never heard of it -- I'll have to take a peek.


Here's a simple suggestion: after loading the site and browsing a few 
pages involving ZClasses, flush the ZODB cache and see if the bug 
appears right away.  If so, it's probably occurring as a result of 
deactivation.

I had pretty much been assuming that that was the case, but performing 
this test confirms it.  Flushing the cache breaks things immediately.



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Infuriating ZClass registry Heisenbug

2002-12-11 Thread Evan Simpson
More data:

It may well be loading correctly, but it seems to be storing 
incorrectly.  I managed to grab the ZGlobals pickle string, and it has 
the _zclass_ stored as a plain class instead of an oid.

I copied the commented-out Python persistent_id() in ZODB/Connections.py 
into a method called test_persistent_id(), and compared its results with 
coptimizations' new_persistent_id.  They matched for everything except 
_zclass_ objects, for which test_persistent_id returned the _p_oid and 
new_persistent_id returned None.  I have no idea why this is.  It would 
explain why the _zclass_es are stored wrongly, but not why everyone else 
isn't seeing major breakage.

Argh,

Evan @ 4-am


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Infuriating ZClass registry Heisenbug

2002-12-11 Thread Evan Simpson
I think I've fixed my ZGlobals, but there's definitely a problem in 
coptimizations.  I made Connections.py use the Python persistent_id, 
restarted twice, and ZGlobals was fine on the second restart.

Whew,

Evan @ 4-am


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


[Zope-dev] Infuriating ZClass registry Heisenbug

2002-12-10 Thread Evan Simpson
This past weekend I migrated a bunch of ZClasses and the web site that 
uses them from a scratch Zope instance into my production instance. 
Both run off the same 2.6 CVS branch checkout, connecting to ZEO servers 
running from the same ZEO trunk checkout.

For a while after starting the server, everything works fine.  After an 
unpredictable time period ranging from minutes to hours, suddenly my 
ZClass instances become broken, and I start seeing this in my log, over 
and over:

2002-12-10T11:33:18 ERROR(200) ZODB Couldn't load state for 
'\x00\x00\x00\x00\x00\x01\x1f\xc9'
Traceback (innermost last):
  Module ZODB.Connection, line 533, in setstate
ImportError: No module named */rJ6Q2CNqMJDSN4Okpwiuw==

The object that fails to load state is a BTree Bucket belonging to the 
ZClass registry, and /rJ6Q2CNqMJDSN4Okpwiuw== is the GUID of one of my 
ZClasses.  If I delete that ZClass, it complains about a different one.

If I restart the server, everything works again, for a while, but I get 
the following in my log:

2002-12-10T11:36:49 INFO(0) ZCS:2443 Connected to storage
--
2002-12-10T11:36:49 INFO(0) ZODB Opening database for mounting: 
'144865536_1012175858.273945'
--
2002-12-10T11:36:49 INFO(0) ZODB Mounted database 
'144865536_1012175858.273945' at /temp_folder
--
2002-12-10T11:36:50 ERROR(200) ZODB Couldn't load state for 
'\x00\x00\x00\x00\x00\x01\x1f\xc9'
Traceback (innermost last):
  Module ZODB.Connection, line 533, in setstate
ImportError: No module named */rJ6Q2CNqMJDSN4Okpwiuw==
--
2002-12-10T11:36:50 ERROR(200) Zope A problem was found when checking 
the global product registry.  This is probably due to a Product being 
uninstalled or renamed.  The traceback follows.
Traceback (innermost last):
  Module OFS.Application, line 218, in checkGlobalRegistry
  Module ZODB.Connection, line 533, in setstate
ImportError: No module named */rJ6Q2CNqMJDSN4Okpwiuw==
--
2002-12-10T11:36:50 INFO(0) Zope Beginning attempt to rebuild the global 
ZClass registry.
--
2002-12-10T11:36:52 INFO(0) Zope The global ZClass registry has 
successfully been rebuilt.
--
2002-12-10T11:36:52 INFO(0) ZServer HTTP server started at Tue Dec 10 
11:36:52 2002
Hostname: server1.shackworks.com
Port: 8280

Help!


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Infuriating ZClass registry Heisenbug

2002-12-10 Thread Evan Simpson
Shane Hathaway wrote:

My first recommendation would be to turn your ZClass registry into an 
OOBTree.  OOBTree has been maintained and updated.

Good thought, but no dice.

Since it is rebuilding the registry on every restart anyway, I went 
ahead and made the changes to my OFS/Application.py.  I confirmed that 
ZGlobals is now an OOBTree, but subsequent restarts continue to show the 
same problem :-(

I've placed pdb.set_trace all over the DB state-loading code.  When I 
attempt to step into the state = unpickler.load() line during the 
loading of the ZGlobals OOBTree, it immediately throws an ImportError on 
the ZClass GUID.  It doesn't even seem to enter the persistent_load or 
classLoader methods.

Tracing this has gotten me all confused.  I understand (I think) that 
when a ZClass instance is unpickled, persistent_load gets the ZClass 
GUID and uses that to look up the actual _zclass_ class in ZGlobals. 
What I can't understand is why it would try to import the GUID when 
loading ZGlobals.  All it has it in is strings and the _zclass_ 
ExtensionClasses, and they should be handled by the normal unpickling 
machinery, right?

Thanks,

Evan


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: bug in mapply.py?

2002-11-05 Thread Evan Simpson
Tim Hicks wrote:

Given a call signature like:

def method(self, *args, **kw)

In this way, mapply.py seems to ignore the fact that I want my method to
accept an arbitrary number of arguments (line 69).


When mapply was written, its only purpose was to map explicit method 
parameters to request variables.  There was no concept of RPC of any 
kind, so neither '*args' nor '**kwargs' had any kind of sensible 
interpretation.

So, yes, mapply does ignore what you want :-)

Unfortunately, given the way that XML-RPC and WebDAV have been piled on 
top of the initial implementation, I'm not sure how this could be fixed 
properly in Zope 2.x.

Sorry,

Evan @ 4-am


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Strange Bug in Scripts (Python) and Python code ...

2002-10-22 Thread Evan Simpson
Joachim Werner wrote:

These few lines brought the Zope server (and the Browser I used for testing)
to a halt:

html = ''
for letter in 'ABCDEFGHIJKLMNOPQRSTUVWXYZ':
html += '|'.join([html, letter])
return html


This computes a string O(2^26) in length.  Scripts make very little 
attempt to prevent excessive consumption of memory or CPU, since the 
only sure way to do this is to have hard OS-level limits on a per-thread 
basis, plus the ability to cleanly shut down a thread that violated the 
limits.

If someone maliciously writes a Script to take down your Zope, you can 
revoke their login (unless you allow Anonymous to edit Scripts :-P).  It 
would be nice to more protection against code such as your example that 
accidentally spins out of control, but your example also demonstrates 
just how hard this is to do.  The interpreter would have to check the 
size of every object it constructed, at every step, in order to catch 
this case.  This could easily drag performance down by an order of 
magnitude.

Cheers,

Evan @ 4-am



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: Only anonymous in an Access Rule?

2002-09-30 Thread Evan Simpson

Chris Withers wrote:
 How come getSecurityManager().getUser() returns the Anonymous User in 
 access rules? Surely some checks must have been done to see whether the 
 folder containing the access rule can be traversed to?
 
 If not, then huh? I'm confused :-(

Access Rules trigger during publishing traversal, and authentication 
isn't performed until publishing traversal is complete.  Until traversal 
is complete, Zope can't know which containers to check for User Folders.

Also, publishing traversal only checks __roles__ on the last object in 
the traversal.  This is very different than unrestrictedTraverse(), for 
instance, which checks permissions at every traversal step.  This means 
that you can set security in a way that allows a user to access an 
object via ZPublisher that they could not access programmatically.

Cheers,

Evan @ 4-am


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request

2002-05-10 Thread Evan Simpson

Jim Penny wrote:
 I have also said that, while ZPT is not as warty as DTML, ZPT looks,
 on the surface, to be pretty ugly.  I have said that there are three
 specific things I dislike about ZPT -- 0)  lots of things have changed
 spelling again -- request v. REQUEST, here v. context v. container v.
 this v. ?

I understand this, but ZPT design was deliberately not constrained by 
DTML or Script binding design.  DTML has no way to spell 'here' or 
'container', and 'this' is actually a method defined by one of the Zope 
mixin classes.  REQUEST is an artifact of acquisition, an attempt to 
deal with a giant pile of (possibly conflicting) names that doesn't make 
sense in the TALES namespace.  So, the only real spelling changes are 
acquisition's REQUEST vs. request and Scripts' context vs. here. 
  During development, we often referred to the entire collection of 
standard TALES variables as contexts, so calling the current traversal 
  object context felt peculiar.

 2) the 
 order of operations, which I think is baroque.  Six levels of precendence 
 for eight statements is pretty amazing.  And it is certainly harder to 
 explain/remember than things happen in the order you specify.

As mentioned before, several decisions were made based on the 
constraints of XML.  Process XML with XSLT, or some other 
standards-compliant filter, and you cannot guarantee that the order of 
attributes will be preserved.  Frankly, I don't see the difficulty.  All 
you need to remember is that variables are defined first and substitions 
happen after repetition.  The only thing I would change now is to make 
repeat come first.

 I will add a fourth nit -- I cannot see why attributes should be plural
 when every other command is singular.  Certainly it feels like attribute
 ought to be an acceptable spelling of the atttributes command!

I suggested allowing both singular and plural versions, but it was 
roundly rejected by Jim and Guido (among others) on the basis of too 
many ways to spell things. Also, the only other TAL statement that can 
have multiple parts is define; define a variable and define 
variables both sound right.

 My most-missed DTML feature has not been mentioned at all -- it is not
 loop batching -- it is the dtml-else option of dtml-in -- which made it
 much easier to handle the nothing found case.

Yes, TAL's constraints make else-type logic hard to do well.  It's not 
all bad, though; if you define a variable for your list you can easily do:

div tal:repeat=value seq.../div
div tal:condition=not:seqelse/div

 I also have not found a convention that I am comfortable with on
 handling check-boxes and radio buttons in error processing.  But I
 expect to!

What do you mean?

Cheers,

Evan @ 4-am



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Speaking of 2.6...

2002-04-17 Thread Evan Simpson

Lennart Regebro wrote:
  There is an alternative, and that is to clean up the enhanced
  enhanced virtual host monster we at Torped have done. It's based on
  sfm@imemes enhanced VHM and just like VHF is makes it possible to
  have standalone virtual hosting without strange apache magic. We
  added an API to translate virtual to physical paths and back.

Just so you know, a limited version of the imeme enhancements is in the
Zope 2.5 VHM, and there is a standard REQUEST API consisting of
physicalPathToVirtualPath, physicalPathToURL, and physicalPathFromURL.

Cheers,

Evan @ 4-am



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Re: typo in HTTPResponse.py

2002-03-15 Thread Evan Simpson

Christian Theune wrote:
 Hmm. Is it possible to implement some option to turn this off?

I just checked in the ability to use HTTP_TRACEBACK_STYLE to control the 
appearance of tracebacks in non-debug mode errors:

'' (default): Place it in an HTML comment
'none': Omit it
'plain': Include it as plain text just as in debug mode.
'js': Show a sect; that expands into the traceback when clicked.

Cheers,

Evan @ Zope


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] User Name in python script

2002-02-25 Thread Evan Simpson

Sebastian Sippl wrote:
 I need to get the name of the current user , in a python script

In a recent Zope, you should be able to use:

from AccessControl import getSecurityManager
user = getSecurityManager().getUser()

Cheers,

Evan @ Zope


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Getting Unauthorized from __bobo_traverse__.

2001-09-12 Thread Evan Simpson

Steve Alexander wrote:

 ... which you can't use from restricted things like (Script) Pythons and 
  DTML Methods. So, the answer lies in External Methods and Python 
 Products. If only I could remember what the question was...

There was a bug, fixed in 2.4.1, with restrictedTraverse across 
__bobo_traverse__ when the security is controlled by the container 
rather than the target object.  If you grab OFS/Traversal.py (I think) 
from the CVS root, it should fix the problem.

Cheers,

Evan @ Zope





___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] TALES in DTML

2001-07-13 Thread Evan Simpson

I've been given time to work on draft documentation changes for:

http://dev.zope.org/Wikis/DevSite/Proposals/DTMLplusTALES

If you're interested, now is the time to comment.

Cheers,

Evan @ digicool


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] XXXPythonScripts release 1.0

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 )



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 )



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 )



[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
 dtml-var func) the positional arguments are gotten from the namespace,
 right?


Not for just any Python functions, no.  For Scripts, yes, *if* you use 
the Bindings tab of the Script to give a name to the caller's namespace. 
  The reasoning here is that a Script won't do anything with the 
caller's namespace unless you tell it to.  Otherwise you have to use 
dtml-var expr=func(x,y,z) type notation.


 So why do so many DTML methods / documents have REQUEST as an explicit
 argument?  It looks like a convention that has to mean something.


That's just the generic call signature of DTML.  If the callee is to 
have implicit access to the REQUEST, you have to either pass the REQUEST 
itself or a proper namespace as the second parameter.   DTML was never 
really designed to be called with explicit parameters.

 I am a little bit confused about the fact that the acquisition path is
 related to how the document was called, not just to the containment
 relationships it is involved in.  Or is it?  myobj.aq_parent isn't
 necessarily the object that contains myobj?


Correct.  Acquisition is a complex subject, and a lot has been written 
about it on Zope.org.  When you write /A/B, B could be contained in 
either A or / (the root), but its acquisition parent is A.


 Is the namespace stack basically the same as the acquisition path?

Nope.  Each Zope object on the namespace stack has its own acquisition 
wrapper.  Fortunately, there usually aren't very many Zope objects on 
the stack.

Cheers,

Evan @ digicool


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Re: DTML-Python confusion (RE: [Zope] How to make a script return rendered dtml)

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] 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: [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] 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: 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] 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] 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 )



[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] 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 )



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 )



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



[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 developersin whichthe programming and page/site design tasks 
are handled by separate people.

Cheers,

Evan @ digicool


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 )



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] 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] 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] 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] 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] 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] 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] porting from Python Methods to PythonScripts in 2.3.0; LoginManager too

2001-01-29 Thread Evan Simpson

From: "Fred Yankowski" [EMAIL PROTECTED]
 + Don't copy over SiteAccess and PythonMethods.
 + Delete the PythonMethods product from the Control_Panel/Products
   management folder.

 Will I have to manually convert each existing Python Method to
 a PythonScript, or are they essentially the same type?

They are radically different types, and can therefore live in the same Zope,
side-by-side, without conflicting.  There is no automatic conversion
process.  Simply keep PythonMethods installed, and replace individual
Methods with Scripts as you feel the need.

Cheers,

Evan @ digicool  4-am


___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )




Re: [Zope] porting from Python Methods to PythonScripts in 2.3.0;LoginManager too

2001-01-29 Thread Evan Simpson

From: "Jim Washington" [EMAIL PROTECTED]
 Standard caveats, YMMV, etc, but it does a quick pass on the Methods in
 the folder where it is and makes Scripts from them when you hit the
 'test' tab, saving the old ones as methodname.old.

Excellent!  Thanks for writing and sharing this -- it looks like a fine
candidate for a HOWTO.

Cheers,

Evan @ digicool  4-am


___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )




Re: [Zope] Python Methods can't construct literal dictionaries?

2001-01-28 Thread Evan Simpson

This is one of the shortcomings of Python Methods that Scripts eliminate.
You can work around it by writing:

x = {}
x.update({y: z})

Cheers,

Evan @ digicool  4-am


___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )




Re: [Zope] PythonScript question

2001-01-27 Thread Evan Simpson

From: "Timothy Wilson" [EMAIL PROTECTED]
 Error Type: TypeError
 Error Value: argument 1: expected read-only character buffer, instance
found
[snip]
input name="display_date:date" size="20" value=""/td
[snip]
 D = string.split(display_date, '/')

You are marshalling 'display_date' as a date, then trying to treat it as a
string.  You need to either convert it to a string or use date methods.

Cheers,

Evan @ digicool  4-am


___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )




Re: [Zope] SiteRoot 2 errors

2001-01-26 Thread Evan Simpson

From: Stephan Goeldi [EMAIL PROTECTED]
 I want to add a SiteRoot to my domain subfolder.
 I installed a fresh Zope 2.2.5 and in the lib/python/Products folder I
 extracted SiteAccess-2.0.0b4-nonbin.tgz. After this I restarted Zope.
 When I click to Add SiteRoot, I get the following error message:
[snip]
   File /usr/local/zope/lib/python/DocumentTemplate/DT_String.py, line 566,
 in read_raw
 (Object: www/SiteRootAdd)
 IOError: (see above)

Check the file ownership/permissions on the SiteAccess directory and its
subdirectories.

Cheers,

Evan @ digicool  4-am


___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )




Re: [Zope] Acquisition Algebra; interaction of containment and acquisition is confusing

2001-01-26 Thread Evan Simpson

From: Fred Yankowski [EMAIL PROTECTED]
 for the very last case, "a.b.c.x".  I just can't follow why the
 equivalent expression isn't

 x.__of__(a).__of__(c.__of__(b.__of__(a)))

 rather than the more complex answer given:

 x.__of__(a).__of__(b.__of__(a)).__of__(c.__of__(b.__of__(a)))

You can expand any access path into an acquisition expression using the
following 3-1/2 rules:

1. Given an unwrapped object 'x', x.child = (child o x)
2. Given a wrapper (self o parent),
  a. (self o parent).child = self.child o (self o parent) if 'child' is
found in 'self'.
  a. (self o parent).child = parent.child o (self o parent) if 'child' is
found in 'parent'.
3. Reduce ((a o b) o (b o c)) to (a o (b o c)) as soon as it appears.

So, a.b = (b o a).  a.b.c = (b o a).c = (b.c o (b o a)) = (c o (b o a)).
Finally, a.b.c.x = (c o (b o a)).x = ((b o a).x o (c o (b o a))) =
   ((a.x o (b o a)) o (c o (b o a))) = (((x o a) o (b o a)) o (c o (b o a)))

 When I run the test cases given in the document I see that the latter
 does match the behavior, but I find that baffling.  In particular, why
 is the effective search order x-a-b-c rather than x-a-c-b?  It almost
 looks like the effective search order could be described as "up
 through the containment heirarchy, then down through the remaining
 acquired path", but I'm not at all sure if that's a valid
 generalization.

Almost.  It's "up through the containment hierarchy, then the rest of it
somehow".  Trying to control or predict the exact search order for any but
the simplest acquisition trees is a dangerous game.  You can read it off
directly from the algebra form, as in (((x o a) o (b o a)) o (c o (b o a)))
= x, a, b, c (ignoring duplicates), but it's unlikely to be useful, as you
saw.

Cheers,

Evan @ digicool  4-am


___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )




Re: [Zope] Acquisition Algebra; interaction of containment and acquisition is confusing

2001-01-26 Thread Evan Simpson

From: Fred Yankowski [EMAIL PROTECTED]
 Now, does that bother anyone besides me?  Since acquisition is intrinsic
 and ubiquitous in Zope, shouldn't we be concerned that it is hard to
 control or predict?

Keep in mind that it is only the *order after containment* that has this
problem. For instance, schemes to "skin" a subfolder by changing access
paths should ensure that there is always exactly one "skin" implementation
in the acquisition path.  It is tempting to provide a "default skin" in the
containment path, but then you can't override it.

Cheers,

Evan @ digicool  4-am


___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )




Re: [Zope] VirtualHostMonster, PATH_INFO and absolute_url

2001-01-25 Thread Evan Simpson

From: Philip Aylesworth [EMAIL PROTECTED]
 I would appreciate that HOWTO. :) I am going to need virtual hosting for
 a project I am undertaking and don't even know where to begin. Is
 VirtualHostMonster part of SiteAccess (which I have just discovered when
 I did a search on zope.org)? Do I need to use apache for it? Should I
 use apache rather than ZServer if I don't need any of apache's features?

If you genuinely don't need Apache, ZServer is certainly good enough.  Many
people (such as myself) use Apache for a cheap management/performance win
serving large utterly static content like images, for battle-tested SSL, and
for the ability to run other back-end servers or CGI in parallel.
VirtualHostMonster is a newish SiteAccess component that makes virtual
hosting easy for the most common cases, where Apache or some other thin
back-end is handling the incoming rewriting, and the rewriting consists of
host/port renaming and path insertion (http://www.myhost.com/ =
http://localhost:8080/myhost).  In this case, all you need is one
VirtualHostMonster and a slight, easy change to your rewrite/proxy
directives.

Cheers,

Evan @ digicool  4-am


___
Zope maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )




  1   2   3   >