Re: [Zope] mixing python and DTML is hellish!
kosh@aesaeion.com wrote:
solution and so far I like it a lot more then ZPT. ZPT seems to have the idea that there should be a 1 document to 1 page mapping which I don't like.
Where on earth did you get that idea?
I prefer having lots of little objects around that get assembled together to build a page. Especially when working with smarter objects.
I think you may have missed METAL, or at least not understood it...
Overall DTML is easier to use with this kind of a model by a good deal.
Not true, by a good deal. <p tal:replace="/some/other/component">Bit bit goes here</p> ...seems a lot nicer (and more predictable) to me than: <p><dtml-var "PARENTS[-1].some.other.component(_.None,_)"></p>
I doubt there is a simpler way to do <dtml-var header><dtml-var someobject><dtml-var footer> with all of those being python products, python scripts etc that know how to behave when called using a little python magic.
Two points: 1. <tal:x tal:replace="here/header"><tal:x tal:replace="here/someobject"><tal:x tal:replace="here/footer"> ..if you really must. Although the concept of half your layout being in a header and the other half in a footer is broken by design. the correct way to do this is: <html metal:use-macro="/some_template/macros/main"> <body metal:fill-slot="here/someobject"> </html> ...which is much more explicit, graceful and nice. 2. "a little bit of python magic" is what causes you to get bit in the ass 6 months down the line when you coem to make a minro tweak to the code and break everything. Explciit is good!
Overall it seems ZPT seems designed for html people that used wysiwyg editors to write pages.
So EMACS is a wysiwig editor now? Glad to hear it ;-)
Overall I don't, nor does anyone I work with do that. The pages written that way just are not as clean as what you can get from someone that knows the spec and how to use it to their best advantage.
Actually, I use Dreamweaver to rapid-prototype pages (and it produces pretty damn good HTML) and then do minro tweaks by hadn when I'm adding in the TAL. I really like the fact that I can look at the source of the template in a browser and see what it's going to look like without actually needing to feed loads of dynamic content into it. Come and have a go if you think you're hard enough ;-) Chris
On Fri, 1 Mar 2002, Chris Withers wrote:
kosh@aesaeion.com wrote:
solution and so far I like it a lot more then ZPT. ZPT seems to have the idea that there should be a 1 document to 1 page mapping which I don't like.
Where on earth did you get that idea?
Can you call ZPT documents from other ZPT documents and so on without having them pull in headers, footers etc at each step. Also how do you deal with user agent detection such that you have a page that changes depending on the requesting agent so that you have one url to x object and x object does not always look the same.
I prefer having lots of little objects around that get assembled together to build a page. Especially when working with smarter objects.
I think you may have missed METAL, or at least not understood it...
Overall DTML is easier to use with this kind of a model by a good deal.
Not true, by a good deal.
<p tal:replace="/some/other/component">Bit bit goes here</p>
...seems a lot nicer (and more predictable) to me than:
<p><dtml-var "PARENTS[-1].some.other.component(_.None,_)"></p>
Well I don't use PARENTS in DTML since I think that belongs in the python code. I also don't use the _.None,_ since I have never had it be needed. Also I don't put the tags around it so the dtml calls I do are just includes.
I doubt there is a simpler way to do <dtml-var header><dtml-var someobject><dtml-var footer> with all of those being python products, python scripts etc that know how to behave when called using a little python magic.
Two points:
1.
<tal:x tal:replace="here/header"><tal:x tal:replace="here/someobject"><tal:x tal:replace="here/footer">
..if you really must. Although the concept of half your layout being in a header and the other half in a footer is broken by design.
Actually I don't think it is broken since I don't see them as the same objects. What you define as the layout of a page may not be the same for all user agents, the same at all levels of a site etc. I like having these nice black boxes that can be called without having to worry about them explicitely since I find that makes things easier to debug. If everything that needs a header calls the header then it only needs to be fixed in one location. Overall I don't think of a page as a single document I think of it as a collection of objects that each does a job and only that job. DTML looks to me to fit that concept better then ZPT does.
the correct way to do this is:
<html metal:use-macro="/some_template/macros/main"> <body metal:fill-slot="here/someobject"> </html>
However now you have defined it as html which is not always the case. Overall that looks more complex to me then just calling the objects and allowing them to behave as needed.
...which is much more explicit, graceful and nice.
2.
"a little bit of python magic" is what causes you to get bit in the ass 6 months down the line when you coem to make a minro tweak to the code and break everything. Explciit is good!
Actually we have been doing it for a lot more then 6 months now without any problems. Introspection and reflection are not really that magical but they do allow an object to react based on its surroundings.
Overall it seems ZPT seems designed for html people that used wysiwyg editors to write pages.
So EMACS is a wysiwig editor now? Glad to hear it ;-)
Overall I don't, nor does anyone I work with do that. The pages written that way just are not as clean as what you can get from someone that knows the spec and how to use it to their best advantage.
Actually, I use Dreamweaver to rapid-prototype pages (and it produces pretty damn good HTML) and then do minro tweaks by hadn when I'm adding in the TAL. I really like the fact that I can look at the source of the template in a browser and see what it's going to look like without actually needing to feed loads of dynamic content into it.
How do you select for which user agent that you will be editing the source. I have data objects that change based on user agent and it seems under that way if you tried to view what the unrendered view of a page would be you would have to state which user agent you wanted to view that information for. I prefer to be able to go to the object and use its interfaces for dealing with the various useragents and being able to trust the other objects will do their job without needing to be checked on it. Overall if you adhere stricly to the DOM and follow the spec to the letter that is not a problem. xhtml 1.0 strict is really not hard and if you use it properly and know how the browsers work you can speed up page drawing and make it easier to develop. Overall I am not happy with any generated code from any application I have seen so far. They are often embarassinly far from the spec and most abuse tables which slows down page rendering.
Come and have a go if you think you're hard enough ;-)
kosh@aesaeion.com wrote:
Can you call ZPT documents from other ZPT documents and so on without having them pull in headers, footers etc at each step.
Yes
Also how do you deal with user agent detection such that you have a page that changes depending on the requesting agent so that you have one url to x object and x object does not always look the same.
You can have a dynamic macro expansion :-)
Actually I don't think it is broken since I don't see them as the same objects.
Then your thinking is broken ;-)
location. Overall I don't think of a page as a single document I think of it as a collection of objects that each does a job and only that job.
You said that before, and I agree, so how do you handle the case where you haev a table containing other objects? I half the table in the header and half in the footer?
DTML looks to me to fit that concept better then ZPT does.
Look harder!
However now you have defined it as html which is not always the case.
Gimme some other cases where ZPT wouldn't work, go on, I dare ya ;-)
Overall that looks more complex to me then just calling the objects and allowing them to behave as needed.
That's just because you haven't seen it before, I can assure you its a lot simpler...
Actually we have been doing it for a lot more then 6 months now without any problems. Introspection and reflection are not really that magical but they do allow an object to react based on its surroundings.
I agree, but ZPT does not proven intospection or reflection, it just doesn't require them.
How do you select for which user agent that you will be editing the source.
How do you do it using your method?
Overall if you adhere stricly to the DOM and follow the spec to the letter that is not a problem. xhtml 1.0 strict is really not hard and if you use it properly and know how the browsers work you can speed up page drawing and make it easier to develop.
ZPT has no requirement for xhtml 1.0.
Overall I am not happy with any generated code from any application I have seen so far. They are often embarassinly far from the spec and most abuse tables which slows down page rendering.
Have you seen the HTML generated by Squishdot's DTML? ;-) cheers, Chris
On Fri, 1 Mar 2002, Chris Withers wrote:
kosh@aesaeion.com wrote:
Actually I don't think it is broken since I don't see them as the same objects.
Then your thinking is broken ;-)
Well we can certainly disagree on that one. ;)
location. Overall I don't think of a page as a single document I think of it as a collection of objects that each does a job and only that job.
You said that before, and I agree, so how do you handle the case where you haev a table containing other objects? I half the table in the header and half in the footer?
I don't make pages where you have a table that spans a page. That is a misuse of tables. Tables are for tabular data not for layout. Use divs for layout and position them as needed. It works much better on the newer browsers and it draws a lot faster. IE 4-6, Netscape 6.x, Opera, and konqueror all handle that very nicely then you just put a netscape 4.x version in to catch that browser and some of the older ones. Overall I see a page as being broken if you have a table spanning it. :)
Actually we have been doing it for a lot more then 6 months now without any problems. Introspection and reflection are not really that magical but they do allow an object to react based on its surroundings.
I agree, but ZPT does not proven intospection or reflection, it just doesn't require them.
Well I do think just about everything could use that capability since it expands what you can do by a good bit.
How do you select for which user agent that you will be editing the source.
How do you do it using your method?
I use a python product that I wrote and it has an inteface in it for editing those items. I store the data in custom objects embedded in it and then they have a filter based on the user agent being used to access them. So in order to edit/see the code for various user agents you would just check out the interface it has for editing those items.
Overall I am not happy with any generated code from any application I have seen so far. They are often embarassinly far from the spec and most abuse tables which slows down page rendering.
Have you seen the HTML generated by Squishdot's DTML? ;-)
Hmm when I looked at it before it was pretty bad. I kind of doubt it has improved that much. :) However DTML does not make it worse it just doesn't help fix the problem.
kosh@aesaeion.com wrote:
Actually I don't think it is broken since I don't see them as the same objects.
Then your thinking is broken ;-)
Well we can certainly disagree on that one. ;)
You would, your thinkign is broken ;-)
I don't make pages where you have a table that spans a page. That is a misuse of tables. Tables are for tabular data not for layout. Use divs for layout and position them as needed. It works much better on the newer browsers and it draws a lot faster. IE 4-6, Netscape 6.x, Opera, and konqueror all handle that very nicely then you just put a netscape 4.x version in to catch that browser and some of the older ones.
And what do you put in your nestcape 4.x version? Also, if you have a page layout that wraps an particular object, how do you avoid having div's being opened in the header adn closed in the footer?
I use a python product that I wrote and it has an inteface in it for editing those items.
What does this interface look like? What do the items you edit using this interface look like?
I store the data in custom objects embedded in it and then they have a filter based on the user agent being used to access them.
What do the custom objects look like? Where is their code? How does the filtering work and where is its code?
So in order to edit/see the code for various user agents you would just check out the interface it has for editing those items.
And how is this interface presented?
Hmm when I looked at it before it was pretty bad. I kind of doubt it has improved that much. :) However DTML does not make it worse it just doesn't help fix the problem.
The same is true of ZPT, although it's much harder to inadertently creeate a mess in ZPT. cheers, Chris
I actually agree very much with Chris on this DTML vs. ZPT. My experience is this: - ZPT has more advantages that DTML in total - ZPT has disadvantages - DTML is for quick and dirty publishing, ZPT is for more serious longlasting things - DTML is easier to understand for the novice (or is it because ZPT is not?) - A site with DTMLed templates tend to be a big bunch of templates and ZPT seems to be fewer with many more Python Script objects - ZPT is less suited for the little textarea editing - DTML is less suited for Dreamweaver and such which is after all pretty important if we want to get paid for our work. So, conclusion: * ZPT for longer lasting more scalable sites * DTML for quicker things where workflow and stuff like that doesn't matter Peter Oh! One other thing. A clearly negative thing about ZPTs is that it seems more difficult to learn and understand. I.e. the usability of ZPT is worse than DTML and I know that exactly this is something Zope.com does not want happening to Zope. At 13:23 2002-03-01 +0000, Chris Withers wrote:
kosh@aesaeion.com wrote:
Can you call ZPT documents from other ZPT documents and so on without having them pull in headers, footers etc at each step.
Yes
Also how do you deal with user agent detection such that you have a page that changes depending on the requesting agent so that you have one url to x object and x object does not always look the same.
You can have a dynamic macro expansion :-)
Actually I don't think it is broken since I don't see them as the same objects.
Then your thinking is broken ;-)
location. Overall I don't think of a page as a single document I think of it as a collection of objects that each does a job and only that job.
You said that before, and I agree, so how do you handle the case where you haev a table containing other objects? I half the table in the header and half in the footer?
DTML looks to me to fit that concept better then ZPT does.
Look harder!
However now you have defined it as html which is not always the case.
Gimme some other cases where ZPT wouldn't work, go on, I dare ya ;-)
Overall that looks more complex to me then just calling the objects and allowing them to behave as needed.
That's just because you haven't seen it before, I can assure you its a lot simpler...
Actually we have been doing it for a lot more then 6 months now without any problems. Introspection and reflection are not really that magical but they do allow an object to react based on its surroundings.
I agree, but ZPT does not proven intospection or reflection, it just doesn't require them.
How do you select for which user agent that you will be editing the source.
How do you do it using your method?
Overall if you adhere stricly to the DOM and follow the spec to the letter that is not a problem. xhtml 1.0 strict is really not hard and if you use it properly and know how the browsers work you can speed up page drawing and make it easier to develop.
ZPT has no requirement for xhtml 1.0.
Overall I am not happy with any generated code from any application I have seen so far. They are often embarassinly far from the spec and most abuse tables which slows down page rendering.
Have you seen the HTML generated by Squishdot's DTML? ;-)
cheers,
Chris
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Fri, 1 Mar 2002, Peter Bengtsson wrote:
I actually agree very much with Chris on this DTML vs. ZPT. My experience is this:
- ZPT has more advantages that DTML in total - ZPT has disadvantages - DTML is for quick and dirty publishing, ZPT is for more serious longlasting things
Why do you think DTML is quick and dirty and ZPT is more serious?
- DTML is easier to understand for the novice (or is it because ZPT is not?)
I find DTML easier overall then ZPT which is not a bad thing for any level of use.
- A site with DTMLed templates tend to be a big bunch of templates and ZPT seems to be fewer with many more Python Script objects
That is because DTML is often abused that is not an inherent flaw in DTML. Most of my work tends to be in python scripts that get called by DTML.
- ZPT is less suited for the little textarea editing - DTML is less suited for Dreamweaver and such which is after all pretty important if we want to get paid for our work.
Dreamweaver and that kind of editing doesn't matter to me at all since neither we or any of our customers use that.
So, conclusion: * ZPT for longer lasting more scalable sites
Why do you think ZPT is longer laster or more scalable?
* DTML for quicker things where workflow and stuff like that doesn't matter
Not sure what you mean about workflow but I do find DTML quick to develop and it does work well long term. Overall dtml-var, and dtml-call are about the only calls I actually use in dtml anymore.
Peter
Oh! One other thing. A clearly negative thing about ZPTs is that it seems more difficult to learn and understand. I.e. the usability of ZPT is worse than DTML and I know that exactly this is something Zope.com does not want happening to Zope.
That topic has come up a good number of times in irc.openprojects.net #zope
kosh@aesaeion.com wrote:
- A site with DTMLed templates tend to be a big bunch of templates and ZPT seems to be fewer with many more Python Script objects
That is because DTML is often abused that is not an inherent flaw in DTML.
Au contrére, that is DTML's BIGGEST inherent flaw. You can write nice DTML, if you try pretty damn hard, but it's soooooo easy to get into foot shooting land.
Dreamweaver and that kind of editing doesn't matter to me at all since neither we or any of our customers use that.
But that doesn't mean other people don't use it. I didn't like the idea of Dreamweaver until I started using it with WebDrive over WebDAV. Now I'm a convert ;-)
Why do you think ZPT is longer laster or more scalable?
It's gonna be supported longer, it was better designed for the task, etc. I could go on but you won't believe me anyway and I'm close enough to RSI-land anyway... cheers, Chris
On Sat, 2 Mar 2002, Chris Withers wrote:
kosh@aesaeion.com wrote:
- A site with DTMLed templates tend to be a big bunch of templates and ZPT seems to be fewer with many more Python Script objects
That is because DTML is often abused that is not an inherent flaw in DTML.
Au contr�re, that is DTML's BIGGEST inherent flaw. You can write nice DTML, if you try pretty damn hard, but it's soooooo easy to get into foot shooting land.
You can write bad python pretty easily also but that is not a flaw of python. Many people have been encouraged to write bad DTML from lots of sources on zope.org. Even the zope book has had some pretty bad examples which does not help the issues.
Dreamweaver and that kind of editing doesn't matter to me at all since neither we or any of our customers use that.
But that doesn't mean other people don't use it. I didn't like the idea of Dreamweaver until I started using it with WebDrive over WebDAV. Now I'm a convert ;-)
Well I don't run a windows OS and do all my devel on linux. With KDE 3.0 webdav will be transparent across any kde app so I will probably use webdav more but I will still use it with DTML.
Why do you think ZPT is longer laster or more scalable?
It's gonna be supported longer, it was better designed for the task, etc. I could go on but you won't believe me anyway and I'm close enough to RSI-land anyway...
I doubt support for DTML can be pulled for a good while. Talk to TheJester he has some very good arguments for why DTML needs to stay around. It has been discussed a fair bit on #zope and the channel is fairly well divided. I think ZPT was designed for a task of allowing web designers to work on stuff and insulate them from the code. The problem I see is that it took so long to get python script in zope. It encouraged people to put lots of logic in DTML since external methods are a pain by comparison. If examples where updated that seperatd the logic into python scripts and the presentation in DTML it would work well.
kosh@aesaeion.com wrote:
You can write bad python pretty easily
Now that I really do disagree with! What are you basing that statement on exactly?
python. Many people have been encouraged to write bad DTML from lots of sources on zope.org. Even the zope book has had some pretty bad examples which does not help the issues.
Maybe the fact that so much bad stuff has been written in it says something about it? Maybe you're a perl user too?
Well I don't run a windows OS and do all my devel on linux.
Good for you :-)
It's gonna be supported longer, it was better designed for the task, etc. I could go on but you won't believe me anyway and I'm close enough to RSI-land anyway...
I doubt support for DTML can be pulled for a good while.
Re-read what I typed ;-) It won't ever be pulled, but it will slowly fade into disrepair and no longer be used except by all the most die-hard fanatics like yourself...
Talk to TheJester he has some very good arguments for why DTML needs to stay around.
Andy Milton has a lot of arguments. I wouldn't describe most of them as 'good'...
I think ZPT was designed for a task of allowing web designers to work on stuff and insulate them from the code. The problem I see is that it took so long to get python script in zope. It encouraged people to put lots of logic in DTML since external methods are a pain by comparison. If examples where updated that seperatd the logic into python scripts and the presentation in DTML it would work well.
What has any of this to do with whether or not ZPT is a better choice for templating than ZPT? cheers, Chris
You can write horrible Zope apps very quickly and easily, and DTML will let you get away with it. I've seen developers copy folders full of ugly DTML to new folders, change a few things inside a few of the methods in the new folder, and that's how a new menu item is born. I've seen Zope apps with 300 DTML methods, and only 6 python scripts, and those 6 would have been in DTML if it were possible. (Python as a last resort because developer X doesn't want to learn another language) In short, I've seen Zope apps with absolutely no separation between the application and presentation layers. Zope, and more specifically DTML, is flexible enough to let you do this. Just because you CAN create a working prototype of an application using a mixture of DTML and HTML during what should be the design phase of a project, doesn't mean you SHOULD. If you want to hack up a barely working un-manageable mess of DTML in the shortest possible amount of time, and then call it a "production ready" web application after a week of bug chasing, then DTML will help you do this. If you want to create a highly structured, easily maintainable and extensible object oriented web application, and you want to apply one more of the "light" SDLC methodologies to your project, then ZPT is your best friend. There's nothing better than completed GUI templates for helping to test your understanding of the requirements and use cases. Your users will gladly contribute to this process. Just my two cents :-) Adam
On Sat, 2 Mar 2002, Chris Withers wrote:
kosh@aesaeion.com wrote:
You can write bad python pretty easily
Now that I really do disagree with! What are you basing that statement on exactly?
Are you telling me that you have not seen badly commented code? Cut and paste code? Incorrect comment code? Heavy abuse of lambda, map, filter? Almost all of those are done in every language and they all make bad code. Python tries to encourage good code but it does not prevent you from writing bad code.
python. Many people have been encouraged to write bad DTML from lots of sources on zope.org. Even the zope book has had some pretty bad examples which does not help the issues.
Maybe the fact that so much bad stuff has been written in it says something about it?
Maybe a lot of bad things have been built by humans. Maybe that says something about humans. Maybe it doesn't. Maybe it just says that any tool that is powerful can be used to create problems and remove them depending on the person using the tool.
Maybe you're a perl user too?
Nope I have not written perl. I got to about hello world and decided I didn't like it. I have mostly done C++ and python.
Well I don't run a windows OS and do all my devel on linux.
Good for you :-)
Certainly cut down on that crash rate. :)
Talk to TheJester he has some very good arguments for why DTML needs to stay around.
Andy Milton has a lot of arguments. I wouldn't describe most of them as 'good'...
A fair number of them are pretty good but you seem so blinded by the ZPT is the perfect solution and DTML is bad you won't see them.
kosh@aesaeion.com wrote:
Are you telling me that you have not seen badly commented code?
That's not 'bad python', that's underdocumented python. And, for there cord, I find python one of the easier languages to understand when it _has_ been underdocumented. I might even go so far as to say that python is one of the few languages that doesn't need heavy commenting ;-)
Cut and paste code?
What's wrong with that?
Incorrect comment code?
And in english?
Heavy abuse of lambda, map, filter?
Define heavy abuse...
Almost all of those are done in every language and they all make bad code. Python tries to encourage good code but it does not prevent you from writing bad code.
Oh but it does, think of the rules on indentation at the very least!
Maybe a lot of bad things have been built by humans. Maybe that says something about humans.
It does indeed.
Maybe you're a perl user too?
Nope I have not written perl.
You should try it, I think you'd like it, it's got lots of things that can be used to make very graceful, small, programs but that can also be abused t owrite indecipherable crap :-) cheers, Chris (who will be ducking out of this thread soon as it always was a futile waste of time, but I think there's enough evidence in the mail archives now that I don't feel guilty about newbies being lead down the DTML road...)
Why do you think ZPT is longer laster or more scalable?
It's gonna be supported longer, it was better designed for the task, etc. I could go on but you won't believe me anyway and I'm close enough to RSI-land anyway...
That was not what I meant. If a second developer three months later comes around to: <dtml-if something><dtml-var something></dtml-if> He's not gonna understand it. But: <span tal:condition="python:request.has_key('something')" tal:content="request/something" ></span> Is more easy to understand. That was just one example. There are other ways of looking at it.
On Sat, 2 Mar 2002, Peter Bengtsson wrote:
Why do you think ZPT is longer laster or more scalable?
It's gonna be supported longer, it was better designed for the task, etc. I could go on but you won't believe me anyway and I'm close enough to RSI-land anyway...
That was not what I meant. If a second developer three months later comes around to: <dtml-if something><dtml-var something></dtml-if> He's not gonna understand it.
Well you did violate one of the rules of refactoring there. Look at rename method page 273 of refactoring. In my case the code would be closer to. <dtml-if customerContactForm><dtml-var customerContactForm></dtml-if> In this case you know what it is trying to do based on its name. It is a poor carpenter who blames his hammer. ;)
But: <span tal:condition="python:request.has_key('something')" tal:content="request/something" ></span> Is more easy to understand.
That was just one example. There are other ways of looking at it.
I don't find that easier to understand but I can see where things would need to be fixed if a variable name was changed. Overall I would probably put that kind of thing in a python script and just call it.
That was not what I meant. If a second developer three months later comes around to: <dtml-if something><dtml-var something></dtml-if> He's not gonna understand it.
Well you did violate one of the rules of refactoring there. Look at rename method page 273 of refactoring. In my case the code would be closer to. <dtml-if customerContactForm><dtml-var customerContactForm></dtml-if>
In this case you know what it is trying to do based on its name. It is a poor carpenter who blames his hammer. ;)
"if a SECOND DEVELOPER thress months later..." Personally I, this week, stumbled across what looked like this: <dtml-if v><dtml-var v></dtml-if> Not my fault, but my problem to solve. A hint would help.
On Sun, 3 Mar 2002, Peter Bengtsson wrote:
That was not what I meant. If a second developer three months later comes around to: <dtml-if something><dtml-var something></dtml-if> He's not gonna understand it.
Well you did violate one of the rules of refactoring there. Look at rename method page 273 of refactoring. In my case the code would be closer to. <dtml-if customerContactForm><dtml-var customerContactForm></dtml-if>
In this case you know what it is trying to do based on its name. It is a poor carpenter who blames his hammer. ;)
"if a SECOND DEVELOPER thress months later..." Personally I, this week, stumbled across what looked like this: <dtml-if v><dtml-var v></dtml-if>
Not my fault, but my problem to solve. A hint would help.
Ick. Find the original writer and have that person keel hauled. Writing unmaintainable code can be done in any language but that code looks like what I have seen from CS grads which is worse then much I have seen. Sorry but the CS dept here is not very good and I see lots of crap. However that is pretty bad crap.
[<kosh@aesaeion.com>]
Not sure what you mean about workflow but I do find DTML quick to develop and it does work well long term. Overall dtml-var, and dtml-call are about the only calls I actually use in dtml anymore.
Same here, plus dtml-in, zsql methods, and the odbc connector. Cheers, Tom P
Peter Bengtsson wrote:
Oh! One other thing. A clearly negative thing about ZPTs is that it seems more difficult to learn and understand. I.e. the usability of ZPT is worse than DTML and I know that exactly this is something Zope.com does not want happening to Zope.
I don't actually agree with that. I reckon once ZPT starts appearing in more books, you'll see newbie's using it more and understanding it more easily than DTML. The problem is that most Zope users have been brain damaged into the DTML way of thinking and so continue to try desperately to shoot themselves in the feet when they move to ZPT and get frustrated whe nit won't let them... cheers, Chris
Oh! One other thing. A clearly negative thing about ZPTs is that it seems more difficult to learn and understand. I.e. the usability of ZPT is worse than DTML and I know that exactly this is something Zope.com does not want happening to Zope.
I don't actually agree with that. I reckon once ZPT starts appearing in more books, you'll see newbie's using it more and understanding it more easily than DTML.
My empirical experience has been that DTML reminds you of the way PHP, ASP, JSP etc. works: <input value="<?%= variableName %?>"> ZPT takes a sligthly different approach. Secondly, ZPT "code" tends to be a bit longer (in amount of characters) and Python advocates don't really like this.
Peter Bengtsson wrote:
My empirical experience has been that DTML reminds you of the way PHP, ASP, JSP etc. works: <input value="<?%= variableName %?>"> ZPT takes a sligthly different approach.
...indeed. One which is much asier and saner if your mind hasn't been poluted first ;-)
Secondly, ZPT "code" tends to be a bit longer (in amount of characters) and Python advocates don't really like this.
Depends on which Python advocates you speak to. That said, it's bound ot be a bit longer since it's more explicit, but as you've already explained in another post, that's a very good thing :-) cheers, Chris
participants (5)
-
Adam Manock -
Chris Withers -
kosh＠aesaeion.com -
Peter Bengtsson -
Thomas B. Passin