Hi! After using Zope more than one year I want to share my experiences with you That's what I think: 0. Learn python 1. Don't programm Zope TTW (Through the web) This applies if you have a small group of developers. If you have many developers who know HTML editing TTW might be for, but then this text does not apply This means: Use Python Products 2. Don't use ZPT, DTML or ZClasses. I spent to much time searching for the line were the error occured. Since I use python I no more have theses problems. Example: def foo(self, REQUEST): "docstring" .... ret=[] ret.append(self.root.standard_html_header()) ret.append(""" <your tag> %s <foo>%s</foo> </your_tag> .... """ % (var1, var2)) return string.join(ret) 3. Don't use acquisition. The only part where acquisition is usefull is for the standard_html_header See the example above how to do it without it 4. If you are starting a new project use ZODB for the storage and not a relational database. Soon directory storage will be stable and you have the latest storage solution 5. Use BTrees. They are very scalable. But pay attention: The keys must all be of the same type. What do you think about it?
hi, Thomas Guettler wrote:
After using Zope more than one year I want to share my experiences with you
That's what I think:
2. Don't use ZPT, DTML or ZClasses. I spent to much time searching for the line were the error occured. Since I use python I no more have theses problems.
Don't use ZClasses!!! That's true... but why not ZPT & DTML? Mixing my html-layout into python-code is moving two steps back. welcome to the php-mixing-code&design-scripting-chaos. cheers, -mj
Maik Jablonski wrote:
hi,
Thomas Guettler wrote:
After using Zope more than one year I want to share my experiences with you
That's what I think:
2. Don't use ZPT, DTML or ZClasses. I spent to much time searching for the line were the error occured. Since I use python I no more have theses problems.
Don't use ZClasses!!! That's true... but why not ZPT & DTML?
DTML is ugly ZPT gives you only sometimes the line number where your typo was. Why learn an other syntax? The following can be understood by all pyhton programmers: """ <html> <head> <title>%s</title> </head> <body> <h1>%s</h1> </body> </html> """ % (mytitle, myheading)
Mixing my html-layout into python-code is moving two steps back
Back to the roots thomas
On Thu, Aug 08, 2002 at 01:49:58PM +0200, Thomas Guettler wrote:
Maik Jablonski wrote:
hi,
Thomas Guettler wrote:
After using Zope more than one year I want to share my experiences with you
That's what I think:
2. Don't use ZPT, DTML or ZClasses. I spent to much time searching for the line were the error occured. Since I use python I no more have theses problems.
Don't use ZClasses!!! That's true... but why not ZPT & DTML?
DTML is ugly
ZPT gives you only sometimes the line number where your typo was.
Why learn an other syntax?
The following can be understood by all pyhton programmers:
I thought one of the reasons to use something like ZPT was that you can seperate design from functionality. HTML programmers usually do not know Python (and vice versa). This is IMHO one of the strong points of Zope... -- __________________________________________________ "Nothing is as subjective as reality" Reinoud van Leeuwen reinoud.v@n.leeuwen.net http://www.xs4all.nl/~reinoud __________________________________________________
it sounds like you might as well have just stuck with Perl CGI ;) Thomas Guettler wrote:
Maik Jablonski wrote:
hi,
Thomas Guettler wrote:
After using Zope more than one year I want to share my experiences with you
That's what I think:
2. Don't use ZPT, DTML or ZClasses. I spent to much time searching for the line were the error occured. Since I use python I no more have theses problems.
Don't use ZClasses!!! That's true... but why not ZPT & DTML?
DTML is ugly
ZPT gives you only sometimes the line number where your typo was.
Why learn an other syntax?
The following can be understood by all pyhton programmers:
""" <html> <head> <title>%s</title> </head> <body> <h1>%s</h1> </body> </html> """ % (mytitle, myheading)
Mixing my html-layout into python-code is moving two steps back
Back to the roots
thomas
_______________________________________________ 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 )
DTML is ugly
Only if you use it as a programming language. Its quite simple and elegant for templating.
ZPT gives you only sometimes the line number where your typo was.
So the issue is more the debugging than anything. I'm starting to like ZPT, its quite nifty, but still mostly use DTML.
<h1>%s</h1> </body> </html> """ % (mytitle, myheading)
Sure if your python programmers do the html. What happens when you start to nest list of items in tables. Every mixing html / python or perl project ive seen has ended up a total unmaintable inflexible mess after a few months and few different developers. -- Andy McKay agmweb consulting http://www.agmweb.ca
ok. I have to pitch into this too. I've worked on, and/or built mixed use setups. i.e. HTML rendered by the script, or the script embedded in HTML (JSP and PHP) And they're 100% unmaintainable especially if you aren't the originating developer. It's almost impossible to visualize a complex html page from a series of out += "HTML stuff" when the script doesn't run, and it's quite easy to break something. I've seen one jsp file return no less than 5 distinct html renderings, and it becomes quite a bear to make a change. Add on top of that other jsp pages that are copied off the original with minor modifications. Try changing the HTML in both of those now. For that matter make 20 copies. Then the idea of one html file being used by those scripts becomes a very good one. ZPT does just that for us, and that's one of the reasons we chose Zope as a platform. ----- Original Message ----- From: "Andy McKay" <andy@agmweb.ca> To: "Thomas Guettler" <zopestoller@thomas-guettler.de>; <zope@zope.org> Sent: Thursday, August 08, 2002 3:51 PM Subject: Re: [Zope] Why not ZPT
DTML is ugly
Only if you use it as a programming language. Its quite simple and elegant for templating.
ZPT gives you only sometimes the line number where your typo was.
So the issue is more the debugging than anything. I'm starting to like ZPT, its quite nifty, but still mostly use DTML.
<h1>%s</h1> </body> </html> """ % (mytitle, myheading)
Sure if your python programmers do the html. What happens when you start to nest list of items in tables. Every mixing html / python or perl project ive seen has ended up a total unmaintable inflexible mess after a few months and few different developers. -- Andy McKay agmweb consulting http://www.agmweb.ca
_______________________________________________ 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 )
I must wholly agree. I have developed in JSP/servlets and in our companies special web/application server product for AS/400 servers. It is too easy to put the logic and presentation is all over the place on JSP/servlets and on our companies product. Our sales reps are real good and it helps if the user are ignorant of good products like Zope, so the managed to sell a lot of test web/application servers. But unfortunately I have to maintain the application built with this product. I am kind of embarassed that I have made that mess. But the power of ZPT comes when you put ZPT's inside ZPT's. You have a main ZPT which has a header ZPT and a footer ZPT and a body ZPT and a left side bar ZPT. ----- Original Message ----- From: "Jim Kutter" <jim@ebizq.net> To: "Andy McKay" <andy@agmweb.ca>; "Thomas Guettler" <zopestoller@thomas-guettler.de>; <zope@zope.org> Sent: Thursday, August 08, 2002 4:25 PM Subject: Re: [Zope] Why not ZPT ok. I have to pitch into this too. I've worked on, and/or built mixed use setups. i.e. HTML rendered by the script, or the script embedded in HTML (JSP and PHP) And they're 100% unmaintainable especially if you aren't the originating developer. It's almost impossible to visualize a complex html page from a series of out += "HTML stuff" when the script doesn't run, and it's quite easy to break something. I've seen one jsp file return no less than 5 distinct html renderings, and it becomes quite a bear to make a change. Add on top of that other jsp pages that are copied off the original with minor modifications. Try changing the HTML in both of those now. For that matter make 20 copies. Then the idea of one html file being used by those scripts becomes a very good one. ZPT does just that for us, and that's one of the reasons we chose Zope as a platform. ----- Original Message ----- From: "Andy McKay" <andy@agmweb.ca> To: "Thomas Guettler" <zopestoller@thomas-guettler.de>; <zope@zope.org> Sent: Thursday, August 08, 2002 3:51 PM Subject: Re: [Zope] Why not ZPT
DTML is ugly
Only if you use it as a programming language. Its quite simple and elegant for templating.
ZPT gives you only sometimes the line number where your typo was.
So the issue is more the debugging than anything. I'm starting to like ZPT, its quite nifty, but still mostly use DTML.
<h1>%s</h1> </body> </html> """ % (mytitle, myheading)
Sure if your python programmers do the html. What happens when you start to nest list of items in tables. Every mixing html / python or perl project ive seen has ended up a total unmaintable inflexible mess after a few months and few different developers. -- Andy McKay agmweb consulting http://www.agmweb.ca
_______________________________________________ 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 )
_______________________________________________ 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 )
"Edward Ing" <edwardbying@hotmail.com> writes:
But the power of ZPT comes when you put ZPT's inside ZPT's. You have a main ZPT which has a header ZPT and a footer ZPT and a body ZPT and a left side bar ZPT.
Hi Edward, this sounds like something I want to do - anything more you can say about it ? Do you need to strip the HTML header & footer from the ZPTs you're including.. or not ? -Simon
We do the same. We have zpt "fragments" or snippets as I call them, and do stuff like < div tal:replace="here/snippet" >< / div > The snippet usually contains a whole < table > element or something and nothing more. It allows me to edit/replace/replicate (like a news snippet) sections of pages without mucking with the whole page. -jim ----- Original Message ----- From: "Simon Michael" <simon@joyful.com> To: <zope@zope.org> Sent: Friday, August 09, 2002 12:29 PM Subject: [Zope] Re: Why not ZPT
"Edward Ing" <edwardbying@hotmail.com> writes:
But the power of ZPT comes when you put ZPT's inside ZPT's. You have a main ZPT which has a header ZPT and a footer ZPT and a body ZPT and a left side bar ZPT.
Hi Edward,
this sounds like something I want to do - anything more you can say about it ? Do you need to strip the HTML header & footer from the ZPTs you're including.. or not ?
-Simon
_______________________________________________ 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 )
you don't "include ZPTs" you use macros defined elsewhere. say, you have a ZPT page somewhere with the name "custom_zpt". inside of custom_zpt you define macros:: <metal:block define-macro="my_greeting"> <p><b>Hello World</b></p> </metal:block> then you can use that in other templates like so:: <metal:block use-macro="here/custom_zpt/macros/my_greeting" /> that's how you reuse stuff with templates. you can also put TAL-statements into the macro when you define it, the TAL code will then be executed in the context of the page that uses the macro. jens On Friday, August 9, 2002, at 12:29 , Simon Michael wrote:
"Edward Ing" <edwardbying@hotmail.com> writes:
But the power of ZPT comes when you put ZPT's inside ZPT's. You have a main ZPT which has a header ZPT and a footer ZPT and a body ZPT and a left side bar ZPT.
Hi Edward,
this sounds like something I want to do - anything more you can say about it ? Do you need to strip the HTML header & footer from the ZPTs you're including.. or not ?
-Simon
_______________________________________________ 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 )
Hi Simon, Simon Michael wrote:
"Edward Ing" <edwardbying@hotmail.com> writes:
But the power of ZPT comes when you put ZPT's inside ZPT's. You have a main ZPT which has a header ZPT and a footer ZPT and a body ZPT and a left side bar ZPT.
this sounds like something I want to do - anything more you can say about it ? Do you need to strip the HTML header & footer from the ZPTs you're including.. or not ?
Go read up on the METAL part of ZPT, it does what you want and in a pretty cool way too :-) cheers, Chris
Thank you for your answers I try to explain my point of view a bit more. The first post was by intend written provokingly. Please note that my point of view is of someone how develops an application where logic is more important than layout. Why not ZPT: Yes, mixing python and HTML can get a mess. But if the first coders did a nice and simple framework every programmer who has understood objectoriented programming will understand what the code does. Unfortunately there are a lot who don't know what inheritance is If designers only know HTML they don't know ZPT, too. I think it makes much more sence to learn python than ZPT. Python is programming language, there are a lot of examples on the net (Cookboo) and a friendly newsgroup. BTW, you can seperate logic and layout without ZPT, DTML, too. You just need to stick to some rule. Methods which create forms are called fooForm and the corresponding page which takes the form variables are called fooAction What remaines if you take away Acquisition, ZPT, DTML, ZClasses? An objectoriented applicationserver, a HTTP/WebDAV/FTP frontend to ZODB Acquisition: Acquisition seems to be inheritance for people who don't do OOP. I think it is usefull if you are developing zope TTW. In a python product you can use real inheritance I tried to inherit from Acquisition.Explicit but this resulted in strange behaviour of some zope methods. thomas -- Thomas Guettler <guettli@thomas-guettler.de> http://www.thomas-guettler.de
If designers only know HTML they don't know ZPT, too. I think it makes much more sence to learn python than ZPT. Python is programming language, there are a lot of examples on the net (Cookboo) and a friendly newsgroup.
But they don't need to know ZPT at all. Ever. They design the site. The programmer put's the tal in after the fact to make it dynamic. The designer never has to view source. They can be content drawing in GoLive. This makes designers happy.
On Friday 09 August 2002 16:28, Steve Drees wrote:
But they don't need to know ZPT at all. Ever. They design the site. The programmer put's the tal in after the fact to make it dynamic.
I think Thomas know this. ;-) But he probably never had designed a compilcated portal with VERY compilcated HTML with lots of graphics. -- Sincerely yours, Bogdan M. Maryniuck And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies." (By Linus Torvalds, Linus.Torvalds@cs.helsinki.fi)
On Friday 09 August 2002 07:39, Thomas Guettler wrote:
Why not ZPT:
[skip]
If designers only know HTML they don't know ZPT, too. But ZPT is a bit easier to learn for *designers* than Python, "AFAIK". :D Well, I don't think, that "designer" (who makes beauty and graphics) equals "programmer" who probably know just a little who Johan Sebastian Bach was...
I think it makes much more sence to learn python than ZPT. Python is programming language, there are a lot of examples on the net (Cookboo) and a friendly newsgroup. IOW, let us to enforce artists learn the Python and let they make more crapware and headicks for us...
What remaines if you take away Acquisition, ZPT, DTML, ZClasses? An objectoriented applicationserver, a HTTP/WebDAV/FTP frontend to ZODB Buuueee... Why Zope? Because it *wide* framework. So if you hate simplicity and RAD and collaboration between different sectors of developers, then you should use CherryPy or something.
Acquisition: [skip] I tried to inherit from Acquisition.Explicit but this resulted in strange behaviour of some zope methods. Yes, Acquisition is quite tricky and Zope 3 will be totally different. To use Explicit you should exactly specify the method / attributes you want to aquire, but you probably know well this already. ;-)
-- Sincerely yours, Bogdan M. Maryniuck Linux! Guerrilla UNIX Development Venimus, Vidimus, Dolavimus. (By mah@ka4ybr.com, Mark A. Horton KA4YBR)
The following can be understood by all pyhton programmers:
""" <html> <head> <title>%s</title> </head> <body> <h1>%s</h1> </body> </html> """ % (mytitle, myheading)
It's never this easy unless it's the simplest of applications :) Speaking of which... Consider using jaxml and the HTML_document class there. Search google for "jaxml". Basically It works like this:
import jaxml h=jaxml.HTML_document() h.html() h.head() h.title() h._text("Hello world") h._pop() h.meta(type="something", refresh="1") print h <?xml version="1.0" encoding="iso-8859-1"?> <html> <head> <title> <text>Hello world</text> Hellow world </title> </head> <meta refresh="1" type="something" /> </html>
I use this module to generate XML and it works great! For HTML I'm not too sure but it appears to be working just fine. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.380 / Virus Database: 213 - Release Date: 2002-07-24
On Fri, Aug 09, 2002 at 10:05:28AM +0100, Peter Bengtsson wrote:
Speaking of which... Consider using jaxml and the HTML_document class there. Search google for "jaxml". Basically It works like this:
...
I use this module to generate XML and it works great! For HTML I'm not too sure but it appears to be working just fine.
Glad to see someone who is happy with this module ;-) You can find it at : http://www.librelogiciel.com/software/ It basically defines an XML_document class, the HTML_document ad CGI_document ones are just the same with some specific methods. Just read the included samples to see how it works, or just ask me if you want. bye, Jerome Alet
Jaxml looks like a pretty neat idea and I like it, but it solves very different use cases from ZPT. That said, if your use cases are more inline with Jaxml then use it. I would hesitate to call it a templating language though as the xml only exists at run time. It is really a very clever leveraging of Python syntax to generate xml. So it is aimed squarely at Python programmers as opposed to ZPT which aims at web developers who may not be "programmers". What I like best about it (Jaxml) is being completely isolated from any icky SGML syntax ;^), which as you can tell I am not terribly fond of... A more general question about it: can it generate DTDs? -Casey On Friday 09 August 2002 07:53 am, Jerome Alet wrote:
On Fri, Aug 09, 2002 at 10:05:28AM +0100, Peter Bengtsson wrote:
Speaking of which... Consider using jaxml and the HTML_document class there. Search google for "jaxml". Basically It works like this:
...
I use this module to generate XML and it works great! For HTML I'm not too sure but it appears to be working just fine.
Glad to see someone who is happy with this module ;-)
You can find it at :
http://www.librelogiciel.com/software/
It basically defines an XML_document class, the HTML_document ad CGI_document ones are just the same with some specific methods.
Just read the included samples to see how it works, or just ask me if you want.
bye,
Jerome Alet
_______________________________________________ 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, Aug 09, 2002 at 09:27:55AM -0400, Casey Duncan wrote:
That said, if your use cases are more inline with Jaxml then use it. I would hesitate to call it a templating language though as the xml only exists at run time. It is really a very clever leveraging of Python syntax to generate xml. So it is aimed squarely at Python programmers as opposed to ZPT which aims at web developers who may not be "programmers".
What I like best about it (Jaxml) is being completely isolated from any icky SGML syntax ;^), which as you can tell I am not terribly fond of...
JAXML also offers two different templating mechanisms if you prefer to use this functionnalities : one with external templates, the other with late binding of anything, even plain-text portions of the current document. These two mechanisms aren't completely tested, any bug report is welcome.
A more general question about it: can it generate DTDs?
Not automatically, unfortunately, but you can always use the _text() method to put plain text into the document. bye Jerome Alet
On Thursday 08 August 2002 13:49, Thomas Guettler wrote:
DTML is ugly If you use DTML for complicated logic, it's even lame, because DTML is quite slow. But if you do design layout in Python it is lame too...
ZPT gives you only sometimes the line number where your typo was. ZPT is for publishing.
Back to the roots Therefore you should use Perl or PHP. ;-)
-- Sincerely yours, Bogdan M. Maryniuck "I would rather spend 10 hours reading someone else's source code than 10 minutes listening to Musak waiting for technical support which isn't." (By Dr. Greg Wettstein, Roger Maris Cancer Center)
After using Zope more than one year I want to share my experiences with you
That's what I think:
2. Don't use ZPT, DTML or ZClasses. I spent to much time searching for the line were the error occured. Since I use python I no more have theses problems.
Don't use ZClasses!!! That's true... but why not ZPT & DTML? Mixing my html-layout into python-code is moving two steps back. welcome to the php-mixing-code&design-scripting-chaos.
As Shreck said, it is layers. You might not like mixing Html with code, but your designer doesn't know python. Depending on your project, the same might go for some of your programmers. Sure, it is nice to have a perfect object hierarcht, but it is not always easy to make little adjustment for the unenlighted sidekick. My perfect setup is having a python product class hierarchy that is zclass derivable, with the abstract application. A layer of zclasses sits on top of that, mainly to offer hooks for specific implementations. On top of that all forms and views are done in ZPT or DTML, calling the python classes where necesary. Douwe
On Thu, Aug 08, 2002 at 01:17:09PM +0200, Thomas Guettler wrote:
4. If you are starting a new project use ZODB for the storage and not a relational database. Soon directory storage will be stable and you have the latest storage solution
That depends on what you are doing. If your application heavily depends on SQL queries that join big tables, I would prefer a relational database. At that moment the question would be: do you want to store everything in one place, or just the relational data in a RDBMS and the rest in ZODB? -- __________________________________________________ "Nothing is as subjective as reality" Reinoud van Leeuwen reinoud.v@n.leeuwen.net http://www.xs4all.nl/~reinoud __________________________________________________
Example: def foo(self, REQUEST): "docstring" .... ret=[] ret.append(self.root.standard_html_header()) ret.append(""" <your tag> %s <foo>%s</foo> </your_tag> .... """ % (var1, var2)) return string.join(ret)
now that's horrible. hardcoding HTML into python is a maintenance nightmare. i suppose it's OK if you are the one who will be maintaining that code until it dies from bit-rot, but i would pity anyone else who did not write it and who has to maintain it somehow ;) one of the goals of zope (and especially ZPT now) is to keep presentation and logic apart. IMHO that's a great goal. one of the patterns that has evolved on "the other side of the fence" (meaning at zope corp), so to speak, is a "three-tier" way of coding: - python products handle all logic. they do not know about web stuff like REQUEST - python scripts are used to glue the web-unaware python product to the web - ZPT does the presentation. all the templates should ever talk to is those glue python scripts there are quite a few advantages to this: - design can be done independent from logic development. adding more logic or changing logic has no influence on the design anymore - web-unaware python products are easier to test using unit tests because you don't have to fake out certain things (such as web requests) in your test environment anymore. the code is cleaner, smaller and more efficient. and, IMHO, more understandable. etc... jens
Jens Vagelpohl wrote:
now that's horrible.
no it isn't!
hardcoding HTML into python is a maintenance nightmare. i suppose it's OK if you are the one who will be maintaining that code until it dies from bit-rot, but i would pity anyone else who did not write it and who has to maintain it somehow
The problem with using template languages is that it scales like s***! Look at the problem with the CMF. If you want to add a component it has to make it's own skin. And if you want the component to get a new look and feel you will have to change the skin. The CMF is a gret big monolith that can get a new look and feel by rewriting the skins. But the amount of work associated with that scales like: n-skins * n-components. That is squared problem. Now you can talk about maintanance problem. The look and feel should generally be seperate from the components. Which they are not right now! You should be able to write a component following some interface specifications, and then you should be able to select a new skin from from a drop-down or pass a ?skin=someSkin in the url, and every component should be able to change their look without any further coding. As it is now with ZPT/dtml Zope will not be able to scale to an architecture where you just create plug'n play components that fits into a framework. And until then we will not see any major reuse of code. regards Max M -- "Sorry I would Really Like To Help More On This Project, But Am To Busy Doing Paid Work On A Tight Deadline" Max M
Look at the problem with the CMF. If you want to add a component it has to make it's own skin. And if you want the component to get a new look and feel you will have to change the skin.
you just have to provide views and python scripts for processing...
The CMF is a gret big monolith that can get a new look and feel by rewriting the skins. But the amount of work associated with that scales like: n-skins * n-components. That is squared problem. Now you can talk about maintanance problem.
huh? i change main_template.pt and that changes my look and feel...
The look and feel should generally be seperate from the components. Which they are not right now!
again, main_template.pt is separate from all those components. you just have to use it from whatever views you need for the new component (like its edit screens, view screens etc)
You should be able to write a component following some interface specifications, and then you should be able to select a new skin from from a drop-down or pass a ?skin=someSkin in the url, and every component should be able to change their look without any further coding.
As it is now with ZPT/dtml Zope will not be able to scale to an architecture where you just create plug'n play components that fits into a framework. And until then we will not see any major reuse of code.
we reuse a lot of CMF skins/code in our development work... you are correct if your point is that it's still too hard to write new content types for the CMF (meaning content types that require more than just a copied-and-changed Type object in the types tool and some views). but i don't think it's as bad as you make it out to be. jens
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
0. Learn python Very good idea anyway...
2. Don't use ZPT, DTML or ZClasses. I spent to much time searching Isn't this what Zope is all about? What would be left if you took them away? 3. Don't use acquisition. The only part where acquisition is usefull is for the standard_html_header I think aquisition is one of the great features of Zope. A small, ridiculuous example is this: if you declare a webmaster name/email address as a dtml-var (like the standard_header), and it's on every page of a 1000 page site, and you want to change it, you can do it in one spot, and it changes everywhere!
Why bother with Zope if you take away all the stuff that makes it unique? Obviously there are warts to Zope, but nothing is perfect. Russell - -- Linux -- the OS for the Renaissance Man -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9Um5QAqKGrvVshJQRAkn+AKDULyUgEQk2h63au0Yd2Gr4iGGi9QCbBH8b 1Gv5VcgNoJu3UbBsuN8q44w= =S0yz -----END PGP SIGNATURE-----
Russell Hires wrote:
I think aquisition is one of the great features of Zope. A small, ridiculuous example is this: if you declare a webmaster name/email address as a dtml-var (like the standard_header), and it's on every page of a 1000 page site, and you want to change it, you can do it in one spot, and it changes everywhere!
Bad example! import Borg globals = Borg.SiteBorg() globals.adminName
Max M
That could just as easily be done with the above code. The aquisition is a harsh mistress and can burn you badly!
Why bother with Zope if you take away all the stuff that makes it unique? Obviously there are warts to Zope, but nothing is perfect.
Zope has get a few thing very right and a lot of things a little wrong :-/ Zope 3 will hopefully correct most of the problems. regards Max M -- "Sorry I would Really Like To Help More On This Project, But Am To Busy Doing Paid Work On A Tight Deadline" Max M
What do you think about it?
I'm a relative newcomer to Zope myself, so I don't have much hard-won experience to base any comments upon. I would like to say that what Zope seems to be missing is the interactive nature of Python. When learning ZPT recently, I had a devil of a time trying to debug it. I would like to know the equivalent of the Python "fire up the interactive interpreter prompt and start playing around" drill for Zope. Also, what about testing? How do you layer and modularize things properly so that you can follow the test driven coding approach of XP with Zope? All I have is a bunch of questions. Cheers, // mark -
What do you think about it?
I'm a relative newcomer to Zope myself, so I don't have much hard-won experience to base any comments upon. I would like to say that what Zope seems to be missing is the interactive nature of Python. When learning ZPT recently, I had a devil of a time trying to debug it. I would like to know the equivalent of the Python "fire up the interactive interpreter prompt and start playing around" drill for Zope.
cd yourzope/lib/python python
import Zope app = Zope.app() app.objectIds() ['standard_html_header', 'Examples', ...]
Also, what about testing? How do you layer and modularize things properly so that you can follow the test driven coding approach of XP with Zope?
See any "tests" package inside of most directories in Zope. Also read UNITTEST.txt in the doc directory.
Hey, too much programming makes you want to index with zero in the wrong places. ----- Original Message ----- From: "Thomas Guettler" <zopestoller@thomas-guettler.de> To: <zope@zope.org> Sent: Thursday, August 08, 2002 7:17 AM Subject: [Zope] My Way of Zope Programming
Hi!
After using Zope more than one year I want to share my experiences with you
That's what I think:
0. Learn python
1. Don't programm Zope TTW (Through the web) This applies if you have a small group of developers. If you have many developers who know HTML editing TTW might be for, but then this text does not apply This means: Use Python Products
I came up to the idea that for people wanting to use Zope for high trafficked sites, and thus are looking for every bit of performance out of their web applications, ZPT would probably may not be a choice at all. I've recently tested Plone (the CMF skin built entirely of ZPTs) on a Pentium IV @ 1.7GHZ plenty of memory, and generally speaking I had this sensation that in despite of that horsepower, every page took a little bit of time to render while some pages took from half a second to two seconds. (DTML based pages, no matter how complicated they were, rendered almost immediately ). Now, take that and multiply it for 20 or more simultaneus hit responses and you'll find out that you'll need more horsepower than the average in order to provide a pleasant session for all the users. By the way it's not Plone's fault. I see ZPT more like a marketing strategy and hence the closing of the gap between designers and programmers looks like a huge selling point ( provided other less elegant scripting languages like PHP do have more attention than Zope/DTML/ZPT/Python from web design suites like Dreamweaver.) Of course in the future, when computing power wouldn't be a concern, this effective separation of code and html will be a key feature. Just my two cents. Ausum ----- Original Message ----- From: "Thomas Guettler" <zopestoller@thomas-guettler.de> To: <zope@zope.org> Sent: Thursday, August 08, 2002 6:17 AM Subject: [Zope] My Way of Zope Programming
Hi!
After using Zope more than one year I want to share my experiences with you
That's what I think:
0. Learn python
1. Don't programm Zope TTW (Through the web) This applies if you have a small group of developers. If you have many developers who know HTML editing TTW might be for, but then this text does not apply This means: Use Python Products
2. Don't use ZPT, DTML or ZClasses. I spent to much time searching for the line were the error occured. Since I use python I no more have theses problems. Example: def foo(self, REQUEST): "docstring" .... ret=[] ret.append(self.root.standard_html_header()) ret.append(""" <your tag> %s <foo>%s</foo> </your_tag> .... """ % (var1, var2)) return string.join(ret)
3. Don't use acquisition. The only part where acquisition is usefull is for the standard_html_header See the example above how to do it without it
4. If you are starting a new project use ZODB for the storage and not a relational database. Soon directory storage will be stable and you have the latest storage solution
5. Use BTrees. They are very scalable. But pay attention: The keys must all be of the same type.
What do you think about it?
_______________________________________________ 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 )
I came up to the idea that for people wanting to use Zope for high trafficked sites, and thus are looking for every bit of performance out of their web applications, ZPT would probably may not be a choice at all.
I've recently tested Plone (the CMF skin built entirely of ZPTs) on a Pentium IV @ 1.7GHZ plenty of memory, and generally speaking I had this sensation that in despite of that horsepower, every page took a little bit of time to render while some pages took from half a second to two seconds. (DTML based pages, no matter how complicated they were, rendered almost immediately ). Now, take that and multiply it for 20 or more simultaneus hit responses and you'll find out that you'll need more horsepower than the average in order to provide a pleasant session for all the users.
you'll find that you need *caching*. no large-scale application server can provide hundreds of hits a second without a good cache in front of it and without making sure that the rendered content carries the right caching headers. jens
You're right about caching, Jens. Nonetheless I talked about the performance, considering every page responding to a unique and personalized request. If there are workarounds to cache that, I'll be happy to know about them. :) Ausum
I came up to the idea that for people wanting to use Zope for high trafficked sites, and thus are looking for every bit of performance out of their web applications, ZPT would probably may not be a choice at all.
I've recently tested Plone (the CMF skin built entirely of ZPTs) on a Pentium IV @ 1.7GHZ plenty of memory, and generally speaking I had this sensation that in despite of that horsepower, every page took a little bit of time to render while some pages took from half a second to two seconds. (DTML based pages, no matter how complicated they were, rendered almost immediately ). Now, take that and multiply it for 20 or more simultaneus hit responses and you'll find out that you'll need more horsepower than the average in order to provide a pleasant session for all the users.
you'll find that you need *caching*. no large-scale application server can provide hundreds of hits a second without a good cache in front of it and without making sure that the rendered content carries the right caching headers.
jens
_______________________________________________ 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 )
I wonder if we can put the blame for that on the javascript that Plone uses. I know that on my system i can see the browser taking its sweet old time to process those 2 javascripts that seem to be on every page of Plone. and of course this has nothing to do with Zope. regards, george donnelly http://zettai.net/ zettai: zope hosting and dynamic websites
From: "Ausum Studio" <ausum_studio@hotmail.com>
I've recently tested Plone (the CMF skin built entirely of ZPTs) on a Pentium IV @ 1.7GHZ plenty of memory, and generally speaking I had this sensation that in despite of that horsepower, every page took a little bit of time to render while some pages took from half a second to two seconds. (DTML based pages, no matter how complicated they were, rendered almost immediately ). Now, take that and multiply it for 20 or more simultaneus hit responses and you'll find out that you'll need more horsepower than the average in order to provide a pleasant session for all the users.
Well, one of the problems with Plone is that the page sizes are approx 40 kb which is way to much for an ISDN line. We have solved this with a little c-program that makes the pages ready for production. \Oliver
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of george donnelly Sent: 9. august 2002 15:05 To: Ausum Studio; zope@zope.org Subject: Re: [Zope] My Way of Zope Programming
I wonder if we can put the blame for that on the javascript that Plone uses. I know that on my system i can see the browser taking its sweet old time to process those 2 javascripts that seem to be on every page of Plone. and of course this has nothing to do with Zope.
regards, george donnelly http://zettai.net/ zettai: zope hosting and dynamic websites
From: "Ausum Studio" <ausum_studio@hotmail.com>
I've recently tested Plone (the CMF skin built entirely of ZPTs) on a Pentium IV @ 1.7GHZ plenty of memory, and generally speaking I had this sensation that in despite of that horsepower, every page took a little bit of time to render while some pages took from half a second to two seconds. (DTML based pages, no matter how complicated they were, rendered almost immediately ). Now, take that and multiply it for 20 or more simultaneus hit responses and you'll find out that you'll need more horsepower than the average in order to provide a pleasant session for all the users.
_______________________________________________ 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 ) --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 02-08-2002
Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 02-08-2002
On Thu, Aug 08, 2002 at 11:52:06PM -0500, Ausum Studio wrote:
I came up to the idea that for people wanting to use Zope for high trafficked sites, and thus are looking for every bit of performance out of their web applications, ZPT would probably may not be a choice at all.
I've recently tested Plone (the CMF skin built entirely of ZPTs) on a Pentium IV @ 1.7GHZ plenty of memory, and generally speaking I had this sensation that in despite of that horsepower, every page took a little bit of time to render while some pages took from half a second to two seconds. (DTML based pages, no matter how complicated they were, rendered almost immediately ). Now, take that and multiply it for 20 or more simultaneus hit responses and you'll find out that you'll need more horsepower than the average in order to provide a pleasant session for all the users.
On the contrary, I suspect that it is Plone's fault. The javascript suggestion may be reasonable. I am doing heavy database backed work (technical drawings, request for samples, drawings, items, catalog photos, etc.) I find that a simple form involving about three database queries is taking between .2 and .5 seconds to render. This really makes me think that ZPT is not the hangup. Moreover, my older sections, which are DTML, seem to take roughly the same time. My personal guess, without doing heavy instrumentation, is that ZPT is a bit slower than DTML, but that the separation of logic into snake thingies roughly offsets that. I am not using METAL much, so I have no idea of what that does to speed. (Server is a K6-450, linux 2.2.13, database is postgresql, DA PoPy)
By the way it's not Plone's fault. I see ZPT more like a marketing strategy and hence the closing of the gap between designers and programmers looks like a huge selling point ( provided other less elegant scripting languages like PHP do have more attention than Zope/DTML/ZPT/Python from web design suites like Dreamweaver.) Of course in the future, when computing power wouldn't be a concern, this effective separation of code and html will be a key feature.
This is the sales pitch. I wish Zope Corp would get over it! The real benefit of ZPT, even for "non designer" sites, is that path expressions make it much easier to use the same form for entry and error handling, in a fairly readable manner. That is, DTML design encouraged a model of present initial form; error check; (present error form or handle). ZPT encourages a view of present initial form; error check; (re-present form or handle). This make it easier to evolve the site, since you don't have to maintain two different forms in lock-step. Yes, I am aware that the same could have been done in DTML. But placing datasource logic in DTML tended to quickly devolve into a unreadable morass, so that it was easier to maintain two separate methods. Jim Penny
Just my two cents.
Ausum
participants (25)
-
alet＠unice.fr -
Andy McKay -
Ausum Studio -
Ben Avery -
Bo M. Maryniuck -
Casey Duncan -
Chris McDonough -
Chris Withers -
douwe＠oberon.nl -
Edward Ing -
george donnelly -
Jens Vagelpohl -
Jim Kutter -
Jim Penny -
Maik Jablonski -
Mark McEahern -
Max M -
Oliver Marx -
Peter Bengtsson -
Reinoud van Leeuwen -
Russell Hires -
Simon Michael -
Steve Drees -
Thomas Guettler -
Thomas Guettler