----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 06, 2003 12:00 AM Subject: Zope-Dev digest, Vol 1 #2021 - 13 msgs
> Send Zope-Dev mailing list submissions to > [EMAIL PROTECTED] > > 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 > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> > To: Craeg K Strong <[EMAIL PROTECTED]> > Cc: Jamie Heilman <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > To: Andy McKay <[EMAIL PROTECTED]> > CC: Craeg K Strong <[EMAIL PROTECTED]>, > Jamie Heilman <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [Zope-dev] LOTS of roles? > > On Tue, Feb 25, 2003 at 06:33:16PM +0000, Florent Guillaume wrote: > > Leonardo Rochael Almeida <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > Date: Tue, 4 Mar 2003 20:21:18 +0100 > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > cc: [EMAIL PROTECTED] > Subject: Re: [Zope-dev] [Vote] PEP308 voting began > From: Guido van Rossum <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > CC: Guido van Rossum <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > To: Guido van Rossum <[EMAIL PROTECTED]> > CC: Dieter Maurer <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > To: Chris Withers <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > 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 - [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 maillist - [EMAIL PROTECTED] > 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, > [EMAIL PROTECTED], http://mail.zope.org/mailman/listinfo/zope ) > > End of Zope-Dev Digest > > _______________________________________________ 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 )
