Zope 3 and Rails - a pragmatic and agile comparation (put the hype aside)
Hello, I come from a Rails background, been working with Rails for about 1 year and a half, it has been a great experience but my last project required me to use Plone as a base framework for the portal/application. I then started deeply studying Plone 3. Bought and read Martin's excellent book Professional Plone Development from cover to cover. Struggled with Zope concepts but almost always could grasp them by reading the other books from the Zope/Plone bookshelf or online articles/tutorials. It has been 3 months already. The project is almost done and I've learned to like Plone and Zope 2. However, what attracted me the most was Zope 3 and its elegant concepts and OOP patterns and this led me to question some things: * The differences in the approaches taken by Rails and Zope 3 to provide developer productivity, scalability and application maintability. Rails is productive, no doubt regarding this. However, I feel that it restricts me in the OOP side of things, hiding much of the OOP patterns from the developer. The "put there it will just work" philosophy often makes it hard (at least harder than if it were being implemented on Zope 3) to make more advanced, complex and specific things. I do believe in the agile methodology and I always follow it whatever I am working with Java, python, C or Rails. Rails just happens to be an out-of-the-box solution that has attract millions of developers becouse of its magic promises and easy learning-curve. I feel however, that Zope 3 with its Component Architecture is much more elegant and can be as productive as Rails AND provide better application scalability and maintability than Rails if you know what you are doing. I can't speak for Zope 2 though :) What do you think? Would you mind sharing your experiences and ideas regarding this subject? Cheers, Marcelo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcelo de Moraes Serpa wrote:
Hello,
I come from a Rails background, been working with Rails for about 1 year and a half, it has been a great experience but my last project required me to use Plone as a base framework for the portal/application.
I then started deeply studying Plone 3. Bought and read Martin's excellent book Professional Plone Development from cover to cover. Struggled with Zope concepts but almost always could grasp them by reading the other books from the Zope/Plone bookshelf or online articles/tutorials.
It has been 3 months already. The project is almost done and I've learned to like Plone and Zope 2. However, what attracted me the most was Zope 3 and its elegant concepts and OOP patterns and this led me to question some things:
* The differences in the approaches taken by Rails and Zope 3 to provide developer productivity, scalability and application maintability. Rails is productive, no doubt regarding this. However, I feel that it restricts me in the OOP side of things, hiding much of the OOP patterns from the developer. The "put there it will just work" philosophy often makes it hard (at least harder than if it were being implemented on Zope 3) to make more advanced, complex and specific things.
I do believe in the agile methodology and I always follow it whatever I am working with Java, python, C or Rails. Rails just happens to be an out-of-the-box solution that has attract millions of developers becouse of its magic promises and easy learning-curve.
I feel however, that Zope 3 with its Component Architecture is much more elegant and can be as productive as Rails AND provide better application scalability and maintability than Rails if you know what you are doing.
I can't speak for Zope 2 though :)
What do you think? Would you mind sharing your experiences and ideas regarding this subject?
Thanks very much for the insight into Zope's stregths and weaknesses as seen by one coming from the Rails world. I know that lots of folks in Zopeland envy the Rails folks for their success at attracting developers: at one point, Zope was doing for Python what Rails has been doing more reccently for Ruby. The Grok folks (http://grok.zope.org/) have made efforts to make a Zope-based development experience which draws on soem of the Rails memes: "don't repeat yourself", "conventiion over configuration", etc. I find those memes problematic, myself, for some of the same reasons you point out for Rails. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHwaqG+gerLs4ltQ4RAoCqAKCivoVCHYoVNHcIEzM7xpoDKrd3QACgtPtX AcWg/oDEJbqVOrCQjgcKdA0= =GAAr -----END PGP SIGNATURE-----
Marcelo, I share your excitement about zope 3 but let me speak about zope 2 . I am also fairly new to zope and came from a java/python background. I have built Rail's tutorial applications but came back to zope 2. Here is my reasons. 1. Through the web editing. Brilliant. Yes it is problematic but it is a game changer. Can zope compete on java or php or asp's territory? No. But nobody else has TTW development and many are now adding something like it (google gears, facebook api, smalltalk's seaside). I just wish more books would discuss how easy it is to take a 'Script Python' and bring it 'inside' to a python product. 2. object database. Perfect for web services with changing schemas. 3. DTML. I know the old timers were smoking way too much dtml in the days before CSS, but I love DTML! It is fast to develop with, it works well with javascript and css (try dynamic css and javascript ) and it has excellent execution speed. It is the IDEs that should change, not dtml. :) 4. REST supporting architecture. 5. a ZMI which allows zope to be an easy to administer database. Easy enough for distribution to powerusers. 6. A well developed catalog/search. 7. A well developed security framework. And finally, there is one other thing I really like about Zope 2. 8. A fairly well defined future. (zope 3). I think the developers of zope 2 were 5-10 years ahead of the curve. If the zope team can continue to appreciate what made zope special while they incorporate the new ideas I think zope will stay ahead of the curve. A toast to all of the zope (2 and 3) developers! Thank you. Tim
I can't speak for Zope 2 though :)
What do you think? Would you mind sharing your experiences and ideas regarding this subject?
Here is a follow up I wrote that fell off the list. The original poster probably thought he was posting to the zope@zope.org but I leave his id off just in case he didn't. I am reposting it here mainly because he makes several good points. -Tim
I find zope's through the web editing it's worst aspect. It would make a great optional add-on, but to make the root of the site only editable through the web is just a disaster.
I could vote for an optional add-on. BTW I meant to say google gadgets. The point is that there is always far more innovation outside your company than inside and companies are looking for software that helps them tap into that talent.
2. object database. Perfect for web services with changing schemas.
It's great, but I wish it wasn't mapped directly to URLs. There should be an abstraction, like the controller in MVC systems.
I could also vote for this but apache does a lot of this for you.
DTML is horrible because it looks like XML but isn't. It should either be XML, like TAL, which I think is great, or be nothing like it, like django's templating language.
If you are talking about reading dtml I share your pain, but if you are talking about writing it then you have a built in filter. When your page starts to look ugly rethink your problem. For example, these days you can program tabs with secondary menus using just two dtml-in loops if you start with tabs that only require css http://labs.silverorange.com/images/tabsupdate/about.html
5. a ZMI which allows zope to be an easy to administer database. Easy enough for distribution to powerusers.
Useful, but should be turn-off-able.
I can vote for this as well
I want to be able to have a zope site entirely in the file system with no ZODB, so I can keep it in subversion, and use normal things like grep, patch and sed to apply changes to the whole codebase.
You can do this with zope 2 but you can also allow user customization that you can later migrate in to the filesystem code. If I want it in the site to do a CMS type
application, I want to put it inside my File System Site code, not put a file system site object into it.
Not sure what you mean here. You aren't forced to put filesystem objects into the ZODB. The folders/tree structure of zope is a natural navigational device that is very useful. Check out the book "Don't make me think". Zope 3 has great ideas (components, interfaces, views, maybe PAU) but zope 2 (dtml, TTW, Plone) is what pulls them in the door. And you have to get them in the door before they will buy.
participants (3)
-
Marcelo de Moraes Serpa -
Tim Nash -
Tres Seaver