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

Tue, 29 Jul 2003 17:38:09 -0400

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

... 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
your class uses.

When it's time for zope 3, most of your work will then consist of rewriting
the wrapper (and maybe writing some zcml configuration file).
In zope 3, the wrapper should hopefully be simpler than what you need
for zope 2.

At least, that's the theory :-)

-- 

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