At 01:13 PM 11/11/99 +1100, Evan Gibson wrote:
I _shouldn't_ be doing things like this in DTML. It shouldn't even let me. The whole _.getattr(blah) sections are far beyond the reality of a reporting language, and they don't go properly with an Object Oriented paradigm either. I should instead have an object made and be going:
<dtml-with "currentuser.get_skin()">
But the existing framework doesn't encourage this. If you banned _ access in anything but python methods and made it so python methods can only be used in Products, then you'd have the proper divide.
I've got to say I disagree on a fundamental level with the whole, "DTML shouldn't let you do stuff" idea. Having to have two different languages to program one application is really pretty ridiculous to me. If it made sense, then why *aren't* we all "doing the right thing" and making objects and using DTML only to format HTML? Well, for one thing, it breaks the flow of development. It's like saying you should use Python only for scripting and anything that's "real programming" you should immediately drop down to C or C++ and implement something you can call from Python. Doesn't that seem rather silly? But there's a second, and far more significant reason why trying to make DTML "just a reporting language" doesn't work in reality. It's this: *generating HTML is a programming task*. The reason you need programming capability in DTML is because you need to program the bloody HTML, URL's, query strings, and all the other overhead of making an interactive application. If you start pushing the hard bits into Python, then sure, you don't "pollute your presentation with programming", but then, you start polluting your programming with presentation, which is equally bad, if not worse. Should people use good style? Sure. Should you make products that implement all the data/business rules stuff and provide a clean interface? Absolutely! But doing this won't keep the need for programming out of DTML, because there will always be the need to perform transformations and compositions of arbitrary kinds on those data objects, precisely *because* they encapsulate data and ignore presentation! That's the dirty little secret of why none of us can kick the programming-in-DTML habit.