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

[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.  <shout>Keep up the good work!</shout> <whisper>which 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.