[ZPT] Truncating strings

[fergal at esatclear.ie]

I don't really want to get into whether or not there should be a way to
call functions, I think there should and others clearly do, otherwise there
wouldn't be a need for the prefix stuff. So, assuming there should be a way
to do it...

What are the benefits of the prefix syntax over a syntax that looks like a
normal method/function call? Something like

fmt:truncate(here/var, there/length)

I know ( and ) are path segment characters so that's currently illegal but
imagine they weren't for a minute.

Isn't this far clearer than

here/var/fmt:truncate/there/length

in fact I don't even know what the above would do, would it be

A (here/var/fmt:truncate/there)/length

or

B here/var/fmt:truncate/(there/length)

or

C here/var/fmt:truncate/(there)/(length) - 2 extra arguments to truncate

and if it's A, is there a way for me to do B or C?

Standard function syntax is unambiguous, well known, nestable and can take
multiple arguments. Prefix syntax is none of those (well maybe unambiguous,
but see the A, B, C question above). Yes, nestable and multiple arguments
are almost always unnecessary and will probably be abused by people who
don't know better but so will the prefix syntax, so why make life more
difficult?

Even better than function syntax, how about letting us pass arguments to
methods then we could just do

lib/fmt/truncate(here/var, there/length)

not need for : at all.

As for the lack of () are {} and [] also taken? If so, why not retake one
of these. I know people can create Zope object with names like "Photo of
mother (on her birthday)" but how many people would use this in a path in
their templates?

F


Original Message:
-----------------
From: Shane Hathaway shane at zope.com
Date: Wed, 22 Oct 2003 22:47:58 -0400 (EDT)
To: ianb at colorstudy.com, zpt at zope.org
Subject: Re: [ZPT] Truncating strings


On Tue, 21 Oct 2003, Ian Bicking wrote:

> [I think tal:format would imply structure]  But the current access to 
> these sorts of functions through the modules variable is painful at 
> best.  And it seems like the functions in PythonScripts.standard are a 
> little sparse.

Once again, this would be beautifully simple with subpath prefixes.  
Behold:

<span tal:content="var/fmt:truncate/10"></span>

I keep trying to tell everyone why this is so great.  Does anyone listen?  
:-)

If the syntax looks a little magical, here is what's going on.  First, the
path expression visits the name "var" and keeps its value in a temporary
variable.  It then looks at the next element of the path expression,
"fmt:truncate".  Normally, the path expression would look for an attribute
or item by that name, but since the name has a colon, the path expression
machinery takes a different route, knowing that colons mean it should use
a prefix implementation instead of traversing the normal way.  It finds a
prefix implementation named "fmt" in the registry of prefixes.  It
probably finds the implementation in the global registry.

Then the path expression machinery says to the "fmt" prefix
implementation, "please traverse from the object I'm giving you, to the
name 'truncate', and return what you got".  The "fmt" prefix
implementation knows about a function called 'truncate' and calls it.  
The 'truncate' function doesn't actually truncate yet, though, because we
haven't looked at the number 10 yet, so we don't know how much to
truncate.  Instead, this truncate function returns an object which, when
traversed, will actually do the truncating.

So the path expression machinery gets the truncator object and continues
traversal.  The next element in the path is the string "10".  That string
doesn't have a colon, so the machinery uses the default traversal.  It
looks for an attribute called "10"... nope, no such attribute.  Then it
looks for an item called "10".  The truncator has a __getitem__ method
that truncates to the specified number of characters, returning a string.  
The path expression gets this truncated string back, and finally, the path
expression returns the truncated string.

Alternatively, the truncate function could use some trick to consume the
next element of the path, rather than return a truncator object.  This is
probably faster, but not as elegant: now the truncate function is tightly
bound to path expressions.  Originally, it didn't care whether a path
expression or some other thing called it.  OTOH, the truncate function is
trivial, so it's probably better to ignore elegance in this case.  
Expedience wins.

Now, consider the oddness and slight magic of Zope's default traverser.  
Even in Zope 3, the default traverser looks for an attribute, then if it
finds no attribute, it looks for an item.  This leads to several
unanswerable questions.  If both attribute access and item access fail,
should it raise an AttributeError, a KeyError, or something else?  How do
you force the path expression to look for an item of a dictionary called
"key"?  (You can't--since dictionaries have an attribute called "key", the
lookup always stops at attribute access.)  If the thing you're looking up
is a method, how do you call the method once you have the attribute?  How
do you pass arguments?  How do you apply operations other and attribute or
item access, such as looking up an adapter?

Subpath prefixes are aimed squarely at solving the default traversal 
problem.  Subpath prefixes let you use traversers other than the default.  
They provide a good answer for all of the questions above: if you want to 
traverse in some way other than the default, just use a prefix.  Then be 
imaginative about the kind of traversal you could do.  (But stop before 
you write something that's Turing-complete [1]. ;-) )

In any case, I hope this rambling has made the ideas behind subpath 
prefixes clearer.  They solve many problems I encounter daily.

[1] http://en.wikipedia.org/wiki/Turing-complete

Shane

_______________________________________________
ZPT mailing list
ZPT at zope.org
http://mail.zope.org/mailman/listinfo/zpt


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .