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