[Zope-dev] Re: TALES idea: tuple unpacking

2003-08-02 Thread Chris Withers
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 implemented in the TALES package was agnostic of 
component architecture...

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] Re: TALES idea: tuple unpacking

2003-07-31 Thread Chris Withers
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 Adapters stuff implements in Zope 3's TALES?

I'm pretty sure the implementation there could be used to make this happen, if 
it was backported to Zope 2's TALES...

cheers,

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 )


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-31 Thread Chris Withers
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 agree with that, but due to the likelyhood of that happening being so 
small, and the fact that backwards compatability will mean that the 
throat-slittingly bad stuff that happened as a result of DTML being used to do 
logic, and the bulk of really evil example stuff out there, I stick with my view 
that 'DTML sux'...

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 )


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-31 Thread Chris Withers
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
than container does! So, I try never to use it.
I believe 'here' is gone in Zope 3.
You're only likely to see 'self' if writing code on the filesystem.
And we're left with 'context' and 'container', which is pretty clear :-)
cheers,

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] Re: TALES idea: tuple unpacking

2003-07-31 Thread Evan Simpson
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 whole component 
framework make this really hard?

Cheers,

Evan @ 4-am

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Christopher Boomer
 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 you
 can appreciate what I mean. :-)
Possibly not.  I've often been thown into the deep end of projects.

 reference manual? which one? The Zope Book? (a fair amount of python
 is in it these days.) ZOpe Developers' Guide? (lots of python there.)
I was referring to Guido's Python Reference Manual, which is less a
reference of python modules, rather a reference of how python itself was
written.  No offence intended.  There's lots of python in both Zope books,
and I refer to them regularly.

 - Write as much as possible of your product's features in a class
 that doesn't inherit from *any* zope-specific base classes.
I can take that advice.  Seems reasonable enough, and makes the python more
reusable in any case.

I'm currently trying to write the interface to integrate a wholesaler XML
response into our database and finding myself falling between XML stools.
My notion was to convert it to a local XML format before importing that to
the database.  I figured that this layer would insulate against change in a
similar manner to the above, but it seems that generating xslt
programmatically is not something that people are doing much yet.

Thanks for your time.

Christopher.


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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Shane Hathaway
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 only one example.
It also raises some new questions that are about
on par with what would be needed to understand the zope 2 version: 
What kind of thingie is format:? Where can I find it if I want 
to learn what else it can do?  What do I do if I want 
format:some_custom_format?  How could I replace or augment
the format thingie and not break any template that uses it?
It is intended that format: refers to a Python module.  You should not 
extend that module, unless you're developing Zope itself.  You'd find 
documentation on it in the Zope Book.  If you need more functionality, 
you can configure your own prefixes.

You know what was actually wrong with DTML?  The lack of Python Scripts. 
Without Python Scripts, everyone used DTML as a programming language. 
Once Python Scripts came around, DTML became a reasonable templating 
language again.  If DTML used TALES expressions, it would be just as 
clean as ZPT.


I think I just said this in another post :)
Maybe you didn't draw the same conclusion, then. ;-)  My conclusion: 
since the main problem with DTML had little to do with DTML syntax, 
nothing indicates that ZPT growing pains are going to turn ZPT into a 
monster.  As long as we retain Python Scripts and evolve ZPT slowly, ZPT 
is in no danger of becoming a problem like DTML did.

Shane

___
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] Re: TALES idea: tuple unpacking

2003-07-30 Thread Evan Simpson
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 
knowledge of data structures -- you usually use key: with a dictionary, 
and item: with a sequence.  The exception is when you have an integer 
key in a dictionary.

Eeep, gad no.  The python is horrible.  The prefix syntax is equally
horrible, unfamiliar, and ambiguous!  For example, why does call: not
have an argument
Because I'm not passing an argument to the SQL statement.  In my 
implementation, the syntax is call:arg1,arg2,..., where each argument 
is required to be a variable name.  Every prefixed path element operates 
upon the current traversal object, using the argument (if any) to the 
prefix.  Here's a list that demonstrates:

x/key:foo  -- x['foo']
x/item:0   -- x[0]
x/attr:foo -- x.foo
x/call:foo -- x(foo)
x/var:foo  -- getattr(x, foo) or x[foo] (path traversal semantics)
x/fmt:%.2f -- '%.2f' % x
x/fmt:thousands_commas -- thousands_commas(x)
Yes, alternative is very nice.  Yes, it can be done with python:path(),
or by refactoring the expression to an script.  Yes, the alternatives
are harder to read, or more work.  Nu?
I can't think of a way to implement my first example using 
python:path(), though you could certainly do it with a Script.  The 
second example can be awkwardly rewritten by defining exists:data/stat 
and using it in a short-circuiting boolean expression such as have_stat 
and thousands_commas(data.stat) or 'No data.'.  My point is that these 
prefixes allow a degree of precision, when necessary, that is not 
possible in current TALES without totally transforming the expression.

Doesn't it strike you as odd that sometimes the prefix denotes
parameterization, and sometimes it denotes application?
I hope that the list above makes the consistency clearer.

Cheers,

Evan @ 4-am



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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Paul Winkler
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?

 you usually use key: with a dictionary, 
 and item: with a sequence.  The exception is when you have an integer 
 key in a dictionary.

That exception does smell a bit funny... 
having to say here/some_dict/item:0 just feels odd.
But I can't remember ever using integers as dictionary keys so it's 
probably not worth fussing over. :-)

 I hope that the list above makes the consistency clearer.

actually it does help a bit, thanks.
hmm. It's not horrible :-)
I'm just still on the fence about whether we really need it.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's BUTCHER BROMO-BOTTLE CAP!
(random hero from isometric.spaceninja.com)

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Jim Penny
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
  how they differ.
 
 The explanation isn't that hard, at least for a user with a basic 
 knowledge of data structures -- you usually use key: with a
 dictionary, and item: with a sequence.  The exception is when you have
 an integer key in a dictionary.

It is in fact not only hard to teach, it is impossible to use.  Look,
the ZPT programmer has no way of discovering whether the python
programmer has returned a dictionary, a sequence, a Set, or anything
else, much less what the key type is. Introspection is not available to
a ZPT programmer. So, you are back to asking the python programmer, who
just as well do the work. 

And why would I expect a ZPT person to have a basic knowledge of data
structures?

 
  Eeep, gad no.  The python is horrible.  The prefix syntax is equally
  horrible, unfamiliar, and ambiguous!  For example, why does call:
  not have an argument
 
 Because I'm not passing an argument to the SQL statement.  In my 
 implementation, the syntax is call:arg1,arg2,..., where each
 argument is required to be a variable name.  Every prefixed path
 element operates upon the current traversal object, using the argument
 (if any) to the prefix.  Here's a list that demonstrates:
 
 x/key:foo  -- x['foo']
 x/item:0   -- x[0]
 x/attr:foo -- x.foo
 x/call:foo -- x(foo)
 x/var:foo  -- getattr(x, foo) or x[foo] (path traversal semantics)
 x/fmt:%.2f -- '%.2f' % x
 x/fmt:thousands_commas -- thousands_commas(x)
 
  Doesn't it strike you as odd that sometimes the prefix denotes
  parameterization, and sometimes it denotes application?
 
 I hope that the list above makes the consistency clearer.

No, it actually makes it clearer, and worse.  It is an interesting
notation, kind of, but hugely irregular, and that you and Chris are
talking about two quite different semantics on top of a similar syntax
does not help things in the least.

One by one:

key: and item: need to be combined, as they cannot be practically used
by the ZPT programmer as separate entities, due to lack of
introspection.

var: is semantically clear, but I suspect will confuse the hell out
of non-programmers.  

Frankly, and I freely admit that I have not a clue to the
implementational details, I would prefer that key:, item:, and var: all
be a single entity, say index:

x/index:'foo'  --  x['foo']
x/index:span_of_int  -x[span_of_int]
x/index:foo-- x[foo]

call: well, you have said that arguments are allowed, and must be only
variable names.  What is the reason for this?  I assume that only
positional parameters are permitted.  With named parameters, this is the
part I have fewest reservations about.  Is there any reason to avoid
parentheses however?  Does using call: explicitly erase all magic name
bindings  (I hope so)?

Why not x/call:(parameter_list)?

There are several reasons to consider this.  The primary one is that
niladic calls are explicitly marked.  Another reason, again with
niladic calls is that x/call:()/foo makes is more clear that the foo
attribute of x() is being requested, rather than that /foo is an
argument to x.  The final one is that it would probably permit much more
general parameter lists, possibly including constants and/or named
parameters.

attr: looks clean enough.  Combinations of attr: and call: made me think
for a while, but, I don't see any obvious problems.

fmt: is most irregular.  First, it reverses the pattern of all the
others and makes the stuff to the left the parameter.  This may be OK
for your intended audience.  It may also confuse them totally.  Why
x/fmt:%.2f and not x/fmt:'%.2f'?   As it stands, it takes either
expression fragments starting with % or function names.  Can I define my
own functions, if so, how/where?

Finally, can we come up with a better term than prefix.  In conventional
terminology, most of these are infix operations, except call, which may
be a purely postfix.

Jim Penny 





 
 Cheers,
 
 Evan @ 4-am
 
 
 
 ___
 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
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Jim Penny
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 introduce additional punctuation (quotes or parens)

But you've already crossed the Rubicon, :, ',', and % have been
introduced as punctuation (yes, not matched, which does make a
difference)!  I am not opposed to this idea, per se, I am worried about
the fact that it is so slippery slopish, and that it is so non-standard
notationally.

As a add-on product, I would say, go for it!  As core functionality, it
worries me.

Further, this is an engineering trade-off.  You are trading parsing
simplicity by requiring extra programmer awareness - things which a
python programmer is often not consciously aware of.  I am trying to
strongly point this out, so that you are prepared for the inevitable
confusion later.

 if I can help it -- TAL and TALES both have a tradition of
 minimalist syntax, and it keeps parsing simple.  Also, as soon as you
 add delimiters, you add quoting issues, and TALES has enough of those
 already.
 
  call: well, you have said that arguments are allowed, and must be
  only variable names.  What is the reason for this?
 
 To keep things simple.  There's a clearly visible slippery slope here,
 

Yes, but named parameters can be very nice, especially working with
databases, they let you match between form names, which are often very
specific and database column names which are often more generic.

And permitting constants keeps the programmer from an artificial
requirement to define bind a constant to a name just to use it in a
conditional section.

I do understand the parsing issues, and can accept them, although I
really would prefer named parameters be available, even if I have to
give up constants.

I strongly would urge you to use parentheses to denote functional
application.  Yes, I know there are alternative traditions, but they are
much less common in practice.  And the strongest one, RPN, was widely
hated by 'the masses'.

  Does using call: explicitly erase all magic name bindings  (I hope
  so)?
 
 I don't know what you mean, here.
 

Well, grabbing missing parameters from request, and possibly (zope2)
other places.

  fmt: is most irregular.  First, it reverses the pattern of all the
  others and makes the stuff to the left the parameter.  This may be
  OK for your intended audience.  It may also confuse them totally. 
  Why x/fmt:%.2f and not x/fmt:'%.2f'?   As it stands, it takes either
  expression fragments starting with % or function names.  Can I
  define my own functions, if so, how/where?
 
 'fmt' is a quick-and-dirty implementation, and most likely to change. 
 It was almost certainly a mistake to conflate the standard formatting 
 functions with Python string formatting.  I don't agree that it
 reverses the pattern, though -- to me, it's apply *this* formatting
 operation to the current object, much like 'key' is fetch *this* key
 from the current object.

well, even if you persist in the mistaken ;-) notion that it is
written key:
x/key:y  -- x[y]
x/call:y -- x(y)
x/fmt:y  -- y(x)

'one of these things is not like the others...'

  Finally, can we come up with a better term than prefix.  In
  conventional terminology, most of these are infix operations, except
  call, which may be a purely postfix.
 
 'prefix' refers to the syntax, not the operations.  In my source code 
 comments, I refer to prefixed path elements.  A better name would be
 welcome :-)

Hmm, maybe 'decorated path'.  I am worried that prefix, postfix, and
infix already have meaning, and this is more an infix language than a
prefix language.

But, I lost on 'snake thingy', so I will lose here to  :-(

Jim Penny

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Chris Withers
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 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 API
This rocks from my perspective :-)

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 )


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Chris Withers
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 implementation in Zope 3's TALES engine doesn't rely on Adapters, take a 
look :-)

cheers,

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 )


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Chris Withers
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 methods.  This would allow 
options/a_mapping/key:items/index:0 rather than 
python:options['a_mapping']['items'][0].
What an extraordinarily good idea! Why has none of us thought of this before?

Like it :-)

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 )


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread 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? 
Personally, I find it much easier to read...

I wonder what non-python'ers would think?


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?
For me, that would be ideal...

I really think that's a mistake.
What leads you to believe that?

cheers,

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 )


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread robert
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?

 Personally, I find it much easier to read...

 I wonder what non-python'ers would think?

For casual ZPT users and newbies it is confusing to use two different 
notations for doing the same

For this group of users the modification as proposed would be great.
-- 
mit freundlichen GrĂ¼ssen

Robert Rottermann
www.redCOR.ch


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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Paul Winkler
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? 
 
 Personally, I find it much easier to read...

I find the opposite:

Assuming that the reader understands python, s/he has to
perform the mental translation anyway in order to understand
how this expression uses the objects it refers to.

Assuming that the reader does NOT understand any python, 
it doesn't make much sense. The immediate questions arise: What's a 
key? What's an index? What's the difference between them? 
How do I know when to use one or the other?
And, how do you answer those questions without talking about
python data structures?

 I wonder what non-python'ers would think?

well, that's a very good and relevant question, but I doubt
we will find them on this mailing list :-)
I would really like to know.

 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?
 
 For me, that would be ideal...
 
 I really think that's a mistake.
 
 What leads you to believe that?

The appeal of TALES path expressions lies in their simplicity.
I don't want them to feature-creep into a general purpose 
programming language. The more complex these expressions get, the more 
work a zope developer (e.g. someone developing new content types, 
services, etc.) has to expend on mentally translating between different 
languages, which is always an opportunity to get something wrong
as we've already discussed.  We all know that Python has a near-unbeatable
record as an easy-to-use, well-designed, and downright fun language.
It has a great reputation as a first language.  These new proposals for 
TALES path expressions do not have any such track record, so I am
naturally skeptical that they are going to beat python at one of its
strengths: readability and novice-friendliness.

Consider what happened with Zope 2 and DTML: the templating
language had enough features that novice developers often got themselves
into trouble by writing excessively complex templates with embedded
logic. The zope 2 tutorial and most other available documents gave the
impression that you didn't need to learn python to get things done
in Zope. Since the addition of ZPT and Python Scripts, things have
improved enormously; but I remember a time when the [EMAIL PROTECTED] list 
was full of questions like how do I do my complex task in DTML. 
It was easy to get your feet wet, and without clear  explicit ways
to use python, it was easy to fall off the continental shelf where 
suddenly nothing worked anymore and nothing made sense.  

So I am very wary of ZPT becoming Son of DTML From Hell,
and that's what the proposed extensions smell like to me.

To frame it as a practical question: how is the template author going to 
get something non-trivial done? 

Assuming that TALES python expressions are banned/discouraged/whatever, 
there are 3 choices:

1) The template author writes some auxiliary python code 
(whether this is a script or a Product or a Persistent Module or 
whatever). This is the case most familiar to me - I'm usually doing 
most of my work alone.  In this case the author has to know both 
ZPT and python - but not both in the same document. 

2) Stretch the capabilities of the template language so that no
python is necessary anywhere.
I think we agree that *currently* this is bad practice, when it's
even possible.

3) Get somebody else to write the python code, and just
refer to the code objects with TALES path expressions.

This is what I think you are suggesting - yes? no?
It's hard for me to imagine working strictly in this fashion, because 
in my limited experience I've never worked that way and I don't know 
anybody who does.  *Do* people actually work this way?  If you don't 
know any python, isn't it tempting to write some icky template code 
yourself instead of waiting for the code guy to have time to help you?

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's USELESS MEGA BOY!
(random hero from isometric.spaceninja.com)

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Jim Penny
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 rather than 
  python:options['a_mapping']['items'][0].
  
  Why is that an improvement? 
  
  Personally, I find it much easier to read...
 
 I find the opposite:

Neither is easy to read.  Go to your nearest non-programmer unit,
spousal, parental, whatever.  Watch the My Eyes Glaze Over, (MEGO)
phenomenon take immediate effect.

 
 Assuming that the reader does NOT understand any python, 
 it doesn't make much sense. The immediate questions arise: What's a 
 key? What's an index? What's the difference between them? 
 How do I know when to use one or the other?
 And, how do you answer those questions without talking about
 python data structures?

I agree with Paul here.  I hated the int: because it had nothing to do
with indexing.  I could reluctantly accept index: -- but it will not
help the intended audience.  Only programmers understand things like
indices, keys, etc.  What is worse, is that it builds a bunch on
un-pythonic syntax, which will get in the way of learning python later.

Let ZPT handle the simplest things, and escape to python as needed.

Lo, ZPT has not even a proper expression syntax.  All that is going on
here is creating a syntax for some extremely limited special cases, a
really non-standard syntax.  And, the syntax depends on having some
python programmer create the dictionaries or sequences that are being
referenced.

That to me, is the fatal flaw.  It is hard to argue, on one hand, that a
python programmer is available to you whenever you need a sequence
created, and on the other hand, that he is no longer there to
consult/hand work off to when a simple expression is needed.

Jim Penny

___
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] Re: TALES idea: tuple unpacking

2003-07-29 Thread Evan Simpson
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:', 'key:', 'item:', 
'attr:', and 'fmt:' with which the snippet:

div tal:define=foo string:*foo*;
 seq python:('arg', 3.4);
 map python:{'*foo*': 'yes', 'keys': 'skeleton'}
  div tal:content=seq/item:0/div
  div tal:content=seq/item:1/fmt:%.2f/div
  div tal:content=template/attr:title/div
  div tal:content=here/key:test3/title/div
  div tal:content=structure foo/fmt:structured_text/div
  div tal:content=map/key:keys/div
  div tal:content=map/var:foo/div
/div
...produces:

div
  divarg/div
  div3.40/div
  divMy Title/div
  divMy Title/div
  divpemfoo/em/p
/div
  divskeleton/div
  divyes/div
/div
You can try it out with the following commands in your 
$ZOPE/lib/python/Products/PageTemplates/ directory:

cvs -q up -r evan-pathprefix-branch PathPrefixes.py
cvs diff -r evan-pathprefix-branch-0 -r evan-pathprefix-branch \
  -u Expressions.py | patch
Cheers,

Evan @ 4-am

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Christopher Boomer
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 no simplification from one
to the other.  If it is easy to do and shall not impact on the performance
of  TAL, then go ahead and do it.  Otherwise, leave it alone.  If you have
enough knowledge to create the first one, you can certainly generate the
second.  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.

Often I solve the problem by using a tal:define, which allows the following
TAL to cope with the variables I am trying to throw at it.  In general this
is my rule:  do not ask TAL to cope with expressions outside of a define
statement.  Let it stick with truth and looping, which it is exceptionally
good at.

Chris What an extraordinarily good idea! Why has none of us thought of this
before?

Because it's so extraordinarily /not new/, in the sense that it might be
handy when everything else is working but remains unnecessary otherwise.  I,
for one, remain opposed to the idea that there should be several ways to do
the same thing, just because the newer one looks a bit prettier.  Newcomers
spend time choosing between them to avoid developing a ZClass when they need
a Product.  Especially when the difference is purely syntactic, nobody
bothers to write down that they are purely equivalent.

Chris I wonder what non-python'ers would think?
Paul well, that's a very good and relevant question, but I
Paul doubt we will find them on this mailing list :-)
Paul I would really like to know.

I am a relevant newcomer who is getting confused by all the options.  I have
avoided learning DTML beyond recognising it when I see it, but still find
the whole experience quite bewildering at times.  It took me the months of
UML work to convince my colleague (and introducer) that DTML was a backward
step, and only on presenting him with the hard-to-find zpt2dtml conversion
guide did I finally make my point that everything was possible without DTML
and its implicit acquisition.

For my money, get someone to spend time documenting option one first, and
explaining why it is useful; then make option two work if there is still
demand.  It's less sexy, but much more productive.

For instance, I spent a long time under the misapprehension that 'options/'
was the only way to get python variables into templates, because that's how
it shows you in the ZDG.

You have an excellent product that is far more powerful than people have
realised.  shoutKeep up the good work!/shout whisperwhich might mean
more marketing (documenting) and less programming/whisper

Paul We all know that Python has a near-unbeatable record
Paul as an easy-to-use, well-designed, and downright fun language.
Paul It has a great reputation as a first language.
I think this is overstating things a little.  I came to Zope/python from a
background in perl-based Intershop4 and found the transition hard enough.  I
had printed out the 80 page reference manual before I discovered that it
contained not a single python command: only on returning to it after eight
months did it begin to make sense, yet wonderful features such as __call__
should be carefully documented as important in Zope Products.

Paul The zope 2 tutorial and most other available documents gave
Paul the impression that you didn't need to learn python to get things
Paul done in Zope.
The Zope Book gives the impression that DTML is a poor-man's substitute to
ZPT/python, which is why I did not spend time on it.  It actually left me
with the impression that DTML and python did not really get on.

Paul If you don't know any python, isn't it tempting to write some
Paul icky template code yourself instead of waiting for the code
Paul guy to have time to help you?
That's exactly why I wrote custom templates for Intershop 4.  It did not
support search-within-search, or search-within-category, yet it was clear
from the database schema that it should and could with little effort.
Luckily the only way to do it was to create the object in advance from the
database and loop over it in the presentation.  Those of you interested in
options/a_mapping/key:items/index:0 would like their approach.

Incidentally, and off topic.  I read somewhere here that Zope3 is abolishing
implicit acquisition.  What should a developer be doing /now/ to avoid
obsolescence?  Should we use .Explicit throughout for new products, or what?
And what does that mean exactly?  It's not really documented in the ZDG
(maybe a page and a bit),
and specifically says (Ch. 3) In general you should subclass from
Acquisition.Implicit unless you have a good reason not to.  Is Zope3 that
good reason?


MfG
Christopher Boomer,
Belfast.


___

Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Shane Hathaway
[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 Python.  The issue is deeper than that.  I'll explain below.

[Paul Winkler]
Assuming that TALES python expressions are banned/discouraged/whatever, 
[...]
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) or c.../div
However, the following is quite bad:

tal:x define=ss nocall:modules/Products/PythonScripts/standard
 a tal:attributes=href python: ss.url_quote(some_url) /
/tal:x
This is un-Pythonic in numerous ways.

- You can't use the import statement.  In fact, you can't use any 
statements at all--only expressions.

- The nocall: prefix.

- The name 'modules' is present automatically along with many other 
names that aren't in the Python builtins namespace.

- Importing using a path expression.

- Binding a variable to a value without an equal sign.

- You have to prefix Python expressions with python:.

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

Zope 2's method of slightly simplifying this is to write a two-line 
script and find it through implicit acquisition.  The overhead of 
invoking a script is somewhat large, but here's what the template would 
look like anyway.

a tal:attributes=href python: here.url_quote(some_url) /

Zope 3 will not have implicit acquisition.  In fact, no system but Zope 
2 has implicit acquisition.  That leaves us with no possible way to 
write the above statement in non-implicit Python!  No matter what you 
do, you need some help from another kind of expression.  Until recently, 
here was the way to write it in Zope 3.

tal:x define=url_quote nocall:here/++acquire++url_quote
  a tal:attributes=href python: url_quote(some_url) /
/tal:x
That alternative is just as complicated and un-Pythonic as importing a 
module in a template.  I can't think of a better way to write this given 
the limitations of Zope 2 ZPT, without the giant implicit acquisition 
band-aid.  Can you?

Zope 3's new alternative looks about like this:

a tal:attributes=href here/format:url_quote /

To me, that's a vast improvment, and it's only one example.

You know what was actually wrong with DTML?  The lack of Python Scripts. 
 Without Python Scripts, everyone used DTML as a programming language. 
 Once Python Scripts came around, DTML became a reasonable templating 
language again.  If DTML used TALES expressions, it would be just as 
clean as ZPT.

Shane

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Fred L. Drake, Jr.

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 a clear understanding of layers of
encoding (a seriously unfortunate state of affairs, though
understandable given the time pressures of creating/updating a site).
Encoding quotes inside an attribute values means that the expression
(Python or not) is harder to read, but if it doesn't still work,
there's a bug in the implementation.  I'll be glad to donate some of
my time to fix any such bugs.

Othan than this, I agree with you on this topic.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Jim Penny
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 a mistake.
 
 Guys, that line of thinking is a distraction.  ZPT authors ought to 
 learn Python.  The issue is deeper than that.  I'll explain below.
 
 [Paul Winkler]
  Assuming that TALES python expressions are
  banned/discouraged/whatever, [...]
 
 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) or c.../div
 
 However, the following is quite bad:
 
 tal:x define=ss nocall:modules/Products/PythonScripts/standard
   a tal:attributes=href python: ss.url_quote(some_url) /
 /tal:x

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.

 
 This is un-Pythonic in numerous ways.

snip

 a tal:attributes=href here/format:url_quote /
 
 To me, that's a vast improvment, and it's only one example.
 
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 reference, both have form structure[key].

Jim Penny

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Shane Hathaway
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 web developers don't have a clear understanding of layers of
encoding (a seriously unfortunate state of affairs, though
understandable given the time pressures of creating/updating a site).
Encoding quotes inside an attribute values means that the expression
(Python or not) is harder to read, but if it doesn't still work,
there's a bug in the implementation.  I'll be glad to donate some of
my time to fix any such bugs.
Othan than this, I agree with you on this topic.
I'm not quite sure what you're saying.  The following fails compilation:

span tal:content=python: abc /

Hence you need to be careful not to use double quotes in expressions.  I 
run into this every day.

I'm a little wary of expressions like this:

span tal:content=python: 1  0 /

... being converted by buggy XML or HTML software to this (I've seen it 
happen before):

span tal:content=python: 1 gt; 0 /

Finally, if you use a pair of hyphens in an expression and later use XML 
syntax to comment it out while leaving the pair of hyphens, the block is 
technically not well-formed.

http://www.w3.org/TR/REC-xml#sec-comments

For example:

!--
span tal:content=python: 'What should we do--walk or run?' /
--
This is not something that should bother anyone, but I wanted to support 
my assertion. ;-)

Shane

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Paul Winkler
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 solve the problem by using a tal:define, which allows the following
 TAL to cope with the variables I am trying to throw at it.  In general this
 is my rule:  do not ask TAL to cope with expressions outside of a define
 statement.  Let it stick with truth and looping, which it is exceptionally
 good at.

this sounds like good practice.

 for one, remain opposed to the idea that there should be several ways to do
 the same thing, just because the newer one looks a bit prettier.

Yes... a very pythonic philosophy... let's not turn TALES into Perl ;-)

 Chris I wonder what non-python'ers would think?
 Paul well, that's a very good and relevant question, but I
 Paul doubt we will find them on this mailing list :-)
 Paul I would really like to know.
 
 I am a relevant newcomer who is getting confused by all the options.  I have
 avoided learning DTML beyond recognising it when I see it, but still find
 the whole experience quite bewildering at times.  It took me the months of
 UML work to convince my colleague (and introducer) that DTML was a backward
 step, and only on presenting him with the hard-to-find zpt2dtml conversion
 guide did I finally make my point that everything was possible without DTML
 and its implicit acquisition.

hmm, well to be clear, you're still using implicit acquisition if you say

span tal:content=here/foo ... /span

... and foo is not in the same folder as the template.
However, TAL is much better about using explicit namespaces
(here, template, container, request) instead of DTML's habit of dumping
them all in one pile. Also explicitly saying python: when you're writing
a python expression, instead of just using quotes. Newbies to DTML
often used to talk about the funny quote syntax, not realizing
it was python.

 Paul We all know that Python has a near-unbeatable record
 Paul as an easy-to-use, well-designed, and downright fun language.
 Paul It has a great reputation as a first language.

 I think this is overstating things a little.

If Zope is your first exposure to Python, I'm not sure if you can
appreciate what I mean. :-)

 I came to Zope/python from a
 background in perl-based Intershop4 and found the transition hard enough.

Sure, but I think a lot of that is due to the inherent size and complexity
of Zope.  Have you ever written some small standalone programs in python?
Try it, you'll like it :-) I came to zope from python scripting and I 
still found it a hard transition: I had to learn the management interface,
DTML, acquisition, the security model, how to use the Catalog, how to 
create a product, etc etc.  And believe me, it was harder before Python 
Scripts were added.

 I
 had printed out the 80 page reference manual before I discovered that it
 contained not a single python command: 

reference manual? which one? The Zope Book? (a fair amount of python
is in it these days.) ZOpe Developers' Guide? (lots of python there.)

 Paul The zope 2 tutorial and most other available documents gave
 Paul the impression that you didn't need to learn python to get things
 Paul done in Zope.

 The Zope Book gives the impression that DTML is a poor-man's substitute to
 ZPT/python, which is why I did not spend time on it.  It actually left me
 with the impression that DTML and python did not really get on.

Hm, maybe we overstated things a bit in the book. :-)
DTML and python get along fine; dtml-in some_python_script is 
much the same as tal:repeat=item some_python_script.

I think DTML is fine as long as you 
- don't need to edit it with a WYSIWIG tool
- don't use the python expression syntax because it's horrid :-)

and some people prefer the fact that it's generally less verbose than
ZPT.

 Incidentally, and off topic.  I read somewhere here that Zope3 is abolishing
 implicit acquisition.  What should a developer be doing /now/ to avoid
 obsolescence?  Should we use .Explicit throughout for new products, or what?
 And what does that mean exactly?  It's not really documented in the ZDG
 (maybe a page and a bit),
 and specifically says (Ch. 3) In general you should subclass from
 Acquisition.Implicit unless you have a good reason not to.  Is Zope3 that
 good reason?

Big topic. This may help, though it's currently just an outline:
http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PortingApplications

The basic approach that's been suggested is:

- Write as much as possible of your product's features in a class
that doesn't inherit from *any* zope-specific base classes.

- Create a wrapper or derived class that lets you use your class with zope 2.

Note that this approach also makes unit testing easier, though you
may need to provide stub implementations of other things that

Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Shane Hathaway
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 acquisition.  Your example is not 
deprecated, it just won't work. :-)  Now, if you made a view component, 
you could get it to work, but that pattern would be very different from 
Zope 2.

But, what does all of this have to do with index:, key:, int:, etc.?
The issue at hand is whether to use prefixes at all.  That's the way I 
understand it, anyway.

Shane

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Fred L. Drake, Jr.

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: 'abc' /

I think the problem is that it's easy to think of TAL as little bits
of different syntaxes, but that's not actually what's happening.  The
syntaxes are layered on top of each other, and where there are
characters meaningful to more than one layer, they have to be encoded
so they are interpreted by the proper layer.

  Hence you need to be careful not to use double quotes in expressions.  I 
  run into this every day.
  
  I'm a little wary of expressions like this:
  
  span tal:content=python: 1  0 /
  
  ... being converted by buggy XML or HTML software to this (I've seen it 
  happen before):
  
  span tal:content=python: 1 gt; 0 /

That's not buggy; that's what you should have written to start with.

  Finally, if you use a pair of hyphens in an expression and later use XML 
  syntax to comment it out while leaving the pair of hyphens, the block is 
  technically not well-formed.
  
  http://www.w3.org/TR/REC-xml#sec-comments
  
  For example:
  
  !--
  span tal:content=python: 'What should we do--walk or run?' /
  --
  
  This is not something that should bother anyone, but I wanted to support 
  my assertion. ;-)

That's life.  If you change the document, you may have to change
context.  If you want to make it possible to enclose something in a
comment, you have to encode your content differently.  For the double
hyphen, encode at least one of them like so:

!--
span tal:content=python: 'What should we do#45;-walk or run?' /
--

In general, I'd recommend using a syntax-highlighting editor to help
detect this one early, or even a proper XML editor for those who can
tolerate them.

I hope this makes sense as I've described it.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

___
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] Re: TALES idea: tuple unpacking

2003-07-29 Thread Evan Simpson
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 reference, both have form structure[key].
I proposed distinct key: and item: in order to kill some implicit magic 
before it was born:

x/key:0 is the same as python:x['0'], while x/item:0 is the same 
as python:x[0].

It seems clear to me that subpath prefixes are going to be part of Zope 
3, no matter how opinion on this thread goes.  It wasn't hard to 
implement them for Zope 2, and I find them useful.  While I agree that 
someone who can deal well with x/item:0 will have no problem with 
python:x[0], I also assert that many such people would join me in 
prefering options/lib/data/my.sql/call:/item:0/state to 
options['lib'].data['my.sql']()[0].state if only because the former 
allows me to specify access methods *only* for the exceptions to the 
norm, not for every path step.  If that isn't valuable, what about path 
expressions is?

I also offer for general consideration the following:

options/foo/item:0 | request/foo/item:0 | default
data/stat/fmt:thousands_commas | string:No data.
Python expression equivalents, please?

Cheers,

Evan @ 4-am



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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Paul Winkler
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) or c.../div

ok.

 However, the following is quite bad:

And quite common :-)  Browse through some of the CMF skins...

  tal:x define=ss nocall:modules/Products/PythonScripts/standard
  a tal:attributes=href python: ss.url_quote(some_url) /
 /tal:x
 
 This is un-Pythonic in numerous ways.
 
 - You can't use the import statement.  In fact, you can't use any 
 statements at all--only expressions.

 - The nocall: prefix.

 - The name 'modules' is present automatically along with many other 
 names that aren't in the Python builtins namespace.

 - Importing using a path expression.

agreed on all 4.  although, import is the only time I miss statements.

 - Binding a variable to a value without an equal sign.

That took some getting used to.  I don't know why this was
chosen, but it seems a bit late to change it now.

 - You have to prefix Python expressions with python:.

That's a feature! If we didn't have that, how would you know the
difference between
   tal:replace=a/b 
and
   tal:replace=python:a/b

 Zope 2's method of slightly simplifying this is to write a two-line 
 script and find it through implicit acquisition.  The overhead of 
 invoking a script is somewhat large, but here's what the template would 
 look like anyway.
 
 a tal:attributes=href python: here.url_quote(some_url) /

yes, this is about the best you can do currently. In fact,
I quite like it. :)  

 Zope 3 will not have implicit acquisition.  In fact, no system but Zope 
 2 has implicit acquisition.  That leaves us with no possible way to 
 write the above statement in non-implicit Python!  No matter what you 
 do, you need some help from another kind of expression.  Until recently, 
 here was the way to write it in Zope 3.
 
 tal:x define=url_quote nocall:here/++acquire++url_quote
   a tal:attributes=href python: url_quote(some_url) /
 /tal:x
 
 That alternative is just as complicated and un-Pythonic as importing a 
 module in a template.  I can't think of a better way to write this given 
 the limitations of Zope 2 ZPT, without the giant implicit acquisition 
 band-aid.  Can you?
 
 Zope 3's new alternative looks about like this:
 
 a tal:attributes=href here/format:url_quote /

Where do you put the argument? I don't see some_url.

 To me, that's a vast improvment, and it's only one example.

It also raises some new questions that are about
on par with what would be needed to understand the zope 2 version: 
What kind of thingie is format:? Where can I find it if I want 
to learn what else it can do?  What do I do if I want 
format:some_custom_format?  How could I replace or augment
the format thingie and not break any template that uses it?

Not that it's bad to raise these questions ... I just want to point
out that the answers are far from self-evident.

 You know what was actually wrong with DTML?  The lack of Python Scripts. 
  Without Python Scripts, everyone used DTML as a programming language. 
  Once Python Scripts came around, DTML became a reasonable templating 
 language again.  If DTML used TALES expressions, it would be just as 
 clean as ZPT.

I think I just said this in another post :)

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's MUZZY ANTIDISESTABLISHMENTARIANISTIC FJUKER!
(random hero from isometric.spaceninja.com)

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Jim Penny
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. 
  That is, an integer indexed reference looks exactly like a string
  indexed reference, both have form structure[key].
 

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.

 I proposed distinct key: and item: in order to kill some implicit
 magic before it was born:
 
 x/key:0 is the same as python:x['0'], while x/item:0 is the same
 
 as python:x[0].
 
 It seems clear to me that subpath prefixes are going to be part of
 Zope 3, no matter how opinion on this thread goes.  It wasn't hard to 
 implement them for Zope 2, and I find them useful.  While I agree that
 
 someone who can deal well with x/item:0 will have no problem with 
 python:x[0], I also assert that many such people would join me in 
 prefering options/lib/data/my.sql/call:/item:0/state to 
 options['lib'].data['my.sql']()[0].state if only because the former 
 allows me to specify access methods *only* for the exceptions to the 
 norm, not for every path step.  If that isn't valuable, what about
 path expressions is?

Eeep, gad no.  The python is horrible.  The prefix syntax is equally
horrible, unfamiliar, and ambiguous!  For example, why does call: not
have an argument, is it because my.sql is niladic, or is it that
'/item:0/state' is the argument?  Is
options/lib/data/call:my.sql/item:0/state equivalent?  Are parameters
magic?  If not, how are they discovered?

 
 I also offer for general consideration the following:
 
 options/foo/item:0 | request/foo/item:0 | default
 data/stat/fmt:thousands_commas | string:No data.
 
 Python expression equivalents, please?

Yes, alternative is very nice.  Yes, it can be done with python:path(),
or by refactoring the expression to an script.  Yes, the alternatives
are harder to read, or more work.  Nu?

The syntax has kind of odd denotation, on top of everything else.  The
item:0 applies the integer indexing operator to the options['foo'] which
must be a sequence type with parameter 0?  (I thought that was index: )

The fmt:thousands_commas construct applies the thousands_commas operator
with parameter data['stat']?  

Doesn't it strike you as odd that sometimes the prefix denotes
parameterization, and sometimes it denotes application?

 
 Cheers,
 
 Evan @ 4-am
 
 

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Jim Penny
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 not realize that this is deprecated in Zope3.
 

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
than container does! So, I try never to use it.

Jim Penny




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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-29 Thread Richard Jones
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 how it works in 
practise...


   Richard


pgp0.pgp
Description: signature


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-25 Thread Shane Hathaway
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 presenting HTML on 
the client side.  Yet browsers can't perform all of the logic, so some 
presentation logic has to exist on the server side.

Instead, two things are important: distinguishing presentation from the 
model and keeping syntax simple.  Python expressions in templates rarely 
violate the first principle because they are not part of the model. 
(Contrast this with PHP, where the model exists only in the 
presentation.)  Complex expressions violate the second principle because 
the syntax becomes unwieldy.

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 is cooking up.
The templates he proposes have only two or three attributes, keeping 
logic rigorously out of the template.
I like the idea.  It's a novel approach.  It may be oversimplifying, 
though, and the danger of oversimplifying is that some other part 
acquires extra complexity to compensate.  For example, if we were to ban 
Python expressions outright in ZPT, it would become necessary to 
compensate by writing at least one Python script per template that used 
to have expressions.  In a product I'm maintaining for a customer, that 
would be a very big burden.

Shane

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-24 Thread Jean Jordaan
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 
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 is cooking up. 

The templates he proposes have only two or three attributes, 
keeping logic rigorously out of the template.

--
Jean Jordaan
http://www.upfrontsystems.co.za
___
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 )


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-24 Thread Paul Winkler
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 is cooking up. 
 
 The templates he proposes have only two or three attributes, 
 keeping logic rigorously out of the template.

Very interesting idea. Here's an excerpt:


I think that ZPT still embed code in a web page, and that there's a better 
alternative.  If you've seen PSO (pso.sf.net), Twisted's Woven, or even JSP 
taglibs (though that's a bit of a stretch), you'll have a better idea of 
what PWT (peak.web.templates) looks like.  Here's an example, straight from 
the test suite:

body
  h1 model=foo view=textTitle Goes Here/h1
  ul model=bar view=list
li pattern=listItem view=text/li
  /ul
/body

'view' attributes identify the object factory used to create the tag, 
'model' attributes are a path to the data to be used, and 'pattern' 
attributes identify parameters that are supplied to the nearest containing 
'view', rather like a METAL macro slot (except that views are written in 
Python, rather than being templates, although I intend to make it possible 
to use a template as a view, too).  Views are looked up in a property 
namespace so you can configure access to arbitrary view components that 
your app (or anybody else) supplies


I don't totally grok it (an object factory creates a tag?
does he mean the contents of the tag? and since they're factories written
in python shouldn't they be called something other than 'views'? like
maybe 'factory'??).  But, odd terminology aside, it's compellingly simple. 
I guess that the 'view' and the 'model' only have to agree on an 
interface ('pattern' names).

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's DEPUTY SHERIFF OF JUSTICE!
(random hero from isometric.spaceninja.com)

___
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] Re: TALES idea: tuple unpacking

2003-07-23 Thread Philipp von Weitershausen
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 
be able to::

   tal:repeat=user,files here/listFilesByUser

or similar. Currently we would have to use a python: expression to manually 
unpack the tuple. Kinda yucky.
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 /
File: tal:dummy replace=user_files/1 /
  /tal:block
Regards,

Phil



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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Shane Hathaway
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 /
File: tal:dummy replace=user_files/1 /
  /tal:block
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
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 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 API
It sure would be nice to have these prefixes, both in Zope 2 and Zope 3.

Shane

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Tino Wildenhain
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 replace=user_files/0 /
File: tal:dummy replace=user_files/1 /
  /tal:block


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
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 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 API
It sure would be nice to have these prefixes, both in Zope 2 and Zope 3.
Hm. But then would we not be better of using python: expressions in the 
first place? Seems to save a lot of typing.
I'd better like to build up lazy complex objects with python scripts
to pass to ZPT, I think this would make more sense.
Imagine instead of returning lists of dictionaries with all precalculated
values you return list of objects with real methods to calculate 
attributes on demand. (Yes, sounds like ZPatterns, but may be
a more easy interface)

Regards
Tino
___
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 )


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Philipp von Weitershausen
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 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 API
+1

It sure would be nice to have these prefixes, both in Zope 2 and Zope 3.
AFAIK, Jim wants this for Zope3 for some time now. The idea is to 
implement this with named adapters.

here/some_object/zope:name would make TALES look up the 'zope' adapter 
(something that implements zope.app.interfaces.talesapi.IZopeTalesAPI) 
and get its name attribute/call its name() method. It would really be a 
two-liner to implement something like an 'int' or 'call' adapter. Other 
named adapters like 'dc' that adapts an object to a Dublin Core 
interface would be nice to have as well. A lot of that is in place 
already, fortunately.

The question remains how to implement this in Zope2 as we don't have 
adapters there.

Philipp

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Jean Jordaan
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 to see 
how that pans out, instead of teasing the current ZPT to creep 
after features.

That said (he continues blithely), the one bit about the current
one that bugs me is the behaviour of callables in path expressions.
This is the one I like::
 tal:define=value here/func/dict-returned-by-func/key
 tal:define=value here/obj/method/returned-dict/key
 tal:define=value here/dict/key/obj-stored-under-key/method
That's the one with the downer that func can't get parameters. 
I'm totally fine with that. For parameters:: 

 tal:define=dict python:here.func('parameter'); 
 value dict/key

--
Jean Jordaan
http://www.upfrontsystems.co.za
___
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 )


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Shane Hathaway
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 API
It sure would be nice to have these prefixes, both in Zope 2 and Zope 3.


Hm. But then would we not be better of using python: expressions in the 
first place? Seems to save a lot of typing.
How is it less typing to write a Python expression?

I'd better like to build up lazy complex objects with python scripts
to pass to ZPT, I think this would make more sense.
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 necessary to write a Python script or expression every 
time you want to format the number 5 as $5.00.

Shane

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Jim Penny
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 to overused
for this.  If you must, why not index:  ?

Jim Penny

 format: -- Perform simple formatting operations like format:money
 zope:   -- Access a big Zope API
 
 It sure would be nice to have these prefixes, both in Zope 2 and Zope
 3.
 
 Shane
 

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Jean Jordaan
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 never to need to deal with but will have to swallow sometime
willy nilly, and that no-one could think of anything better in that
case :|
--
Jean Jordaan
http://www.upfrontsystems.co.za
___
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] Re: TALES idea: tuple unpacking

2003-07-23 Thread Evan Simpson
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 (using 'items' as a dictionary key bites me 
regularly).  This suggests the following prefixes:

'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 methods.  This would allow 
options/a_mapping/key:items/index:0 rather than 
python:options['a_mapping']['items'][0].

There's an alternative, longer syntax that would be more consistent with 
the adapter concept from Zope 3.  Given that prefixes are meant to be 
namespaces, 'key', 'index', and 'attr' should be elements of a namespace 
(perhaps 'by' or 'as' to keep it reasonably short) rather than prefixes 
themselves.  In this case, we would have the path expression 
options/a_mapping/by:key/items/by:index/0.  Note that this form has 
the advantage of allowing a_list/by:index/?i.

Cheers,

Evan @ 4-am



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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Paul Winkler
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 generally available.

What bothers me is the tendency in z2 to improve one tool with 
little features that would be nice to have, adding functionality 
that is either not provided elsewhere, or is provided elsewhere in a 
totally different way. So please, if there's new functionality
you want to add, consider: how would I use this
functionality from a script? from dtml? from a product?

 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 necessary to write a Python script or expression every 
 time you want to format the number 5 as $5.00.

No script needed, and I *like* that zpt encourages python
expressions. Makes it easy to refactor things out into Scripts when 
you realize that your page template is doing too much work.

In this case, the expression you need is documented
(although it really needs an explicit example) in the Zope Book,
API Reference:

span tal:define=pss modules/Products/PythonScripts/standard
  div tal:content=python:pss.dollars_and_cents(5.0)
   $1.00
  /div
/span

You could argue against the define at the beginning, but I think of
those as being analogous to python import statements:
before I get started, I'm going to give myself convenient access
to the stuff I need.

You could also argue that we need a non-US-centric currency formatter,
and I agree; but I say again that we need it everywhere and not only via
some special syntax in ZPT.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's OUR ROCKET PERVERT!
(random hero from isometric.spaceninja.com)

___
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] Re: TALES idea: tuple unpacking

2003-07-23 Thread Philipp von Weitershausen
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.

This suggests the following prefixes:

'key:' -- use item access with the prefixed string.
'index:' -- use item access with the prefixed integer.
'attr:' -- use attribute access with the prefixed string.
+1

There's an alternative, longer syntax that would be more consistent with 
the adapter concept from Zope 3.  Given that prefixes are meant to be 
namespaces, 'key', 'index', and 'attr' should be elements of a namespace 
(perhaps 'by' or 'as' to keep it reasonably short) rather than prefixes 
themselves.  In this case, we would have the path expression 
options/a_mapping/by:key/items/by:index/0.
*ugh*. Too long. You'd keep adding thousands of elements to your TALES 
expression...

Note that this form has the advantage of allowing
a_list/by:index/?i.
Why wouldn't that be possible with a_list/index:?i?

Phil

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Fred L. Drake, Jr.

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 all names look like integers.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Shane Hathaway
(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 attribute, index, or key access 
on several occasions (using 'items' as a dictionary key bites me 
regularly).  This suggests the following prefixes:

'key:' -- use item access with the prefixed string.
'index:' -- use item access with the prefixed integer.
'attr:' -- use attribute access with the prefixed string.
I agree, index: is better.  I had a mental block that made me think of 
only item:, which would be ambiguous.

Shane

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Paul Winkler
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...

 options/a_mapping/by:key/items/by:index/0.

do you find this easier to read or write than the python version?

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.

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's RED ORIGAMI SNOWMAN!
(random hero from isometric.spaceninja.com)

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Fred L. Drake, Jr.

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 syntax for a web
developer to learn.

I'm not necessarily one of them, but I am sympathetic with that
reasoning.


  -Fred

-- 
Fred L. Drake, Jr.  fred at zope.com
PythonLabs at Zope Corporation

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Paul Winkler
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
 reasoning.

I'm definitely not one of them. I am sympathetic with the impulse
- don't place too many burdens on the web developer - but I think that
in this case it's misguided. I don't mean to be harsh, but
I feel very strongly about this:

I think it is wrong to think that one can be an effective web developer 
with zope and never have to write a single python expression.
WHen I started using zope, lots of people were trying to build
entire applications with nothing but DTML and propertysheets
and the like. The result was some really horrid DTML.
I am still maintaining some of this gunk, and I'm really looking
forward to the day I can finally rewrite our oldest running zope apps.

The solution to DTML-from-hell was to refactor the logic into scripts 
written in - guess what - python. This is now widely regarded as 
best practice for quick through-the-web scripting and site development 
in zope.

I always thought that one of the key design goals for TAL/TALES was to
be very minimal and *force* the developer to offload anything difficult 
into python.  I think ZPT is successful partly because of this feature.

My concern is that ZPT will grow so many conveniences that it will 
become easier to abuse it in the same way that DTML has been 
widely abused. New zope developers will then be more tempted to
avoid python (i don't have time to learn another language) and
with the best intentions will do themselves a serious disservice: 
a lot of things will still be unnecessarily difficult compared to 
using python, and a lot of logic will be in templates where it 
doesn't belong.


-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's LORD MC-FJUKER!
(random hero from isometric.spaceninja.com)

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Dieter Maurer
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 necessary to write a Python script or expression every 
  time you want to format the number 5 as $5.00.

I use TALES since its beginnings and I never needed a monetary format.

We will end up with TALES as a huge monster.

I am sure, both of us (and many others) will be able to cope with this monster
and take advantage of its many features as we did, for example, with
the myriads of attributes for dtml-var and dtml-in.
However, many others will be overwhelmed by the vast set of options.

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 am with you for your macro argument proposal as it makes
METAL much easier to understand and more explicite.
I would like to get some documentation facility to be able to
document macros, again to make them clearer and easier to maintain.
And I would like some way for a macro to refer to its template
in order to build macro libraries (I think, we need this).

But the prefix proposal seems to me like syntactic sugaring.
I would use it when it were implemented but I do not really need it.


Dieter

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Shane Hathaway
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 sympathetic with that
reasoning.
That's not my reasoning either. :-)

My feeling is that you should avoid mixing syntaxes in a single 
document.  The more syntaxes you mix, the more perfection you require of 
developers.  Take the following code:

pre tal:content=python: text.replace('\\n', 'br /') /

This code has at least four errors (one XML, one HTML, one ZPT, one 
Python--can you spot them?), but it will work anyway without complaint. 
 This is hard to debug because it requires complete understanding and 
perfect spelling of four languages at once: XML, ZPT, HTML, and Python.

I wholeheartedly agree that newcomers should learn Python as well as 
ZPT, but there should be a clean separation of the two.

My concern is that ZPT will grow so many conveniences that it will 
become easier to abuse it in the same way that DTML has been 
widely abused. New zope developers will then be more tempted to
avoid python (i don't have time to learn another language) and
with the best intentions will do themselves a serious disservice: 
a lot of things will still be unnecessarily difficult compared to 
using python, and a lot of logic will be in templates where it 
doesn't belong.
I have a slightly different concern.  You're concerned that people will 
use path expressions when they could use Python expressions.  I'm 
concerned that people will use *any* kind of complicated expressions 
instead of Python code blocks.  To me, the choice between path 
expression and Python expression isn't very meaningful; either way I'm 
putting logic in a template, and if it's too complicated, it doesn't 
belong there.  The better goal is to move complicated logic out of 
templates and into Python code blocks, don't you think?

I know of two ways to avoid writing complicated expressions in templates:

1. Move complicated expressions into Python code blocks.

2. Provide a simpler equivalent for complicated expressions.

Prefixes in the middle of path expressions attacks #2.

Shane

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Paul Winkler
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
 developer to learn.
 
 I'm not necessarily one of them, but I am sympathetic with that
 reasoning.
 
 That's not my reasoning either. :-)
 
 My feeling is that you should avoid mixing syntaxes in a single 
 document.  The more syntaxes you mix, the more perfection you require of 
 developers.

Ah. yes, i think there's something to that.

 Take the following code:
 
 pre tal:content=python: text.replace('\\n', 'br /') /
 
 This code has at least four errors (one XML, one HTML, one ZPT, one 
 Python--can you spot them?),

heheh, good example... took me a while to find 4 :-)

but it will work anyway without complaint. 
  This is hard to debug because it requires complete understanding and 
 perfect spelling of four languages at once: XML, ZPT, HTML, and Python.

yeah, that sucks. Maybe I'm just upset that you want to remove my
favorite of the four. :-)  Given the context, of course, python is 
the only one that's a candidate for removal from the template.

 I wholeheartedly agree that newcomers should learn Python as well as 
 ZPT, but there should be a clean separation of the two.

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.

 I have a slightly different concern.  You're concerned that people will 
 use path expressions when they could use Python expressions.  I'm 
 concerned that people will use *any* kind of complicated expressions 
 instead of Python code blocks.  To me, the choice between path 
 expression and Python expression isn't very meaningful; either way I'm 
 putting logic in a template, and if it's too complicated, it doesn't 
 belong there.  The better goal is to move complicated logic out of 
 templates and into Python code blocks, don't you think?

Yes, I do. But I've found that when I write templates, there is a typical
progression:

 1. Start with a simple path expression:

 request/foo

 2. Whoops, now I need to do something a bit more involved:

 python:here.do_something(request.foo, here.something_else, ...)

 3. ugh, it's getting too long - 
move the python expression into foo_script and change
the tales expression to:

 here/foo_script

The current proposals aim to reduce the need to go to step 2.
Nice goal - it is true much of my ugliest template code has
been caused by pushing 2 too far. But I find that going from step 2 
to step 3 is so easy that I don't mind refactoring and it's
usually very quick.

However... it should be noted that step 2 can be completely bypassed.
There's nothing preventing me from going from 1 directly to 3.
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. 

Consider the psychological factor - python expressions are 
convenient sometimes. Many of us do not have the willpower to 
resist. :-)  Adding features to TALES doesn't change this, it 
gives us another brand of rope to hang ourselves with.

 I know of two ways to avoid writing complicated expressions in templates:
 
 1. Move complicated expressions into Python code blocks.
 
 2. Provide a simpler equivalent for complicated expressions.

what about:

 0. make complicated expressions illegal

I'm only half-joking. Why are we arguing for adding more stuff to TALES
rather than removing python expressions? Can someone think of an 
example that *requires* a python expression and can't be done with a 
path expression and a Script? If so, is it solvable by improving
the interaction between templates and Scripts instead of adding
features to Templates?

I seriously doubt this would meet community approval for zope 2,
there's too much existing code that would break.  but maybe it should be 
considered (if it hasn't been already) for zope 3.

 Prefixes in the middle of path expressions attacks #2.

hm. i guess i would agree if I thought any of the proposals actually 
are significantly simpler!  Let's stick to your first point - 
python in ZPT is undesirable because ZPT already makes you deal with
3 languages (assuming the output is html and not just XML).

But since we are stuck with 3 languages in one file,
why do we want to make one of them more complex than it already is? 
And since we know that we very often need a fourth language in another file, 
why not leverage that capability to keep the template super-simple?

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's PORN STAR OMEGA!
(random hero from isometric.spaceninja.com)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No 

Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Paul Winkler
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 that python expressions in TALES provide a huge hole
 in the separation of presentation from logic. 

I didn't mean to sound schizo... i'm just thinking out loud! :-)

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's MOSTLY-PENGUIN WEARING A HAT!
(random hero from isometric.spaceninja.com)

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


Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-23 Thread Shane Hathaway
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 feature has to be a lot better than the previous 
alternatives.  Well, here's a sample of what we'd get with prefixes in 
path expressions, all with a very minimal addition to TALES.

call: eliminates the need for implicitly calling things.  Purely 
explicit calling would eliminate a major class of bugs.

format: provides access to the same string formatting API that 
previously required importing a module.  In fact, it seems unlikely 
you'll want to import *any* modules in templates anymore.

zope: gives you access to a nice Zope-specific API, again without 
importing a module.

dc: lets you access simple Dublin Core metadata.  Perhaps here/title 
should even be deprecated and replaced with here/dc:title, since it's 
more explicit and more likely to generate the expected result, yet no 
more work.

I almost forgot to mention the most compelling reason why we need 
prefixes: in Zope 3, we won't be able to fall back on implicit 
acquisition anymore, so we need something to replace it.  Here's the 
(old) proposal that explains it all--

http://dev.zope.org/Zope3/NamespacesInTemplates

You see, prefixes are meant to let you work comfortably in an otherwise 
excruciatingly explicit world. :-)

Shane

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