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

Reply via email to