On Wed, Jul 23, 2003 at 03:59:58PM +1000, Richard Jones wrote:
Say a method listFilesByUser returns a list of (user, [files])
it'd be nice to be able to::
tal:repeat=user,files here/listFilesByUser
or similar. Currently we would have to use a python: expression to manually
unpack
Hi
Someone please help me out with this:
I am passing a string in this format (215,216) from the python script to
the Zsql method.
The SQl query should have the following form:
select * from employees where id in (215,216)
but is as follows:
select * from employees where id in '(215,216)'
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
Hello!
I've found today that it is simply impossible to use cyrillic
characters in ZMI in the latest zope from cvs. If I don't have
management_page_charset set on root folder and try to enter cyrillic
title for some folder, I get following error:
Error Type: UnicodeError
Error Value: Latin-1
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
Yes, this would be more comfortable, some of my templates would be cleaner
with this feature.
You may work this around like this...
stuff tal:define=packed python: someScript(stuff, foo, bar);
item1 python: packed[0];
item2 python: packed[1]
with someScript ending with...
return foo, bar
I'm
Paul Winkler writes:
In this case, consider a trivial change to (or wrapper around)
listFilesByUser to make it return a sequence of dictionaries
like {'user': some_user, 'files': (file1, file2...)}
This is exactly what the proposal I posted a couple of weeks ago was
trying to avoid.
Gilles Lenfant writes:
I'm interrested into adding some other wishes for the next ZPT versions.
Where could those wishes be posted ?
This is the place.
There's only very limited resources available at Zope Corp to make
changes happen right now, so be prepared to help make changes if
Hi
Someone please help me out with this:
I am passing a string in this format (215,216) from the python script to
the Zsql method.
The SQl query should have the following form:
select * from employees where id in (215,216)
but is as follows:
select * from employees where id in
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.
What's behind this ?
Actually, we get the template variable available in the TALES namespace.
template, when used in a macro, refers to the template that uses the
macro, and not to the template that contains the macro.
The future (if you wish it with me) thistemplate variable will refer to
the
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
Gilles Lenfant wrote:
What's behind this ?
Actually, we get the template variable available in the TALES namespace.
template, when used in a macro, refers to the template that uses the
macro, and not to the template that contains the macro.
IMHO the underlying problem is that there's no clean way
(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
30 matches
Mail list logo
