Re: Zope-Dev digest, Vol 1 #2021 - 13 msgs - Zope-Dev

6 Mar 2003


      ----- Original Message -----
From: <zope-dev-request@zope.org>
To: <zope-dev@zope.org>
Sent: Thursday, March 06, 2003 12:00 AM
Subject: Zope-Dev digest, Vol 1 #2021 - 13 msgs
...
Send Zope-Dev mailing list submissions to
zope-dev@zope.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.zope.org/mailman/listinfo/zope-dev
or, via email, send a message with subject or body 'help' to
zope-dev-request@zope.org
You can reach the person managing the list at
zope-dev-admin@zope.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Zope-Dev digest..."
Today's Topics:
1. Re: Declaring Dependencies for XML documents (Was: How
       To Improve Cache Coherency for RAM/Disk Cache Manager...?) (Andy
McKay)
   2. Re: Declaring Dependencies for XML documents (Was: HowTo
       Improve Cache Coherency for RAM/Disk Cache Manager...?) (Shane
Hathaway)
   3. Re: LOTS of roles? (Paul Winkler)
   4. [Vote] PEP308 voting began (Dieter Maurer)
   5. Re: Declaring Dependencies for XML documents (Was: HowTo Improve
Cache Coherency for RAM/Disk Cache Manager...?) (Paul Winkler)
   6. Re: [Vote] PEP308 voting began (Guido van Rossum)
   7. Re: [Vote] PEP308 voting began (Matthew T. Kromer)
   8. Re: [Vote] PEP308 voting began (Evan Simpson)
   9. Re: Re: [Vote] PEP308 voting began (Paul Winkler)
  10. Re: [Vote] PEP308 voting began (Chris Withers)
  11. [Fwd: Re: [Zope-dev] [Vote] PEP308 voting began] (Chris Withers)
--__--__--
Message: 1
Date: Tue, 04 Mar 2003 10:59:03 -0800
From: Andy McKay <andy@agmweb.ca>
To: Craeg K Strong <cstrong@arielpartners.com>
Cc: Jamie Heilman <jamie@audible.transient.net>, zope-dev@zope.org
Subject: Re: [Zope-dev] Declaring Dependencies for XML documents (Was: How
 To Improve Cache Coherency for RAM/Disk Cache Manager...?)
...
Anyway, after talking this over with my colleague, I realize that
the problem of *deriving* dependencies is fundamentally undecidable.
We might be able to figure it out in the case of simple acquisition,
like
<span tal:replace="here/aObject/aMethod"/>
But it is hopeless for pure python:
<span
tal:replace="python:I-can-do-anything-and-you-cant-stop-me(REQUEST)"/>
:)
Well you could, in theory, hook every object as CallProfiler does and
then you would know for each request what object was called and Cache
it. You could even do something really clever like using CallProfiler
automatically cache objects that took longer than a certain amount of
time...
But there are more issues with that than there are days in a year and
you could be writing that code forever, letting the user figure it out
manually is an easier choice.
Cheers.
--
   Andy McKay
--__--__--
Message: 2
Date: Tue, 04 Mar 2003 14:32:31 -0500
From: Shane Hathaway <shane@zope.com>
To: Andy McKay <andy@agmweb.ca>
CC: Craeg K Strong <cstrong@arielpartners.com>,
   Jamie Heilman <jamie@audible.transient.net>, zope-dev@zope.org
Subject: Re: [Zope-dev] Declaring Dependencies for XML documents (Was:
HowTo
 Improve Cache Coherency for RAM/Disk Cache Manager...?)
Andy McKay wrote:
...
...
Anyway, after talking this over with my colleague, I realize that
the problem of *deriving* dependencies is fundamentally undecidable.
We might be able to figure it out in the case of simple acquisition,
like
<span tal:replace="here/aObject/aMethod"/>
But it is hopeless for pure python:
<span
tal:replace="python:I-can-do-anything-and-you-cant-stop-me(REQUEST)"/>
:)
Well you could, in theory, hook every object as CallProfiler does and
then you would know for each request what object was called and Cache
it. You could even do something really clever like using CallProfiler
automatically cache objects that took longer than a certain amount of
time...
But there are more issues with that than there are days in a year and
you could be writing that code forever, letting the user figure it out
manually is an easier choice.
Ah, but you might have something there.  What if there were a cache
manager that simply dropped its contents whenever anything changes in
ZODB?  You could associate nearly all scripts and templates with that
cache manager without any fear of stale cache entries.  For many sites,
it could be an instant win.
Shane
--__--__--
Message: 3
Date: Tue, 4 Mar 2003 14:28:17 -0500
From: Paul Winkler <pw_lists@slinkp.com>
To: zope-dev@zope.org
Subject: Re: [Zope-dev] LOTS of roles?
On Tue, Feb 25, 2003 at 06:33:16PM +0000, Florent Guillaume wrote:
...
Leonardo Rochael Almeida  <leo@hiper.com.br> wrote:
...
So I think you need dynamically calculated local roles. This can be
achieved by a user folder that returns a user object that overrides
".getRolesInContext(object)" to take the location (or any other
attribute, such as an acquired "site") of "object" and check it
against
your central authorization source (eg. LDAP).
Note that you'll also want to change validate() if you go that route.
It has a short-circuited version of getRolesInContext in it.
I'm now looking into doing this...
and i haven't found what you mean.
there are a bunch of validates() in various modules in AccessControl,
which are you talking about?
]$ grep "def validate(" * 2> /dev/null
AuthEncoding.py:    def validate(reference, attempt):
AuthEncoding.py:    def validate(self, reference, attempt):
AuthEncoding.py:    def validate(self, reference, attempt):
AuthEncoding.py:        def validate(self, reference, attempt):
SecurityManager.py:    def validate(self, accessed=None, container=None,
name=None, value=None,
User.py:    def validate(self, request, auth='', roles=_noroles):
User.py:        def validate(self, request, auth='', roles=_noroles):
ZopeSecurityPolicy.py:        def validate(self, accessed, container,
name, value, context,
cAccessControl.c:       /*| def validate(self, accessed, container, name,
value, context
are you sure it's not BasicUser.allowed() that you mean?
there's a comment in there about checking roles manaully
rather than with getRolesInContext...
--
Paul Winkler
http://www.slinkp.com
--__--__--
Message: 4
From: Dieter Maurer <dieter@handshake.de>
Date: Tue, 4 Mar 2003 20:21:18 +0100
To: zope-dev@zope.org, zope@zope.org
Subject: [Zope-dev] [Vote] PEP308 voting began
Attention: cross post
PEP308 is concerned with the introduction of a ternary conditional
operator (something like an "if cond: val_true else: val_false")
into Zope.
In my view, such an operator would make TALES expressions
easier because we could get rid of the "and/or" hack to
represent conditionals and we could forget about the "test"
function, which evaluates too eagerly.
Please have a look at PEP308 and consider voting.
Details in "comp.lang.python.announce".
Dieter
--__--__--
Message: 5
Date: Tue, 4 Mar 2003 15:11:11 -0500
From: Paul Winkler <pw_lists@slinkp.com>
To: zope-dev@zope.org
Subject: Re: [Zope-dev] Declaring Dependencies for XML documents (Was:
HowTo Improve Cache Coherency for RAM/Disk Cache Manager...?)
On Tue, Mar 04, 2003 at 02:32:31PM -0500, Shane Hathaway wrote:
...
Ah, but you might have something there.  What if there were a cache
manager that simply dropped its contents whenever anything changes in
ZODB?  You could associate nearly all scripts and templates with that
cache manager without any fear of stale cache entries.  For many sites,
it could be an instant win.
interesting idea. there's certainly plenty of sites, though, where
the cache would get invalidated so often that the cache would be
of limited value.  e.g. a busy squishdot-type site, or many CMF sites.
and on those kind of sites, the busiest times are when you most need
the cacheing...
but the simplicity is certainly appealing...  and in my case, i
have a CMF site where this would likely be quite useful since
the public never logs in, only our content management team, and
we tend to make changes on dev servers and push them to production
in a big bunch.
--
Paul Winkler
http://www.slinkp.com
--__--__--
Message: 6
To: Dieter Maurer <dieter@handshake.de>
cc: zope-dev@zope.org
Subject: Re: [Zope-dev] [Vote] PEP308 voting began
From: Guido van Rossum <guido@python.org>
Date: Tue, 04 Mar 2003 15:23:54 -0500
...
Attention: cross post
PEP308 is concerned with the introduction of a ternary conditional
operator (something like an "if cond: val_true else: val_false")
into Zope.
In my view, such an operator would make TALES expressions
easier because we could get rid of the "and/or" hack to
represent conditionals and we could forget about the "test"
function, which evaluates too eagerly.
Please have a look at PEP308 and consider voting.
Details in "comp.lang.python.announce".
Dieter
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.
--Guido van Rossum (home page: http://www.python.org/~guido/)
--__--__--
Message: 7
Date: Tue, 04 Mar 2003 15:34:05 -0500
From: "Matthew T. Kromer" <matt@zope.com>
To: zope-dev@zope.org
Subject: Re: [Zope-dev] [Vote] PEP308 voting began
Guido van Rossum wrote:
...
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python.  If you can have a
"not:.." expression, surely you can have an "if:..:then:..:else:.."
expression.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Yes, I'd be interested in seeing some kind of expression superset
operator in TALES such that you could use some boolean logic in
expressions which had subexpressions of different types (ie path
expressions vs python expressions).  Currently the "punt" is to go out
to Python for any logic other than the path expression OR syntax.
e.g.
tal:define="variable tales: path: path_component | string: foo"
An inline if/else might be C like
tal:define="variable tales: local_var ? path: path_componenta :
string: foo"
where "tales:" is simply whatever the meta-expression handler name is.
--__--__--
Message: 8
Date: Tue, 04 Mar 2003 15:21:57 -0600
From: Evan Simpson <evan@4-am.com>
To:  zope-dev@zope.org,  zpt@zope.org
CC: Guido van Rossum <guido@python.org>
Subject: [Zope-dev] Re: [Vote] PEP308 voting began
Guido van Rossum wrote:
...
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python.  If you can have a
"not:.." expression, surely you can have an "if:..:then:..:else:.."
expression.
Now that you point it out, it's not even hard.  Here's a
proof-of-concept, with really awful parsing (it obviously breaks on
nested if: then: else:), that actually works:
class IfExpr:
     def __init__(self, name, expr, compiler):
         self._s = expr = expr.lstrip()
         m = re.match('(.*) then:(.*) else:(.*)', expr)
         if m is not None:
             condexpr, thenexpr, elseexpr = m.groups()
         self._cond = compiler.compile(condexpr)
         self._then = compiler.compile(thenexpr)
         self._else = compiler.compile(elseexpr)
def __call__(self, econtext):
         if econtext.evaluateBoolean(self._cond):
             return econtext.evaluate(self._then)
         return econtext.evaluate(self._else)
(Tested with
<div tal:replace="if:options/x then:string:yes else:string:no">)
Is this worth a robust implementation, ZPT folks?
Cheers,
Evan @ 4-am
--__--__--
Message: 9
Date: Tue, 4 Mar 2003 17:10:50 -0500
From: Paul Winkler <pw_lists@slinkp.com>
To: zope-dev@zope.org
Subject: Re: [Zope-dev] Re: [Vote] PEP308 voting began
On Tue, Mar 04, 2003 at 03:21:57PM -0600, Evan Simpson wrote:
...
Is this worth a robust implementation, ZPT folks?
maybe, but i'd rather first wait and see how the PEP goes.
it would suck to have to constantly deal with two totally
different flavors of ternary.
--
Paul Winkler
http://www.slinkp.com
--__--__--
Message: 10
Date: Wed, 05 Mar 2003 12:53:33 +0000
From: Chris Withers <chrisw@nipltd.com>
To: Guido van Rossum <guido@python.org>
CC: Dieter Maurer <dieter@handshake.de>,  zope-dev@zope.org
Subject: Re: [Zope-dev] [Vote] PEP308 voting began
Guido van Rossum wrote:
...
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python.  If you can have a
"not:.." expression, surely you can have an "if:..:then:..:else:.."
expression.
I think not: is dubious and I'd find if-then-else way over the lines...
Chris
--__--__--
Message: 11
Date: Wed, 05 Mar 2003 14:54:03 +0000
From: Chris Withers <chrisw@nipltd.com>
To:  zope-dev@zope.org
Subject: [Fwd: Re: [Zope-dev] [Vote] PEP308 voting began]
I think this was for the list...
Chris
-------- Original Message --------
Subject: Re: [Zope-dev] [Vote] PEP308 voting began
Date: Wed, 05 Mar 2003 08:42:10 -0500
From: Brian Brinegar <brinegar@pier.ecn.purdue.edu>
To: Chris Withers <chrisw@nipltd.com>
References: <15972.64686.377126.329892@gargle.gargle.HOWL>
<200303042023.h24KNuH27603@odiug.zope.com> <3E65F34D.8020701@nipltd.com>
Not sure if this applies, but lets say I have something like:
<div tal:repeat="item container/myList">
   <div class="selectedItem" tal:condition="item/isCurrent">Item 1</div>
   <div class="regularItem" tal:condition="not: item/isCurrent">Item
2</div>
</div>
When this is viewed outside of TAL, say by a designer in Dreamweaver,
both styles are apparent and their presentation can be changed by the
designer. Where something like this:
<div tal:repeat="item container/myList">
   <div class="selectedItem" tal:attributes="class ternary:
item/isCurrent: string: selectedItem | string: regularItem">Item</div>
</div>
would not include both versions of the presentation when viewed outside
of TAL. I've always assumed any kind of if/else combo would break the
change design after implementation aspect of page templates. However a
little extra work for designers saves a ton of duplication for
developers, so I think we should go with it. I also agree that it should
be an addition to TAL rather than using whatever python ends up with.
That's my few cents.
-Brian
Chris Withers wrote:
...
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.
I think not: is dubious and I'd find if-then-else way over the lines...
Chris
_______________________________________________
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 maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
(To receive general Zope announcements, see:
http://mail.zope.org/mailman/listinfo/zope-announce
For non-developer, user-level issues,
zope@zope.org, http://mail.zope.org/mailman/listinfo/zope )
End of Zope-Dev Digest

Re: Zope-Dev digest, Vol 1 #2021 - 13 msgs

Tra^`n Tua^'n Vinh

tags

participants (1)