[ZPT] Truncating strings

[Ian Bicking]

On Wednesday, October 22, 2003, at 11:28 PM, Shane Hathaway wrote:
>> Thinking about the same thing, I'd intuitively come up with:
>>
>> <span tal:content="fmt/truncate/10:var"/>
>>
>> Which would be equivalent to fmt.truncate['10'](var).  I.e., just use 
>> :
>> to mean call.  This is a little problematic because : is already being
>> used elsewhere (not:, python:), but there are a fixed number of such
>> prefixes and they are clearly defined (and can't have a '/' in them).
>
> Here are some things I would consider with your approach:
>
> 1. You have to provide the name "fmt" somehow.  Is it a local/global
> variable?  The approach I described doesn't even require an import.

It would have to be a global variable or something.  That's better than 
a registry, IMHO.  A registry seems complex and opaque.  Either way you 
have to somehow map the names to objects -- using normal namespaces 
seems clearly to be the best way.  If importing is an issue, then maybe 
that needs to be fixed -- it's too hard to get access to functions in 
page templates, even though there are lots of display-related functions 
you might want to use in a template.

> 2. You have to rearrange the expression.  In fact, your syntax only 
> works
> if the thing you're formatting is a variable.  How would you format
> "here/var" without storing "here/var" in a temporary variable first?  I
> can write "here/var/fmt:truncate/10".  In fact, I could also write
> "here/var/truncate:10" if I decided to register a "truncate" prefix.

It's assumed both sides of the : are full expressions.  So you could do 
fmt/truncate/10:here/var, for instance (assuming truncate had a 
__getitem__ which would take an integer-like argument and curry it for 
later use).

> 3. There is no precedent for the idea that ":" means you should call
> something.  There is a precedent, however, for the idea that ":" means 
> you
> should switch to a different namespace (XML).

There's maybe a slight precedence in Smalltalk.  I don't care much 
about the way the expression is formatted -- heck, even parenthesis 
would work.  Namespaces, especially the way you propose, are hard and 
require lots of backtracking.  Calling is easy.

> 4. You'd be better off writing your expression in plain old Python.  
> More
> explicit and no new syntax.  But again, the thing you've lost is that 
> you
> have to import something first, and that's a costly thing to do in a
> template.

The problem with a Python expression is that the translation isn't so 
good.  The expression will probably start out as something simple, like 
"options/var/subvar", and only later do you want to format that.  It's 
annoying to translate options/var/subvar to options['var].subvar, and 
this way you avoid that.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org