Folks, I have been trying out Zope, and am now getting beyond the trivial. I do have a question about python vs DTML. What I am finding is that mixing and matching python scripts and DTML (methods and documents) is rather hellish/confusing. For example: o descending into python and then back up to DTML is hard, when you are trying to use acquisition. The python code does not understand contexts and acquisition in quite the same way as DTML. o I am trying to use the SQL Session object from within a python script, and am having all kinds of difficulty. I am starting to believe that it is cleaner (although not as powerful) to use DTML exclusively (and python only for that which is impossible in DTML). This' kind of saddens me as the "Zope Book" suggests that python is highly interchangeable with, and more powerful than DTML. Am I totally off base? Is there some valuable reading that I have missed? How do experienced ZOPErs view this issue? Roy.
On Thu, 28 Feb 2002, Roy Mathew wrote:
Folks,
I have been trying out Zope, and am now getting beyond the trivial. I do have a question about python vs DTML.
What I am finding is that mixing and matching python scripts and DTML (methods and documents) is rather hellish/confusing. For example:
I would certainly agree that mixing and matching DTML with python script is a bad idea however I also think that is the wrong way to do things. I used to mix and match items and over time found that it did not work very well for many reasons. What I have been doing for about 9 months or so is putting just about all logic in python and then using DTML to present it only. So I have lots of little scripts and then just use dtml-var to call them. This works very well and is maintainable.
o descending into python and then back up to DTML is hard, when you are trying to use acquisition. The python code does not understand contexts and acquisition in quite the same way as DTML.
Could you be more precise in how they you see the python code as not seeing contexts and acquistion in the same way that DTML does? Python scripts allow for a fair bit of power by allowing you to specify exactly what it is you want to do.
o I am trying to use the SQL Session object from within a python script, and am having all kinds of difficulty.
This part I can't help with since I don't tend to do anything with SQL.
I am starting to believe that it is cleaner (although not as powerful) to use DTML exclusively (and python only for that which is impossible in DTML). This' kind of saddens me as the "Zope Book" suggests that python is highly interchangeable with, and more powerful than DTML.
Overall I would recommend going to python almost exclusively instead of DTML. Then just use the simplest DTML constructs needed to render the output from python.
Am I totally off base? Is there some valuable reading that I have missed? How do experienced ZOPErs view this issue?
I think you are making the mistake of using DTML to put the logic in and since you have been doing that for a while it seems easier. However if you know python or take the time to learn it fairly well then you will find the making python scripts is usually a lot faster then making DTML code and easier to maintain. Also check out irc.openprojects.net #zope there are often those around that can help depending on what time of day you ask for help. Overall I like DTML a lot since it allows you to seperate a page into many little objects that know how to behave in various situations. I find this makes it very easy to plug things together to build complex solutions. However DTML is for presentation not for logic so put the logic in python code where it fits better.
roy, im only addressing a smallish part of your mail, which does convey, to me at least, a sense that you have things a bit back to front! i tend to agree that mixing python and DTML is hellish, from an aesthetic point of view if nothing else! to be fair, it was never intended for this purpose... my experience is that its too easy to keep cramming logic into DTML where you should really be putting it into python. i always feel bad doing it (a couple of hundred 20-30K dtml methods = an unmaintainable mix of presentation & logic), but i keep doing it because its quicker... and easy... the way forward is not trying to cram more logic into DTML, but less. python really is your friend! (though i guess its hard for people who came to python via zope, rather than zope via python - i should know, im one of them) better still, give zope page templates (zpt) a swirl: i find its a lot easier to avoid the nastier excesses i find myself perpetrating with DTML and it just feels like a better match for the task... the zope book has a couple of new chapters and a new appendix on zpt which is a good place to start... if you have more pressing, specific problems the list is usually a good place to look for help... hth, garry On 28 Feb 2002, at 23:39, Roy Mathew wrote: From: Roy Mathew <roy@anoobe.com> To: zope@zope.org Send reply to: roymath@yahoo.com Subject: [Zope] mixing python and DTML is hellish! Date sent: Thu, 28 Feb 2002 23:39:54 -0500
Folks,
I have been trying out Zope, and am now getting beyond the trivial. I do have a question about python vs DTML.
What I am finding is that mixing and matching python scripts and DTML (methods and documents) is rather hellish/confusing. For example:
o descending into python and then back up to DTML is hard, when you are trying to use acquisition. The python code does not understand contexts and acquisition in quite the same way as DTML.
o I am trying to use the SQL Session object from within a python script, and am having all kinds of difficulty.
I am starting to believe that it is cleaner (although not as powerful) to use DTML exclusively (and python only for that which is impossible in DTML). This' kind of saddens me as the "Zope Book" suggests that python is highly interchangeable with, and more powerful than DTML.
Am I totally off base? Is there some valuable reading that I have missed? How do experienced ZOPErs view this issue?
Roy.
_______________________________________________ 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 )
+-------------------------------------------+ Garry Steedman mailto:gs@styrax.com Styrax Associates http://www.styrax.com/ "The Good Man has no shape." +-------------------------------------------+
Roy Mathew wrote:
Am I totally off base? Is there some valuable reading that I have missed? How do experienced ZOPErs view this issue?
Yup ;-) Take a morning, learn ZPT, forever banish DTML back to the pits of hell where it belongs and your life will once again be peaceful and happy. Use the templating language to do layout, use the python scripts to do logic. good luck, Chris
On Fri, 1 Mar 2002, Chris Withers wrote:
Roy Mathew wrote:
Am I totally off base? Is there some valuable reading that I have missed? How do experienced ZOPErs view this issue?
Yup ;-)
Take a morning, learn ZPT, forever banish DTML back to the pits of hell where it belongs and your life will once again be peaceful and happy.
Actually I have to defend DTML on this one. I do think it is a good 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. I prefer having lots of little objects around that get assembled together to build a page. Especially when working with smarter objects. Overall DTML is easier to use with this kind of a model by a good deal. 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. Overall it seems ZPT seems designed for html people that used wysiwyg editors to write pages. 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.
Use the templating language to do layout, use the python scripts to do logic.
This we can agree on. I feel just about everything should be in python and the page template stuff should just be used for calling the objects.
Designing and building web applications http://webme-eng.com
<kosh@aesaeion.com> writes:
This we can agree on. I feel just about everything should be in python and the page template stuff should just be used for calling the objects.
Something like Webobjects in Python? Without management interface? Sounds too good to become true :) Regards, Frank
Frank Tegtmeyer wrote:
<kosh@aesaeion.com> writes:
This we can agree on. I feel just about everything should be in python and the page template stuff should just be used for calling the objects.
Something like Webobjects in Python? Without management interface? Sounds too good to become true :)
I believe it's called "Zope 3" ;-) cheers, Chris
From: <kosh@aesaeion.com>
Overall it seems ZPT seems designed for html people that used wysiwyg editors to write pages.
No. It's designed for people that create *web design* with wysiwyg editors. Almost everybody does that. If you want to hack the design by hand, thats fine. I do, mostly. But most people prefer using dreamweaver or something like that, and I would probably too, if I wasn't hampered by dtml...
On Sat, 2 Mar 2002, Lennart Regebro wrote:
From: <kosh@aesaeion.com>
Overall it seems ZPT seems designed for html people that used wysiwyg editors to write pages.
No. It's designed for people that create *web design* with wysiwyg editors. Almost everybody does that. If you want to hack the design by hand, thats fine. I do, mostly. But most people prefer using dreamweaver or something like that, and I would probably too, if I wasn't hampered by dtml...
I design using my knowledge of the spec. I figure out what I want to do and break it down into essentially a DOM model in my head and write that. It usually goes very quickly and remembering the details is not very hard. Actually our customers hire my company because most other companies hack things together with dreamwaver and other wysiwyg editors. They are tired of the complaints, about pages loading slowly because of the abuse of the DOM model. They might not know exactly why some pages take so long to render once they browser gets them but they can see the results of doing it the right way. You can continue to design with dreamweaver and in general abuse how the markup tags where designed and what you will find over time is that fewer search engines will give you very good hits. There is a good deal of work being done to allow the search engines to take the markup of the page into account on their indexing in order to give better search results. If tags are not closed properly, used properly etc it won't work as well. Also I don't like having to go back and do maintenance on a site very often so it works better long term just to adhere exactly to the spec in a way that works in all the browsers which is pretty easy.
From: <kosh@aesaeion.com>
If tags are not closed properly, used properly etc it won't work as well.
Are you trying to tell me that this is achieved more easily by NOT using a wysiwyg editor that takes care of that for you, but instead hack the code manally in a text-editor?
Also I don't like having to go back and do maintenance on a site very often so it works better long term just to adhere exactly to the spec in a way that works in all the browsers which is pretty easy.
And that would be impossible to do with Dreamweaver? Come on... Most people create the design with a wysiwyg editor because it's easier and it's faster, and none of the things you claim are common problems have anything to do with using a wysiwyg editor to make the design. You are clutching to straws in your argumentation. I suspect thats all I have to add to the discussion.
On Sat, 2 Mar 2002, Lennart Regebro wrote:
From: <kosh@aesaeion.com>
If tags are not closed properly, used properly etc it won't work as well.
Are you trying to tell me that this is achieved more easily by NOT using a wysiwyg editor that takes care of that for you, but instead hack the code manally in a text-editor?
Yes I think that is easier to do without a wysiwyg editor. Using vim or emacs is easier then using one of those editors. The wysiwyg editors gets in the way of being able to track all the code and the model mentally.
Also I don't like having to go back and do maintenance on a site very often so it works better long term just to adhere exactly to the spec in a way that works in all the browsers which is pretty easy.
And that would be impossible to do with Dreamweaver?
I find it harder to do in those apps then just doing the work by hand. I can just type out what I want and not worry about pointing and clicking on various things. I can type a lot faster then I can move the mouse around and click on things. Drag and drop interfaces are good for some things but making source code is not one of them.
Come on... Most people create the design with a wysiwyg editor because it's easier and it's faster, and none of the things you claim are common problems have anything to do with using a wysiwyg editor to make the design. You are clutching to straws in your argumentation.
It may be faster for the unskilled but it also produces worse pages. However I find that if you have read the html, xhtml, css, dom, etc specs and know them then it is faster to develop manually then using any of those helpful editors. Overall I have not liked code generation tools for any language since you spend more time cleaning up afterwards then it would take to write the code by hand.
I suspect thats all I have to add to the discussion.
kosh@aesaeion.com wrote:
I find it harder to do in those apps then just doing the work by hand.
I'd suggest that there are a lot of people who find it easier ;-)
I can just type out what I want and not worry about pointing and clicking on various things.
Have you actually used Dreamweaver?
It may be faster for the unskilled but it also produces worse pages.
What are you basing that statement on?
However I find that if you have read the html, xhtml, css, dom, etc specs and know them then it is faster to develop manually then using any of those helpful editors.
Uhuh, so the features of said editor that let you check for those things, and , more importantly, the behaviour of various browsers (all of which pay little or no attention to the specs ;-) are worthless? I don't think so, I actually think that for people who don't have time to read the specs (man, how much time do you have?!) tools like Dreamweaver provide a method of producing more reliable and robust HTML.
Overall I have not liked code generation tools for any language since you spend more time cleaning up afterwards then it would take to write the code by hand.
You are in a minority ;-) I suspect you've used some really bad tools in the past and are now using those experiences to judge every other tool that comes along. Well, I'm sorry you need to hang on to those views... cheers, Chris
On Sat, 2 Mar 2002, Chris Withers wrote:
kosh@aesaeion.com wrote:
I find it harder to do in those apps then just doing the work by hand.
I'd suggest that there are a lot of people who find it easier ;-)
I'd suggest lots of people find it easier to write apps in VB then other languages. However that does not make VB a good choice. The programs tend to be slower, user more memory, be more crash prone, and have no security to them.
I can just type out what I want and not worry about pointing and clicking on various things.
Have you actually used Dreamweaver?
Yes
It may be faster for the unskilled but it also produces worse pages.
What are you basing that statement on?
From looking at the source code of the page.
However I find that if you have read the html, xhtml, css, dom, etc specs and know them then it is faster to develop manually then using any of those helpful editors.
Uhuh, so the features of said editor that let you check for those things, and , more importantly, the behaviour of various browsers (all of which pay little or no attention to the specs ;-) are worthless? I don't think so, I actually think that for people who don't have time to read the specs (man, how much time do you have?!) tools like Dreamweaver provide a method of producing more reliable and robust HTML.
Would you trust a contractor to build a house if they did not know the building specs in an area? How about a programmer that did not read the specs for the language they where using? Overall it comes down to a simple fact. If you are going to be working with a tool professionally it is your job to take it professionally. That means taking the time to read about how the tools work and what the requirements are for working in the field you are. Computer programs tend to be the bug ridden pieces of crap that they are because so many ignore that. It is the same with web pages. I am sorry that it takes time to learn information but that is what it takes and that is what has to be done. Sure you can avoid it for a while but it will catch up with you. The specs are updated about once a year at most and it should only take about 10 hours to learn at least most of html/xhtml and css which should cover most of what people need. Also you would be surprised how much attention to specs browsers really pay. If you specify a strict doctype most of the newer browsers render differently and render faster so long as there are no errors.
Overall I have not liked code generation tools for any language since you spend more time cleaning up afterwards then it would take to write the code by hand.
You are in a minority ;-) I suspect you've used some really bad tools in the past and are now using those experiences to judge every other tool that comes along. Well, I'm sorry you need to hang on to those views...
I have used some that where supposed to be pretty good but I still did not like them. Overall if you have a good memory and can read fast it is faster to just learn how the system works and do it by hand instead of having the computer make guesses for you.
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of kosh@aesaeion.com
I haven't been following this thread, but I cannot keep myself from butting in...
I'd suggest that there are a lot of people who find it easier ;-)
Easier and much more productive. I'm one of those, and I've been doing this professionally for 7 years.
I'd suggest lots of people find it easier to write apps in VB then other languages. However that does not make VB a good choice. The programs tend to be slower, user more memory, be more crash prone, and have no security to them.
This analogy doesn't fit. DW can be used to create equally clean HTML as hand coding (this cannot be said for all editors). Both methods result in plain text files with HTML markup. VB, by design, cannot produce what could be done in lower level languages.
It may be faster for the unskilled but it also produces worse pages.
Any tool misused can produce worse results than not using the tool at all. User knowledge cannot be replaced by a good tool. However, used properly, a good tool can produce equally good results in less time.
It may be faster for the unskilled but it also produces worse pages.
What are you basing that statement on?
From looking at the source code of the page.
Then you've only looked at source code from sloppy developers, or your standards are unrealistic. Many of the pages I produce have little signs of DW and do meet the specs.
However I find that if you have read the html, xhtml, css, dom, etc specs and know them then it is faster to develop manually then using any of those helpful editors.
If you've found that to be the case, then you're free to keep hand coding. However, I've found quite the opposite; hand coding takes far more time than proper use of a good editor, and I'm less likely to make careless mistakes.
Overall it comes down to a simple fact. If you are going to be working with a tool professionally it is your job to take it professionally. That means taking the time to read about how the tools work and what the requirements are for working in the field you are.
I agree 100%. Which is why I have taken more time than my wife can stand learning the languages I use as well as the tools I use.
Computer programs tend to be the bug ridden pieces of crap that they are because so many ignore that. It is the same with web pages. I am sorry that it takes time to learn information but that is what it takes and that is what has to be done. Sure you can avoid it for a while but it will catch up with you.
I agree 100% with this too. Bad pages are a result of ignorant developers (or developers that just don't care). They're also a result of effective marketing that makes people believe anyone can create "great looking Web pages" with no knowledge of HTML. Sadly, "poor" Web pages are often the result of working around years of different browser bugs. I have to crap up more pages because of browser bugs than any other reason, but that's another story.
Overall I have not liked code generation tools for any language since you spend more time cleaning up afterwards then it would take to write the code by hand.
DW creates quite clean code when configured and used properly. This cannot be said for all editors. For something relevant to this mailing list... DW has been very kind to me when using both DTML and ZPT. It's not without its quirks, but with my years of experience, I can use it to create clean standards-based pages that work wonderfully in Zope in far less time than I ever could by hand. _______________________ Ron Bickers Logic Etc, Inc.
DW can be used to create equally clean HTML as hand coding (this cannot be said for all editors).
That, I suppose, would depend on your definition of clean HTML. If by clean HTML, you mean HTML3.2 then yeah, I'll agree. Well sort of, DW(I have 4) doesn't, that I could find anyway, have a mechanism to add a DOCTYPE(and doesn't by default) which if you have read the specs are required to meet a spec. So assuming you add one by hand, DW creates HTML3.2, maybe 4.0 Transitional, if you are careful and do NOT use anything that inserts <font> then maybe 4.0 strict, XHTML is out of the question. Now I have no proof that by adding a DOCTYPE that the DW markup would validate even to HTML3.2, but I am willing to give it the benefit of the doubt.
-----Original Message----- From: Jeff Peterson [mailto:jpeterso@rangebroadband.com]
That, I suppose, would depend on your definition of clean HTML.
True. I was mostly comparing it to the hatchet job many visual editors do to the HTML as well as to the "clean" HTML that can be created by hand coding. That is to say, DW does a descent job at formatting and doesn't add a bunch of unnecessary junk to the code it creates through the visual editor.
Transitional, if you are careful and do NOT use anything that inserts <font> then maybe 4.0 strict, XHTML is out of the question. Now I have no proof that by adding a DOCTYPE that the DW markup would validate even to HTML3.2, but I am willing to give it the benefit of the doubt.
Sure, you still have to know which features to use and which ones not to in order to get strictly valid documents. DW does have a validation feature to run your document through various standards, though I don't know how good it is and I suspect not many people use it or care what it says. Most importantly, DW doesn't hack up my ZPT or DTML markup. _______________________ Ron Bickers Logic Etc, Inc.
DW does have a validation feature to run your document through various standards, though I don't know how good it is and I suspect not many people use it or care what it says.
I did notice the validation feature, though I did not try it. It is the last part that concerns me though, people not caring is at the very least unfortunate.
Most importantly, DW doesn't hack up my ZPT or DTML markup.
This is, in my opinion, the most important feature of any wysiwyg editor, not hosing up _my_ code. -- Jeffrey D. Peterson Webmaster & Resident Standards Warrior "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was."
Lennart Regebro wrote:
have anything to do with using a wysiwyg editor to make the design. You are clutching to straws in your argumentation.
Oh, he's been doing that for a coupla days now, it's kinda fun to watch and poke every so often ;-) *grinz* Chris
participants (9)
-
Chris Withers -
Frank Tegtmeyer -
Garry Steedman -
Jeff Peterson -
kosh＠aesaeion.com -
Lennart Regebro -
Ron Bickers -
Ron Bickers -
Roy Mathew