Hi people, Ah, you're replying to my rant here. :) Rik Hoekstra wrote: [snip]
I _really_ like Zope,
me too, no question.
but I am afraid I have to agree with you.
I agree with myself too. :)
I'll add some more rant. I believe it's important to stress that this is _not_ meant as criticism per se, but only to point out what even for people who have used ZOpe for almost a year are major flaws in its usability. And I can vote for Martijn, that he's not stupid; I myself have the excuse of not coming from a computer science background, but still I rabble on.
Thanks for your vote of non-stupidity. :)
Philosophical end rant:
If I ever get the time I'd be tempted to work on a DTML 'cleanup' project. DTML is currently *far* too much like Perl and not enough like Python. *some* easy things are very easy, but as a consequence some other easy things become far too hard, or at least look far too complicated. You can spell the same thing in too many ways. The community encourages and praises additions for convenience (like the 'default' option, or the new extended &entity; syntax) but as a result DTML loses its conceptual integrity. It becomes too big and not easy to understand.
I understand the argument that DTML shouldn't be used for complicated purposes, and that you should use Python. This is fine and good, but in practice people *do* use DTML for complicated purposes. ZClasses in fact encourage this.
The point is that it's not always clear when things are complicated. And using python for complicated tasks is not exactly a piece of cake either, for a number of reasons. - writing products in python is complicated and mostly not worth it
Though this is getting easier in the newer Zopes. Or I'm learning more about it. I highly recommend the 'Boring HOWTO' in this regard, by the way.
- writing python base classes for ZClasses is easier, but using them in the Z framework requires quite a bit of understanding of ZClasses and the Zope framework in general
Yes, this is pretty easy, but (as Amos remarked in his slides), distribution is currently difficult. Also if something goes wrong you can end up with objects in weird states which you can't delete. And it's true they could probably be simplified (or the documentation improved) so that still less understanding about Zope's inner details is necessary.
- External methods are much easier, but they have their own disadvantages: (1) it is less than obvious how they interact with the dtml methods/namespace they are called from (2) they are not easily transported to another machine, because you need physical access to the filesystem for that (I understand that that's the only way)
Though you can say the same for Products and ZClasses for Python base classes. Python Methods are cool. I haven't played a lot with them as I'm working on a production site, but I intend to play with them more.
DTML should be more like Python.
Yes
Luckily the Zope framework does allow new objects to be plugged in using something else than DTML, so not all hope is lost. :)
But it should be easier to use this stuff (do I hear the word developer documentation??? uuummm)
It's not only documentation though. The 'with' issue that caused me to rant is simply not consistent enough. There are more places in DTML where it is like this. The _[_['sequence-item']] style constructions are also obfuscatory.
Feedback on this rant would be appreciated.
My 2 cents.
Thanks! Regards, Martijn