Irene says:
I get so frustrated with DTML, I want to scream. Please don't tell me to buy the Zope book, DTML should be more intuitive. DTML maybe the heart of Zope, but it's also it's achilles heel.
You're right about the confusion, frustration, nor are you alone. Still, DTML isn't the heart of Zope, it's more like the fascia. DTML was intended to make the task of delivering dynamic content wrapped up in HTML-ish Templates easier. It evolved, and took on a broader scope that made it enticing for lot's of "other stuff". Like most evolution, there are obvious benefits, and some unfavorable outcomes. The most glaring problems show up when you start trying to do things that seem to be just a step or two more sophisticated than simple examples that "just work". There's good news. Python Methods, or whatever we end up calling them, make actually implementing such things as easy as Py(thon). For some folks, it may look like the bad news is, "Now I have to learn Python". In perspective, learning Python is way better than wading through the Zope API via DTML. Way way better. So, the moral is, keep the DTML as simple as it can be. For anything else, reach for another tool. Zope has bunches of them. BTW, the <dtml-if "_['sequence-item'}"> stuff is the tip of the DTML Complexity Iceberg. The sooner you get comfortable with Python Methods, ZClasses, etc., the happier you'll be. One last point. Python Methods (a.k.a. Restricted, Internal, or some other as yet unheard of alternative, which we are all anxiously awaiting) is an add-on at this point. Target date for inclusion as part of the standard "Core Zope" is Zope v.2.3. For now, see: http://www.zope.org/Members/4am/PythonMethod Later, Jerry S.
To all of you that responded, I appreciate your comments. I will admit, after reading some of your comments, and going back to the DTML Reference, this topic is discussed in the section under "The special namespace variable". Right before my eyes, there is an example doing exactly what I wanted: <dtml-if "_['sequence-length'] > 20"> The dtml-in variables don't follow Zope's own rules on variable names, but I've been told that this might change. Beyond this, when you need to do anything complex with DTML, the code gets really ugly. I have found it cleaner to just write an external Python method to take care of such complex things like parsing fields for wildcards, etc.. I will also look at Python Methods and ZClasses. Finally, don't get me wrong. I like Zope. It's the best solution I have found for through-the-web management and program development. I thank all of the Zope folks for that! Cheers, --irene "Spicklemire, Jerry" wrote:
Irene says:
I get so frustrated with DTML, I want to scream. Please don't tell me to buy the Zope book, DTML should be more intuitive. DTML maybe the heart of Zope, but it's also it's achilles heel.
You're right about the confusion, frustration, nor are you alone. Still, DTML isn't the heart of Zope, it's more like the fascia. DTML was intended to make the task of delivering dynamic content wrapped up in HTML-ish Templates easier. It evolved, and took on a broader scope that made it enticing for lot's of "other stuff".
Like most evolution, there are obvious benefits, and some unfavorable outcomes. The most glaring problems show up when you start trying to do things that seem to be just a step or two more sophisticated than simple examples that "just work".
There's good news. Python Methods, or whatever we end up calling them, make actually implementing such things as easy as Py(thon). For some folks, it may look like the bad news is, "Now I have to learn Python". In perspective, learning Python is way better than wading through the Zope API via DTML. Way way better.
So, the moral is, keep the DTML as simple as it can be. For anything else, reach for another tool. Zope has bunches of them.
BTW, the <dtml-if "_['sequence-item'}"> stuff is the tip of the DTML Complexity Iceberg. The sooner you get comfortable with Python Methods, ZClasses, etc., the happier you'll be.
One last point. Python Methods (a.k.a. Restricted, Internal, or some other as yet unheard of alternative, which we are all anxiously awaiting) is an add-on at this point. Target date for inclusion as part of the standard "Core Zope" is Zope v.2.3.
For now, see: http://www.zope.org/Members/4am/PythonMethod
Later, Jerry S.
-- ---------------------------------------------------------------- Irene Barg Email: ibarg@as.arizona.edu Steward Observatory Phone: 520-621-2602 933 N. Cherry Ave. University of Arizona FAX: 520-621-1891 Tucson, AZ 85721 http://nickel.as.arizona.edu/~barg ----------------------------------------------------------------
participants (2)
-
Irene Barg -
Spicklemire, Jerry