Re: ZClasses useful! [Was: ZMI / JavaScript brainstorm]
I will not stop dissing them until people stop using them and then complaining when they break, don't do what they want or behave unexpectedly.
What's your efford on this task? If people like to use them, let them! It's not up to you to decide for THEM what's best or not. The choice for YOURSELF not to use them is just as fair as other peoples choices. martijn.
On Tue, 9 Apr 2002, Martijn Jacobs wrote:
I will not stop dissing them until people stop using them and then complaining when they break, don't do what they want or behave unexpectedly.
What's your efford on this task? If people like to use them, let them! It's not up to you to decide for THEM what's best or not. The choice for YOURSELF not to use them is just as fair as other peoples choices.
Actually, we find on #zope-dev that if we steer newbies away from zclasses and toward Products to begin with, they thank us later, and it reduces our support burden. The same can be said for this list. Chris does tend to be a little vociferous about it <grin>. We aren't generally dealing with content devloper types in either place. Learning ZClasses (because that's what was documented in the manual at the time) rather than going straight to python products was the *worst* mistake I made in starting to use Zope, myself. It probably set me back six to nine months. --RDM
What's your efford on this task? If people like to use them, let them! It's not up to you to decide for THEM what's best or not. The choice for YOURSELF not to use them is just as fair as other peoples choices.
Sure but many people ask more experienced developers for advice. I agree saying ZClasses suck totally is unhelpful. For people who dont know coding or want to do quick prototyping they have a place. However if someone asks me how to do a product, I normally give them the choice: use ZClasses but I would strongly recommend using a Product etc (and then be ready with the reasons why which is the next question). Unfortunately people deciding the right and wrong ways for other people to code is a trait sometimes found in Python / Zope world. But dont get me started on that :) -- Andy McKay
Maybe a little Perl psychology might help us here, i.e. "There is more than one way to do it" - Some are faster, some more feature rich, and (in this case) some are TTW codeable. The only ones that are actually _wrong_ are the ones that don't work at all. ZClasses are one of the two things that bring Zope up to and above the level of the competition (In this case Coldfusion) IMHO - TTW coding, including writing products TTW, and DTML which is far more powerful and focused than the competitions offering. I think that blindly disposing of both, just because a newer idea has come along is just that - blind. So what if ZPT is more (choose your comparison here) than DTML? DTML is far easier to learn, far easier to read, far easier to write, and much much easier to explain to newbies. It has always been clear that ZClasses are the poor relation of Python products, but even that does not earn ZClasses a death warant (IMHO) - Have you never needed a quick fix product that needs writing in a few minutes and in a week will no longer be needed? I know I have - Many MANY times! Just my $0.02 Adrian... ----- Original Message ----- From: "Andy McKay" <andy@agmweb.ca> To: "Martijn Jacobs" <mart@eastsite.nl>; <zope-dev@zope.org> Sent: Wednesday, April 10, 2002 3:52 AM Subject: Re: [Zope-dev] Re: ZClasses useful! [Was: ZMI / JavaScript brainstorm]
What's your efford on this task? If people like to use them, let them! It's not up to you to decide for THEM what's best or not. The choice for YOURSELF not to use them is just as fair as other peoples choices.
Sure but many people ask more experienced developers for advice. I agree saying ZClasses suck totally is unhelpful. For people who dont know coding or want to do quick prototyping they have a place. However if someone asks me how to do a product, I normally give them the choice: use ZClasses but I would strongly recommend using a Product etc (and then be ready with the reasons why which is the next question).
Unfortunately people deciding the right and wrong ways for other people to code is a trait sometimes found in Python / Zope world. But dont get me started on that :) -- Andy McKay
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Adrian Hungate writes:
.... DTML and ZCLasses ... I think that blindly disposing of both, just because a newer idea has come along is just that - blind. So what if ZPT is more (choose your comparison here) than DTML? DTML is far easier to learn, far easier to read, far easier to write, and much much easier to explain to newbies. I see this exactly the other way round: ZPT is easier than DTML.
Otherwise, I agree with you... Dieter
Ok, ZPT is easier that DTML? How do you code this in ZPT? <dtml-in objectIds() sort=id> <dtml-var sequence-item> </dtml-in> Last I checked, sorting and batching were difficult to the extreme in ZPT. If we are aiming to be a Web Application Server, we have to assume that people are going to want to generate sorted lists of data, in batches. Also, have you tried explaining ZPT to ASP programmers? Trying to turn an ASP designer from the Dark Side is not being made any easier by either the uncertainty about the programming platform, or by moving from a simple, HTML based language, to an attribute based language that allows you to use and abuse HTML tags in potentially confusing ways... <hr tal:replace="structure here/standard_html_footer" /> I rest my case. Adrian... ----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de> To: "Adrian Hungate" <adrian@haqa.co.uk> Cc: "Andy McKay" <andy@agmweb.ca>; "Martijn Jacobs" <mart@eastsite.nl>; <zope-dev@zope.org> Sent: Tuesday, May 07, 2002 9:09 PM Subject: Re: [Zope-dev] Re: ZClasses useful! [Was: ZMI / JavaScript brainstorm]
Adrian Hungate writes:
.... DTML and ZCLasses ... I think that blindly disposing of both, just because a newer idea has come along is just that - blind. So what if ZPT is more (choose your comparison here) than DTML? DTML is far easier to learn, far easier to read, far easier to write, and much much easier to explain to newbies. I see this exactly the other way round: ZPT is easier than DTML.
Otherwise, I agree with you...
Dieter
Adrian Hungate wrote:
Ok, ZPT is easier that DTML? How do you code this in ZPT?
<dtml-in objectIds() sort=id> <dtml-var sequence-item> </dtml-in>
You have some good points, but there's a certain irony in the fact that the above code won't work. You either forgot to quote the "objectIds()" expression, or it shouldn't have parentheses, illustrating the first ugly thing most people run into when learning DTML. :-) Nevertheless, as you said, ZPT really does need some better way to implement batching and sorting. The need is too common to require external scripts or big Python expressions to do it. Shane
On Tue, May 07, 2002 at 05:35:55PM -0400, Shane Hathaway wrote:
Adrian Hungate wrote:
Ok, ZPT is easier that DTML? How do you code this in ZPT?
<dtml-in objectIds() sort=id> <dtml-var sequence-item> </dtml-in>
You have some good points, but there's a certain irony in the fact that the above code won't work. You either forgot to quote the "objectIds()" expression, or it shouldn't have parentheses, illustrating the first ugly thing most people run into when learning DTML. :-)
Nevertheless, as you said, ZPT really does need some better way to implement batching and sorting. The need is too common to require external scripts or big Python expressions to do it.
Shane
I agree with the irony and all that, and have tried several times to switch to zpt. I am finally almost there. But, I also agree with Adrian's thrust, DTML is a simple useful language, that, ignoring the quoting problems and all the _ namespace magic, can be picked up by anyone with an imperative language background in a couple of days. (Now, the quoting problems are indeed gross). There is also far too much magic in DTML, especially in name lookup. ZPT is, in fact, a much more controllable artifact. It is also ugly, and almost completely non-intuitive. It seems far harder to map to conventional languages. In fact, I am wondering if ZPT code may not prove to be harder to maintain, mostly because I have real trouble finding the tal: statements while scanning the program. In particular, tal:repeat seems nowhere near as easy to find as <dtml-in>. I suspect that a great deal of my problem is that ZPT is an infix or a suffix-like notation, where DTML was a prefix notation. I am used to skipping infixes to some extent, especially on first reading. I am going to be honest, I think I could probably do no better, given the constraints of embedding in XML. The biggest change for the better that I see is that it is now easy to use a script (Python) [still lobbying for Snake Thingie] as index_html. Jim Penny
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Jim Penny wrote:
But, I also agree with Adrian's thrust, DTML is a simple useful language, that, ignoring the quoting problems and all the _ namespace magic, can be picked up by anyone with an imperative language background in a couple of days. (Now, the quoting problems are indeed gross). There is also far too much magic in DTML, especially in name lookup.
So you see, DTML isn't actually simple ;-) It appears simple, until you try and do anything useful with it. Then, all of a sudden, you have to use the quoting, the _, and you have to try and make sure you're <dtml-var some_variable>'s are coming from the right place, not calling something when they don't mean to, etc, etc...
ZPT is, in fact, a much more controllable artifact. It is also ugly, and almost completely non-intuitive.
Well, come up with something more intuitive then, and less ugly, which actualyl solves the problem :-) I think ZPT is pretty good considering how difficult the problems are it's trying to solve...
It seems far harder to map to conventional languages.
Such as? I don't think that an improtant requirement is for a templating language to look like a programming language. If that's the case, why not just use Python Scripts and string substitution?
In fact, I am wondering if ZPT code may not prove to be harder to maintain, mostly because I have real trouble finding the tal: statements while scanning the program.
Just use a normal HTML syntax highlighter.
In particular, tal:repeat seems nowhere near as easy to find as <dtml-in>.
I actually find the opposite true ;-)
I suspect that a great deal of my problem is that ZPT is an infix or a suffix-like notation, where DTML was a prefix notation. I am used to skipping infixes to some extent, especially on first reading.
Well, this kindof supports a feeling I have that DTML actually forces you into a pattern of thinking incorrectly. I have seen no new Zope users complaning about ZPT, I have see plenty of new Zope users getting baffled and confused by DTML, I remember, I was one of them!
The biggest change for the better that I see is that it is now easy to use a script (Python) [still lobbying for Snake Thingie] as index_html.
yup :-) cheers, Chris
On Wednesday 08 May 2002 04:36 am, Chris Withers allegedly wrote: [snip]
It seems far harder to map to conventional languages.
Such as? I don't think that an improtant requirement is for a templating language to look like a programming language. If that's the case, why not just use Python Scripts and string substitution?
The fact that ZPT finally comes to grips with the fact that templating is different than programming is its greatest strength IMHO. Since ZPT encourages a greater level of abstraction then DTML does, it can exacerbate the "where's the beef" problem a bit. However, I would argue that there is still too much mixing of presentation and logic, even in ZPT. Someday, I intend to change that. -Casey
This would have turned up the the testing, My normally save is Save/View/Back (if you see what I mean). Blame it on 2 weeks of non-stop C++ programming... My head hurts and the project is only half finished. Adrian... ----- Original Message ----- From: "Shane Hathaway" <shane@zope.com> Newsgroups: zope.dev To: "Adrian Hungate" <adrian@haqa.co.uk> Cc: "Dieter Maurer" <dieter@handshake.de>; "Andy McKay" <andy@agmweb.ca>; "Martijn Jacobs" <mart@eastsite.nl>; <zope-dev@zope.org> Sent: Tuesday, May 07, 2002 10:35 PM Subject: Re: [Zope-dev] Re: ZClasses useful! [Was: ZMI / JavaScript brainstorm]
Adrian Hungate wrote:
Ok, ZPT is easier that DTML? How do you code this in ZPT?
<dtml-in objectIds() sort=id> <dtml-var sequence-item> </dtml-in>
You have some good points, but there's a certain irony in the fact that the above code won't work. You either forgot to quote the "objectIds()" expression, or it shouldn't have parentheses, illustrating the first ugly thing most people run into when learning DTML. :-)
Nevertheless, as you said, ZPT really does need some better way to implement batching and sorting. The need is too common to require external scripts or big Python expressions to do it.
Shane
Adrian Hungate wrote:
This would have turned up the the testing, My normally save is Save/View/Back (if you see what I mean).
...as opposed to ZPT which would have given you a nice error message explaining exactly where the error was and what caused it, even if it was just because you hadn't closed a </table> ;-) cheers, Chris
On 5/8/02 2:38 AM, "Chris Withers" <chrisw@nipltd.com> wrote:
Adrian Hungate wrote:
This would have turned up the the testing, My normally save is Save/View/Back (if you see what I mean).
...as opposed to ZPT which would have given you a nice error message explaining exactly where the error was and what caused it, even if it was just because you hadn't closed a </table> ;-)
This is especially nice when using an FTP/WebDAV tool. You can keep saving and saving and saving, with errors, and then get a report from the ZMI. While saving with errors may sound wrong to some, remember that you can save ASP pages with all the errors you want, there's nothing that's going to check them until compile/execution time. And, it's MUCH better than the cryptic FTP save errors one gets when forgetting to close a <dtml-if>, or using <dtml-and> outside of a <dtml-sqlgroup>. -- Jeffrey P Shell www.cuemedia.com
Jeffrey P Shell writes:
... And, it's MUCH better than the cryptic FTP save errors one gets when forgetting to close a <dtml-if>, or using <dtml-and> outside of a <dtml-sqlgroup>. You know there is a patch providing better FTP error messages.
One of the many patches that failed to be incorporated into the Zope core despite their usefullness... Dieter
Shane Hathaway wrote:
Nevertheless, as you said, ZPT really does need some better way to implement batching and sorting. The need is too common to require external scripts or big Python expressions to do it.
Now that I'd agree with. I also think ZPT (METAL in particular from what I hear) need some serious optimisation. But, given how old ZPT is compared to DTML, surely it says something about DTML that ZPT has already managed to outperform it in so many areas? cheers, Chris
Vi/Emacs war anyone? :) Seriously though, what, exactly, was so broken about DTML that fixing it became so vital? Given the strengths of DTML I still maintain that ZPT is no (yet?) a complete replacement, and given the comfortable, familiar syntax, I doubt that it should ever replace DTML completely, even if most pages are ZPT. I would be very supprised (Not to mention impressed) if by 2.6 ZPT can comfortably replace every aspect of DTML without having to employ Python scripts, or some arcane incantations. Don't get me wrong, ZPT is likely to be a very useful supliment to the existing Zope tools, but I would no more suggest replacing Python Scripts, than DTML. Just my $0.02 Adrian... ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: "Shane Hathaway" <shane@zope.com> Cc: "Adrian Hungate" <adrian@haqa.co.uk>; "Dieter Maurer" <dieter@handshake.de>; "Andy McKay" <andy@agmweb.ca>; "Martijn Jacobs" <mart@eastsite.nl>; <zope-dev@zope.org> Sent: Wednesday, May 08, 2002 9:30 AM Subject: Re: [Zope-dev] ZPT is young
Shane Hathaway wrote:
Nevertheless, as you said, ZPT really does need some better way to implement batching and sorting. The need is too common to require external scripts or big Python expressions to do it.
Now that I'd agree with. I also think ZPT (METAL in particular from what I hear) need some serious optimisation.
But, given how old ZPT is compared to DTML, surely it says something about DTML that ZPT has already managed to outperform it in so many areas?
cheers,
Chris
On Wednesday 08 May 2002 14:54, Adrian Hungate wrote:
Given the strengths of DTML I still maintain that ZPT is no (yet?) a complete replacement, and given the comfortable, familiar syntax, I doubt that it should ever replace DTML completely, even if most pages are ZPT. I would be very supprised (Not to mention impressed) if by 2.6 ZPT can comfortably replace every aspect of DTML without having to employ Python scripts, or some arcane incantations.
Isn't that one of the points of using ZPT instead of DTML? You are able to do far too much in DTML; a somewhat peculiar strength of ZPT is that you are not able to do so much, so you'll have to refactor and put functionality in python scripts thus separating content and functionality.
Don't get me wrong, ZPT is likely to be a very useful supliment to the existing Zope tools, but I would no more suggest replacing Python Scripts, than DTML.
DTML is great for style sheets, javascript and such where you cannot use ZPT and python scripts would be too ugly to use ;-) -- Regards, Thomas Olsen
Yeah, for CSS I'd use ZStyleSheets, and for javascript I'd use a very large magnet... but that is another argument. Adrian... ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: "Thomas Olsen" <tol@tanghus.dk> Cc: "Adrian Hungate" <adrian@haqa.co.uk>; "Shane Hathaway" <shane@zope.com>; "Dieter Maurer" <dieter@handshake.de>; "Andy McKay" <andy@agmweb.ca>; "Martijn Jacobs" <mart@eastsite.nl>; <zope-dev@zope.org> Sent: Thursday, May 09, 2002 8:47 AM Subject: Re: [Zope-dev] ZPT is young
Thomas Olsen wrote:
DTML is great for style sheets, javascript and such where you cannot use
ZPT
and python scripts would be too ugly to use ;-)
There's no reason to use DTML for these, as I've explained before ;-)
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Thursday 09 May 2002 09:47, Chris Withers wrote:
Thomas Olsen wrote:
DTML is great for style sheets, javascript and such where you cannot use ZPT and python scripts would be too ugly to use ;-)
There's no reason to use DTML for these, as I've explained before ;-)
Must have missed that mail..? -- Regards, Thomas Olsen
Thomas Olsen wrote:
Must have missed that mail..?
http://zope.nipltd.com/public/lists/dev-archive.nsf/$$Search?OpenForm cheers, Chris
On Wednesday 08 May 2002 08:54 am, Adrian Hungate allegedly wrote:
Vi/Emacs war anyone? :)
Seriously though, what, exactly, was so broken about DTML that fixing it became so vital?
It was mostly motivated by the desire to be able to edit dynamic templates with WYSIWIG tools (like dreamweaver), something that is not possible with DTML. Also it was an implementation of the desire to acheive greater separation of presentation and logic. Something not encouraged by DTML. Another reason was the desire to increase the explicitness of the language. IOW, make it less magical, less unpredictable. DTML also encourages a mixing of content with logic (ala DTML Document), something ZPT does not. Although I am befuddled by the whole ZPTPage thing in Zope 3....Hmmm, maybe I'm wrong here 8^/
Given the strengths of DTML I still maintain that ZPT is no (yet?) a complete replacement, and given the comfortable, familiar syntax, I doubt that it should ever replace DTML completely, even if most pages are ZPT. I would be very supprised (Not to mention impressed) if by 2.6 ZPT can comfortably replace every aspect of DTML without having to employ Python scripts, or some arcane incantations.
ZPT is not a complete replacement for DTML. It is just another way to do templating. By design, it is less powerful than DTML. It is better suited to templating most SGML documents tho IMHO, which are often in the majority in Zope apps. That said, ZPT sux for templating plain text documents.
Don't get me wrong, ZPT is likely to be a very useful supliment to the existing Zope tools, but I would no more suggest replacing Python Scripts, than DTML.
DTML is not going anywhere. Its just not the only game in town anymore. -Casey
On 5/8/02 6:54 AM, "Adrian Hungate" <adrian@haqa.co.uk> wrote:
Seriously though, what, exactly, was so broken about DTML that fixing it became so vital?
There are many things. DTML started its life as basically a reporting focused template language to be used in conjunction with Bobo objects. There were no expr's in those days, they weren't really needed - editing templates through the web was an uncommon thing, and where it was common, you were editing very focused templates that belonged to a very focused application (like tweaking how a report of engine parts would be displayed). It was not intended to be a programming language - just a more advanced version of server side includes. But, as Principia and then Zope grew, it was the main way of gluing everything together. Thus, more and more programming oriented constructs found their way in to DTML along side the reporting oriented constructs. And they grew kindof haphazardly. Plus, people's desires for shortcuts have made for some delightful obfuscations. The fact that <dtml-var foo> and <dtml-var "foo"> can produce wildly different results stopped giving me that old "comfortable, familiar" feeling a long time ago. And the old games and debates over how <dtml-set> might work and how often "REQUEST.set()" gets used, even when its known to be bad... It's just headache. And how about the fact that you never really know how some DTML tag parameters are going to be interpreted? Some are interpreted as a literal string, some as an name lookup, some as an expression. Granted, some of these latter points could be solved by making a TALES aware revision of DTML. A big broken thing about DTML was that often, a designer would make a look for the site, and a DTML programmer would deconstruct it into multiple little DTML objects. When the design changed, reflecting that change across multiple little DTML objects could at times be excruciating. But ultimately, with the power of things like the name lookup (<dtml-var foo>), and the namespace, DTML was really easy to make into components. Sometimes that would come in as a maintenance win (just fix the right component), sometimes at a loss (major design changes meant lots of tweaking, testing, and tweaking and testing some more). On the other hand, I'm making some really nice ZPT based admin interfaces in GoLive 6 right now, coupled with Python Scripts and SQL Methods. It's some of the best looking UI work I've done in years, and it's great to be able to use the tool and switch effortlessly between Visual and Source modes, and not have the Visual mode peppered with unknown or broken looking tags (the visual editors never seemed to care much for code like: <input type="checkbox" ... <dtml-if expr="foo == bar">checked</dtml-if>> However, they're not caring too much over: <input type="checkbox" ... tal:attributes="checked python:foo == bar"> )
Given the strengths of DTML I still maintain that ZPT is no (yet?) a complete replacement, and given the comfortable, familiar syntax, I doubt that it should ever replace DTML completely, even if most pages are ZPT. I would be very supprised (Not to mention impressed) if by 2.6 ZPT can comfortably replace every aspect of DTML without having to employ Python scripts, or some arcane incantations.
It's not a complete replacement, no. DTML is still very good for SQL methods, although much of this has to do with the wonderful <dtml-sqlxxx> tags. DTML does have all that great batching/sorting/reporting stuff built in, while ZPT uses the heavily underdocumented ZTUtils module to provide default implementations of those features (another pro-ZPT note, you can implement and use your own Batcher much more easily in ZPT than in DTML). What's wrong with employing Python scripts? They're much easier to read and write than DTML, and actually go back to the old Bobo way of doing things. In Bobo, before the days of expr's, it was common to have some utility methods on a class that would return data in a form easy to use in DTML, making the DTML cleaner, and making changes into the algorithms that returned that data was easier to manage. Translating from DTML to ZPT is hard. To do this best, one really has to re-architect the presentation layer of their site, rather than trying to just replace DTML with ZPT straight across. But after working with ZPT, especially in situations where I have a blank slate, I find it to be a much better design and usage philosophy. There are still some sharp corners, and I still don't understand how to make the equivalent of the <dtml-tree> tag at all, let alone how to start customizing it.
Don't get me wrong, ZPT is likely to be a very useful supliment to the existing Zope tools, but I would no more suggest replacing Python Scripts, than DTML.
Likely to be? I say it is the most useful supplement to the existing Zope tools that there has been in a long time. ZPT and Python Scripts were raised in a day when the mistakes of the past could be learned from. If some of the techniques used in them could find their way into DTML Documents/Methods and SQL Methods, I'd be very happy indeed. For my closing statement - in my experience there are far fewer surprises in using Page Templates than in DTML. I like this. TALES opens up the possibility for future expression languages. In DTML, expression support is decided on an attribute by attribute basis and is fixed at tag development time. In Page Templates, being able to use a single "master page" metal macro is FAR better than standard_html_header and standard_html_footer. Trying to keep tags balanced between two separate files when a page design gets complex gets to be a royal pain in the ass, no matter how proficient you are with DTML (again - in my experience). And finally, ZPT is much better architected for the future than DTML is. It's a good party, why not join? I keep wanting to say a line about people not moving towards the future and staying with the familiar comfortable nature of the first editor to barely move beyond the one line nature of the teletypewriter, but I'm not going to. ;) -- Jeffrey P Shell www.cuemedia.com http://radio.weblogs.com/0106123/
Adrian Hungate wrote:
Vi/Emacs war anyone? :)
Seriously though, what, exactly, was so broken about DTML that fixing it became so vital?
I remember the discussion, "back in the day", that lead to ZPT. People were adamant that DTML was the biggest thing holding back Zope. Pretty funny, eh? Lesson learned: when the vast majority of an open source project unanimously agree on a change, afterwards another vast majority will pop up in opposition. :^)
Given the strengths of DTML I still maintain that ZPT is no (yet?) a complete replacement, and given the comfortable, familiar syntax, I doubt that it should ever replace DTML completely, even if most pages are ZPT. I would be very supprised (Not to mention impressed) if by 2.6 ZPT can comfortably replace every aspect of DTML without having to employ Python scripts, or some arcane incantations.
It's ok if DTML doesn't replace ZPT. Earlier in this thread you extolled the virtues of an imperative language for templating. I can safely say, ZPT is not for you. :^) In fact, I can easily close this argument: if you don't like ZPT, then you probably aren't in its intended audience. Gotta love self-fulfilling logic like that! --Paul
Paul Everitt wrote:
Lesson learned: when the vast majority of an open source project unanimously agree on a change, afterwards another vast majority will pop up in opposition. :^)
I would hardly call one person a 'vast majority' ;-) cheers, Chris
Hey, watch who you are calling One Person... :) Adrian... ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: "Paul Everitt" <paul@zope.com> Cc: "Adrian Hungate" <adrian@haqa.co.uk>; <zope-dev@zope.org> Sent: Thursday, May 09, 2002 8:46 AM Subject: Re: [Zope-dev] ZPT is young
Paul Everitt wrote:
Lesson learned: when the vast majority of an open source project unanimously agree on a change, afterwards another vast majority will pop up in opposition. :^)
I would hardly call one person a 'vast majority' ;-)
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Adrian Hungate wrote:
Also, have you tried explaining ZPT to ASP programmers? Trying to turn an ASP designer from the Dark Side is not being made any easier by either the uncertainty about the programming platform, or by moving from a simple, HTML based language, to an attribute based language that allows you to use and abuse HTML tags in potentially confusing ways...
From what I hear, the next generation of ASP is going to be attribute-based in the same way ZPT is...
cheers, Chris
Adrian Hungate wrote:
Maybe a little Perl psychology might help us here, i.e. "There is more than one way to do it" -
And you know what I see as one of Perl's worst features? ;-)
ZClasses are one of the two things that bring Zope up to and above the level of the competition (In this case Coldfusion)
I would strongly disagree. The biggest problem people get into is when they run out of steam with ZClasses and have nowhere to go without rewriting all their code. Not to mention the fact that theyr'e buggy, non-intuitive and not supported anymore.
IMHO - TTW coding, including writing products TTW, and DTML which is far more powerful and focused than the competitions offering.
I think that blindly disposing of both, just because a newer idea has come along is just that - blind. So what if ZPT is more (choose your comparison here) than DTML? DTML is far easier to learn, far easier to read, far easier to write, and much much easier to explain to newbies.
DTML is not faster to learn. It is certainly not easier to read. It is much more difficult to write if you want behaviour to be deterministic and is much harder to explain what has happened when things go wrong, especially to newbies.
products, but even that does not earn ZClasses a death warant (IMHO) - Have you never needed a quick fix product that needs writing in a few minutes and in a week will no longer be needed? I know I have - Many MANY times!
Yeah, and I find Python Products a helluva lot quicker to write than ZClasses... For other stuff, I use lightweight types a la CMF's Types Tool. cheers, Chris - why make other people suffer?
participants (12)
-
Adrian Hungate -
Andy McKay -
Casey Duncan -
Chris Withers -
Dieter Maurer -
Jeffrey P Shell -
Jim Penny -
Martijn Jacobs -
Paul Everitt -
R. David Murray -
Shane Hathaway -
Thomas Olsen