Evan Simpson wrote:
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?
Don't think so, the stuff we
Evan Simpson wrote:
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)
How would this interact with the
Shane Hathaway wrote:
Guys, that line of thinking is a distraction. ZPT authors ought to
learn Python.
I dunno about that, I would really like to see simple ZPT require no
understanding of python...
language again. If DTML used TALES expressions, it would be just as
clean as ZPT.
I actually
Jim Penny wrote:
Ahh, OK. The damned here/context semantic trap again. It is too late
to revisit, it is a done deed, it was a really good idea to call the
concept context, self, and here, depending on what kind of object you
are using, etc. But here suggests container more strongly to my mind
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
hmm, well to be clear, you're still using implicit acquisition if you say
span tal:content=here/foo ... /span
However, TAL is much better about using explicit namespaces
Yes, explicitly using implicit acquisition. I'll give you that.
If Zope is your first exposure to Python, I'm not sure if
Paul Winkler wrote:
On Tue, Jul 29, 2003 at 04:43:21PM -0400, Shane Hathaway wrote:
a tal:attributes=href here/format:url_quote /
Where do you put the argument? I don't see some_url.
Oops, I meant this:
a tal:attributes=href some_url/format:url_quote /
To me, that's a vast improvment, and it's
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
On Wed, Jul 30, 2003 at 12:13:41PM -0500, Evan Simpson wrote:
The explanation isn't that hard, at least for a user with a basic
knowledge of data structures --
they have a basic knowledge of data structures but they can't be
taught to write a python script in about the same amount of time?
On Wed, 30 Jul 2003 12:13:41 -0500
Evan Simpson [EMAIL PROTECTED] wrote:
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
On Wed, 30 Jul 2003 15:59:47 -0500
Evan Simpson [EMAIL PROTECTED] wrote:
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
Shane Hathaway wrote:
Literally, user_files/int:0 says get item 0 of user_files,
interpreting '0' as an integer. Technically, this could be interpreted
as get the attribute named 0 or item 0, but an attribute name must be
a string, so implicitly it really just says get item 0.
We've come up
Philipp von Weitershausen wrote:
AFAIK, Jim wants this for Zope3 for some time now. The idea is to
implement this with named adapters.
The framework is implemented, as are one or two examples, IIRC...
The question remains how to implement this in Zope2 as we don't have
adapters there.
The
Evan Simpson wrote:
'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
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote:
... This would allow
options/a_mapping/key:items/index:0 rather than
python:options['a_mapping']['items'][0].
Why is that an improvement?
Personally, I find it much easier to read...
I wonder what
Am Dienstag, 29. Juli 2003 19:22 schrieb Chris Withers:
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote:
... This would allow
options/a_mapping/key:items/index:0 rather than
python:options['a_mapping']['items'][0].
Why is that an improvement?
On Tue, Jul 29, 2003 at 06:22:38PM +0100, Chris Withers wrote:
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote:
... This would allow
options/a_mapping/key:items/index:0 rather than
python:options['a_mapping']['items'][0].
Why is that an improvement?
On Tue, 29 Jul 2003 14:27:34 -0400
Paul Winkler [EMAIL PROTECTED] wrote:
On Tue, Jul 29, 2003 at 06:22:38PM +0100, Chris Withers wrote:
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote:
... This would allow
options/a_mapping/key:items/index:0
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:',
I have been watching this thread silently for what seems like weeks, and I
think it is time for a newcomer's opinion. I like to read above my station
;-)
options/a_mapping/key:items/index:0 rather than
python:options['a_mapping']['items'][0].
They look very similar to me. There is little or
[Paul Winkler]
I guess I don't understand the goal. Are we trying to make it
so that zpt authors don't have to know any python?
[Chris Withers]
For me, that would be ideal...
[Paul Winkler]
I really think that's a mistake.
Guys, that line of thinking is a distraction. ZPT authors ought to
learn
Shane Hathaway writes:
- You have to be careful not to use double quotes in expressions.
(Ampersands and less-than/greater-than signs are tricky too. Watch out
for pairs of hyphens!)
This is FUD. TAL can handle these things quite well; the problem is
that many web developers don't have
On Tue, 29 Jul 2003 16:43:21 -0400
Shane Hathaway [EMAIL PROTECTED] wrote:
[Paul Winkler]
I guess I don't understand the goal. Are we trying to make it
so that zpt authors don't have to know any python?
[Chris Withers]
For me, that would be ideal...
[Paul Winkler]
I really think that's
Fred L. Drake, Jr. wrote:
Shane Hathaway writes:
- You have to be careful not to use double quotes in expressions.
(Ampersands and less-than/greater-than signs are tricky too. Watch out
for pairs of hyphens!)
This is FUD. TAL can handle these things quite well; the problem is
that many
On Tue, Jul 29, 2003 at 09:26:07PM +0100, Christopher Boomer wrote:
The only problem I ever have in this area is knowing when something
is too complicated for TAL, and moving that boundary will not help.
In particular, expanding the size of the overlapping gray area will not help.
Often I
Jim Penny wrote:
Frankly, would not even have occurred to me - I would probably create a
tiny Script (Python) en passant, and called it directly, as:
a tal:attributes=href python: here.url_quote(some_url) /. I did not
realize that this is deprecated in Zope3.
Your example relies on implicit
Shane Hathaway writes:
I'm not quite sure what you're saying. The following fails compilation:
span tal:content=python: abc /
That's because you've broken the syntax. It should have been:
span tal:content=python: quot;abcquot; /
or, more legibly,
span tal:content=python:
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
On Tue, Jul 29, 2003 at 04:43:21PM -0400, Shane Hathaway wrote:
Python expressions won't be banned. I will never consider them
discouraged for all cases, either. There will always be a need for
constructs like:
div tal:condition=python: a == b.../div
div tal:condition=python: (a and b)
On Tue, 29 Jul 2003 17:04:46 -0500
Evan Simpson [EMAIL PROTECTED] wrote:
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.
On Tue, 29 Jul 2003 17:51:56 -0400
Shane Hathaway [EMAIL PROTECTED] wrote:
Jim Penny wrote:
Frankly, would not even have occurred to me - I would probably
create a tiny Script (Python) en passant, and called it directly,
as:a tal:attributes=href python: here.url_quote(some_url) /. I
did
On Wed, 30 Jul 2003 06:16 am, Evan Simpson wrote:
OK, I've checked in a sample implementation on evan-pathprefix-branch.
It allows for registering prefixes with:
This seems very nice. I'm not likely to actually have a chance to play with it
any time soon though, so I can't really comment on
I only use 2 because it's there :-) Thinking more about it, it
occurs to me that python expressions in TALES provide a huge hole
in the separation of presentation from logic.
My view is that embedding logic in presentation isn't quite the right
thing to avoid. Consider how much logic goes into
I only use 2 because it's there :-) Thinking more about it, it
occurs to me that python expressions in TALES provide a huge hole
in the separation of presentation from logic.
Perhaps it's worthwhile for this thread to have a look at
On Thu, Jul 24, 2003 at 11:00:09AM +0200, Jean Jordaan wrote:
Perhaps it's worthwhile for this thread to have a look at
http://www.eby-sarna.com/pipermail/transwarp/2003-July/000606.html
http://www.eby-sarna.com/pipermail/transwarp/2003-July/000607.html
and following to see what Phillip Eby
Richard Jones wrote:
During the Melbourne Zope3 Sprint, someone ran up against a situation where
they'd have liked to have TALES perform a tuple unpacking like Python can.
I've just run into a similar situation :)
Say a method listFilesByUser returns a list of (user, [files]) it'd be nice to
Philipp von Weitershausen wrote:
I agree that it is 'yucky', but I have to disagree with your proposed
solution. I would rather suggest making TALES aware of integer indexes
for sequences. Example::
tal:block repeat=user_files here/listFilesByUser
User: tal:dummy replace=user_files/0 /
Shane Hathaway wrote:
Philipp von Weitershausen wrote:
I agree that it is 'yucky', but I have to disagree with your proposed
solution. I would rather suggest making TALES aware of integer indexes
for sequences. Example::
tal:block repeat=user_files here/listFilesByUser
User: tal:dummy
Shane Hathaway wrote:
Here's the way I'd like to spell it:
div tal:repeat=user_files here/listFilesByUser
User: span tal:replace=user_files/int:0 /
File: span tal:replace=user_files/int:1 /
/div
+1
We've come up with a number of generally useful prefixes, BTW. Off the
top of my
It is absolutely amazing how slippery this stuff is to pin down.
The same ideas keep popping up and then slowly subsiding under
the weight of exceptions, prefixes and caveats.
I kinda suspect the only way is to deliver a specific take on
the whole thing, like Evan did with the current ZPT, and
Tino Wildenhain wrote:
Shane Hathaway wrote:
We've come up with a number of generally useful prefixes, BTW. Off
the top of my head:
call: -- Call a named method
int:-- Look up an item by index
format: -- Perform simple formatting operations like format:money
zope: -- Access a big Zope
On Wed, 23 Jul 2003 10:00:37 -0400
Shane Hathaway [EMAIL PROTECTED] wrote:
We've come up with a number of generally useful prefixes, BTW. Off
the top of my head:
call: -- Call a named method
int:-- Look up an item by index
Hate this. Looks like a typecast of some kind, int is way
int:-- Look up an item by index
Hate this. Looks like a typecast of some kind, int is way to overused
Aesthetically, I also find it ugly. The attractiveness of a *path*
expression lies in its resemblance to a *path*.
But I realise it's like the weird ++elements in Zope3 paths that
I hope
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
On Wed, Jul 23, 2003 at 10:48:10AM -0400, Shane Hathaway wrote:
Think of prefixes as site-wide, generally useful Python scripts.
That's fine and dandy... but please please PLEASE don't let that
be the only way to call them. Put them in ZTUtils, or
Products.PythonScripts.standard, or someplace
Evan Simpson wrote:
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).
I can imagine the pain. Explicit is better than implicit.
Philipp von Weitershausen writes:
Why wouldn't that be possible with a_list/index:?i?
I think making it a_list/index:i is fine. The adapter for index:
will get the index as a string and convert that to an integer and
return a_list[i]. The index: adapter simply represents a namespace in
which
(I'm cc'ing zope-dev this time)
Evan Simpson wrote:
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
On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote:
... This would allow
options/a_mapping/key:items/index:0 rather than
python:options['a_mapping']['items'][0].
Why is that an improvement? surely it's not saving 3 characters
that makes the new syntax worthwhile...
Paul Winkler writes:
I guess I don't understand the goal. Are we trying to make it
so that zpt authors don't have to know any python?
I really think that's a mistake.
There are those that consider using python: expressions in ZPT should
be discouraged, primarily because it's yet another
On Wed, Jul 23, 2003 at 02:04:51PM -0400, Fred L. Drake, Jr. wrote:
There are those that consider using python: expressions in ZPT should
be discouraged, primarily because it's yet another syntax for a web
developer to learn.
I'm not necessarily one of them, but I am sympathetic with that
Shane Hathaway wrote at 2003-7-23 10:48 -0400:
...
Think of prefixes as site-wide, generally useful Python scripts. Quite
often some API returns something that's intuitively easy to present, but
ZPT's syntax makes it somewhat difficult to present. For example, it
should not be
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 02:04:51PM -0400, Fred L. Drake, Jr. wrote:
There are those that consider using python: expressions in ZPT should
be discouraged, primarily because it's yet another syntax for a web
developer to learn.
I'm not necessarily one of them, but I am
On Wed, Jul 23, 2003 at 05:15:48PM -0400, Shane Hathaway wrote:
Paul Winkler wrote:
On Wed, Jul 23, 2003 at 02:04:51PM -0400, Fred L. Drake, Jr. wrote:
There are those that consider using python: expressions in ZPT should
be discouraged, primarily because it's yet another syntax for a web
On Wed, Jul 23, 2003 at 06:15:46PM -0400, Paul Winkler wrote:
(snip)
I think I'd have to try rewriting some of my complex templates with
no python expressions whatsoever before I'd know if I agree with you.
(snip)
I only use 2 because it's there :-) Thinking more about it, it
occurs to me
Dieter Maurer wrote:
Be very reluctant to extend TALES. Do not do it do get just
syntactic sugar in order to save a few lines of code.
I agree that we should be wary. Adding a feature to make something
simpler simultaneously complicates the whole picture. To offset that
negative, the new
56 matches
Mail list logo