[Zope-dev] Re: [Zope] DTML Syntax contd. + rant

[Ethan Fremen]

Here's my take:

When my bid was accepted to redesign the site I'm working on, I settled
on Zope instead of PHP (it compiled without error.)

I knew nothing about Python or Zope.

Now I'm happily using Zope and I just got Learning Python.  I'm not very
far into it, but just learning some of the basics I'm starting to
realize how close to the surface Python is.

I would love to see Python Methods take over more of the "engine"
behavior from DTML.  I assume, however, that ngDTML would still include
things like <dtml-in>, otherwise I'll pull my hair out.

I also think there's some things that can/should be pushed elsewhere-
REQUEST.set is a good example- I get a content-type for images, why not
let me do that with other objects?  Maybe the drop-down list of
properties could be like the object-selection, so you could add new
property types (content-type, tinytable...)

Simultaneously, the last thing I want to see is for HTML to get imbedded
in python.  I used a Perl module where I built forms programmatically,
and I don't want to go back to that. I've spent most of my time on this
project getting out from under some developer who thought implementing
HTML in javascript was a good idea. I'm also frustrated with things like
TreeTag.py that imbed HTML into them, not allowing me to change their
output to fit my fancy.

I don't really have a problem with PythonMethods being scattered
throuought my hierarchy: indeed, if they live with aquisition the same
as everybody else, this could be quite useful.

(as an aside, I'd like to be able to use factories like this, so that
certain objects are only creatable at certain places in the hierarchy)

Perhaps if DTML has a consistent method of dealing with things passed
to/from npythonMethods, and a way of invoking them (dtml-call?), they
would be more used.

I know I stay as far away from the _ stuff as I can.  If I have to use
one of those _[blarg._['foo']] things, i copy it from someone else and
hope that it works.  It sure reminds me of something somebody called
another language- "executable line noise".

anyway, python seems to me to be a transparent enough language that
there's no compelling need to obfuscate it for things it does well
enough already.
Plus, the "closer" python is in the upgrade path from content manager ->
developer -> zope source contributor, the sooner you'll have more of the
latter.

wannabe zope hacker,
--
Ethan "mindlace" Fremen
you cannot abdicate responsibility
for your ideology.