Benji York, a relatively recent Zope Corporation employee, first
appeared on my "does interesting stuff" radar due to his work with Zope 3 testing: zope.testbrowser, which promises to bring to
Zope 3 testing something I played with before in the context of Silva but never really made very usable: functional testing of the web frontend of code on the server side (utilizing mechanize). Benji's innovation to make this really easy is by integrating it with doctests. Zope 3 is an extremely well tested framework already and through
the efforts of Jim Fulton, Tim "doctest" Peters, Benji York and others is continuing to push the boundaries in this area. At the
same time, by using doctest in ever expanding ways, they also pushing forward software documentation at the same time. I haven't seen any other Python project with a stronger emphasis on testing, except possibly PyPy. Zope 3's rock solid, and we know it, as we keep banging on it with more tests. This is not the only thing Benji has been up to though; today I discovered his new weblog, where he says good stuff on a topic close to my heart: Zope 3 marketing. Moreover he is actually doing something about it. He's written the
beginnings of a Zope 3 quickstart guide that should help
people on their way when learning Zope 3. Perhaps it can eventually lead to a "20 minute screencast" on Zope 3. Such screencasts seem to be an essential framework marketing tool in this day and age...
![[Comments]](/blog-content//themes/Default/comments.png "16 comments")
(16) Tue Oct 04 2005 19:50 Benji York is doing good work:
- Comments:
Posted by Paul Everitt at Wed Oct 05 2005 09:28
Well said, Martijn. I just read through Benji's quick start. Amazingly, he made it through 8 hands-on sections before even mentioning interfaces. Fantastic! While people need to learn such abstractions eventually, his Quick Start guide actually gets people started, errm, quickly, before asking them to take their vitamins.
Posted by Stephan Diehl at Wed Oct 05 2005 10:00
Maybe it's only me, but if I have to edit xml config files in order to get a 'hello world' type web application running, the framework is clearly not for me. (and a 20 minute screencast wouldn't help).
If you think that zope3 is what the world waited for, please try to make a 'zope light' that is as easy to start with than, let's say, cherrypy.Posted by Martijn Faassen at Wed Oct 05 2005 11:39
It isn't just you who complains about editing XML
config files. I think that's in part due to the meme spread most effectively by Ruby on Rails that configuration that is not in the programming language itself is evil. In the Zope community we believe configuration in a domain specific language can be valuable, as we've *already* gone through the difficulty of it all being in Python in Zope 2. It doesn't scale very well once your application gets larger. Your application becomes harder to plug into.Zope 2 has been used to build a whole range of CMSes. I
do not believe they have their peer in elsewhere in the Python world in range of features and pluggability. It's therefore probable that the scale of deployments and configurability that the typical Zope developer of such systems has to deal with is a lot larger than the typical Python web application developer. This influences design choices. Zope developers value pluggability, by other people, at another time, without necessarily change the core, a lot more than the average Python developer.This pluggable component model means that in time the featureset that Zope 3 will have to offer will be hard
to beat.Unfortunately, it has also meant that Zope is not as easy to scale *down* to small applications. Not being able to scale down negatively impacts the learning curve, and that negatively impacts adoption. We should fix this, and in fact work has been done on it. You're right in that the "hello world" case should be even easier (even though Zope's "hello world" does a lot more than you'd think at first sight).Would it help if the configuration language wasn't XML,
by the way? Or do people fundamentally object to the concept of a domain specific language for configuration?Posted by Stephan Diehl at Wed Oct 05 2005 14:28
Martin, based on your comment, I'd say that Zope has a different target audience than, say Cherrypy. (I'm using Cherrypy as an example, because it's the easiest to get started with IMHO). I can assure you, that my observation about xml config files doesn't come from some other web framework written in Ruby.
So, my point is the following: if I'm using a framework (or library or any other foreign code), I want to be able to use just as much as I really need. I don't want to be bothered about features I don't care about at the moment. I'm scared about Zope exactly because it's doing a lot more than what I think when doing a 'hello world'.
What I'd like to see is that the different web application teams would sit together and agree on a common set of supporting libraries for web development (o.k., I'm dreaming here).Posted by Mats Nordgren at Wed Oct 05 2005 16:41
Benjis quick start is one of the simplest guides to Zope3 development I've come across, cudos to you Benji. It would have been even greater had it not required a svn version but a released version, but that is a minor issue.What Zope3 needs are:1. Break Zope3 free from the bowels of the development section on zope.org. We are at the second release, yet it is still not presented as a viable environment by zope.org. I'd suggest creating a whole new site just for Zope3.2. Update the documentation section. Remove old stuff that is no longer needed, it can only create confusion. If needed to be there create a "historical artifact" section where it should live. The only documentation that serves a purpose on zope.org is Jims fantastic development book. Great job Jim.3. Create how-tos and recipes. While lots can be learned from the development book it is not nearly enough. How do you make a folder a site at initialization? How do you make an ordered folder display up and down arrows in your browser? How do you create a simple autentication and user management function in your site? How do you simulate "owner" with workflow? etc etc. Simple practical examples are far better than theoretical answers.4. Set up a forum section on the Zope3 site where people can participate in discussion and recieve help. Mailing lists might be great, but it is a hassle for someone that is just checking zope out for the first time.Just my 2 cents. Zope is a wonderful environment and I've been a fan of it since the 1.X days. If there is anything I can do to make this or something like it happen please let me know. I'm a retard when it comes to programming, but I certainly can organize documents if that would be of help.Sincerely,Mats
Posted by Martijn Faassen at Wed Oct 05 2005 17:00
Zope 3 does largely make it possible not to think about features you don't care about yet.Zope 3 does a lot more than what you think not because your object is magically doing much more, but because you or someone else, or the framework, can use ZCML to glue other components (views, adapters) to it.At the heart the component architecture tries to solve exactly the problem that you want to write simple code and *still* benefit from the features the framework can offer. It's trying to solve a problem that's very fundamental
if you write complex extendable applications.I'll note here that I don't think a framework is exactly like a library -- in exchange for buying in you get features, but buying into a framework is not without
cost. Zope 3 goes a long way to try to minimize the cost without minimizing the features, but writing it all yourself from scratch will always make you more free than using a framework.Does Zope have a different target audience than,
say, CherryPy? Yes and no. I think it aims at the general
web application developer just as CherryPy does. It also expects that this web application developer will end up in a situation where pluggability becomes important:* now the same app, but with a new content object* now the same app, but with a radically different look and feel* now the same app, but authenticate with LDAP* now the same app, but with this one extra view to an object written and maintained by these other people* now a new app, but you already have the LDAP authentication part and the view displays this information and the new content object -- remix them!This kind of flexibility requirement is not true for all web applications. But perhaps for more web applications than one would expect at first sight.Posted by Edoardo "Dado" Marcora at Wed Oct 05 2005 18:42
I agree with everything Stephan and Mats said.In particular, I would like to comment on Stephan idea of a Zope3 'light'.I see having to write ZCML for the simple scenarios and overkill and something that can scare people away. Why not having a generator ala RoR in the bin directory that would layout an MVC application folder layout (with views, controllers, and models directories) and write the appropriate ZCML (which, if I understand correctly, is used to create the plumbing among components, what RoR does by convention over configuration). People then would only have to write the python and zpt code. Perhaps a reasonable default security setup could be also autogenerated, etc. To make easily digestible by newbies like me, the generator should also create scaffold that uses the schema information in the model files to autogenerate 'view' and 'edit' views. I could go on and on, but I hope you get the point. It seems to me that everything is there to make such a generator. I am not much of a programmer... otherwise I would have already done it for myself.Just my two cents.Dadop.s.: having to restart the server every time I change a source file also sucks ;) :( !!!
Posted by Martijn Faassen at Wed Oct 05 2005 19:38
I agree that the Zope 3 web presence needs work:http://faassen.n--tree.net/blog/view/weblog/2005/04/06/0I'm not much a fan of code generation myself; something that could be handled by code generation could also be handled by putting some more abstractions in the system itself.Anyway, this all chimes in pretty much with Jim Fulton's bobo branch for Zope 3, and Paul's recent weblog entry on
this:http://radio.weblogs.com/0116506/2005/09/10.htmlSo, some work is being done. It should be done. Not because I believe Zope 3's architecture is too complicated in general, but because it may be too complicated for the beginner.Posted by Mats Nordgren at Wed Oct 05 2005 19:43
While valid points dado, I'm not sure I agree with you. The zcml configuration is extreemely flexible and to have a script deciding what to be in it would take control away not add it. Perhaps the zcml configuration program that was talked about on the dev list might be a better direction to make it easier yet leave the control in the developers hand. Also keep an eye on ArchGenXML. I hear they are working on porting it to support Zope3. It will make it a breeze to make components through UML far surpassing anything RoR has to offer. Zcml is really not that difficult, personally I think it is one of the easiest aspects of Zope3 development.To recap, create your models in UML, run a wizzard/config program to tie it together in xml. This would take zope3 miles ahead of anything else out there.Guess that brings the total to 4 cents.Mats
Posted by Edoardo "Dado" Marcora at Wed Oct 05 2005 20:38
Mats:ArchGenXML for Z3 would be a great way to create content objects (aka Models in MVC parlance). However, I would like to have a folder structure + files containing boilerplate code that Z3 can "read" and respond appropriately following an MVC paradigm. I think Z3 can already do something similar by reading interfaces (which would be generated easily with ArchGenXML) and spitting out code.My idea was the following, why not have something like Tim Morgan's React in Z3, but with the added advantages of keeping code on the file system? This way you would give newbies enough to start writing simple apps, get their feet wet and start thinking about Z3/ZCML power and flexibility (which can I always come in at a second stage, if needed).If the MVC "flow" of things could be written into the framework itself it would definitively better than code generation. One would just have to put the right files in the right places and have an app come alive without much configuration at all.Does that add two more cents? ;)Dado
Posted by Martijn Faassen at Wed Oct 05 2005 21:26
"they" are indeed working on ArchGenXML for Zope 3; I was at the castle sprint just a few weeks ago where a whole team of people was working on it. (I myself worked on Five stuff,
though chatted with the ArchGenXML people about their work too)Posted by Mats Nordgren at Wed Oct 05 2005 22:02
>>> The only documentation that serves a purpose on zope.org
>>> is Jims fantastic development book. Great job Jim.Duh... sorry that should be Stephan Richter... My bad.Posted by Jeff Shell at Thu Oct 06 2005 01:08
"""
To recap, create your models in UML, run a wizzard/config program to tie it together in xml. This would take zope3 miles ahead of anything else out there.
"""Ugh. First, not it wouldn't. Some ancestors of Philip Eby's "PEAK" (I think it was Transwarp) did this. Few of Eby's products along those lines ever got completed, however, in favor of the next idea he had, at least up until PEAK. Whether that's an invalidation of the general ideas or what, I don't know.There are great visual-model based systems out there. The Enterprise Objects Framework which powers WebObjects is one such system. There is still a lot of coding and such beyond just designing the model.In Zope 3, the model is plain Python code, often enhanced by interface schemas. Using these schema definitions, views and edit forms can be automatically generated - not by code generation (an evil thing, in my opinion), but by dynamic introspection. These views are typically configured via ZCML, but they *could* be done in Python. Although anyone that's suffered through crazy __init__.py files in Zope 2 and didn't know if their product would be configured before or after Formulator probably knows that there are benefits to having configuration separate from programming code. Or is it cool to over-separate model/view/controller but throw configuration about willy-nilly?"""
If the MVC "flow" of things could be written into the framework itself it would definitively better than code generation. One would just have to put the right files in the right places and have an app come alive without much configuration at all.
"""Also a bad thing, I think, at least for professional apps. Right files in right places is a recipe for disaster if you accidentally add a "right file" that you don't realize is a right file. For an example of this, travel back in time to an old version of Zope 2, and probably all of Zope/Principia 1.x. Add a DTML method named 'target' using the ZMI. Watch the hilarity ensue as the ZMI's tabs render wildly out of control. Why? Because 'target' was a magic name. This situation has since been fixed, but it's still a relevant example. Having something go wrong because of a syntax error, logic error, or configuration error that's my fault is one thing. Having something go belly-up because I gave it a common name that the framework secretly wants to use is beyond frustrating. About the only special names in a Zope 3 package you're likely to find are '__init__.py' and 'configure.zcml', and those still have to be explicitly loaded / imported by something else.Zope 3 uses full MVC separation, although "view" and "controller" are kindof muddied... but not in a bad way. No, Zope isn't forcing you into directories named models/views/controllers. And it isn't forcing you into modules or packages named "browser", even though that's the prevailing idiom. It's all there though! There is just explicit view binding of view components to model classes or interfaces. The number of cool things my company of two developers has been able to accomplish with this in the last two months is amazing. And a lot of that has come from the little bit of extra explicit bindings between things. It actually makes it easier to embrace and extend other code. I find it funny that half of the responses in this thread balk at the configuration language of ZCML (which could be any kind of domain specific language, as has been pointed out - I just like that configuration is separate from code); half seem to be eager to avoid Python entirely and spit out a fully functioning application from some random UML tool.Posted by Brian Mahoney at Thu Oct 06 2005 01:46
Has anyone experimented with SCons for building configurations? That would be in Python.
Posted by Edoardo "Dado" Marcora at Thu Oct 06 2005 03:47
In response to Jeff:I am sure that ZCML etc are powerful tools in the hand of professional programmers... and perhaps that is the audience that Z3 is targeting. But given the success of projects like RoR, I would not forget the not-so expert programmer (like myself, I am not programmer, I am trying to write a Wiki-like system to use in the organization of the kind of information that molecular neurobiologists, like me, have to store and search every day).Trading flexibility for more rapid development (and less writing of framework specific/boilerplate code) is something us "occasional programmers" are more than willing to do... thus I think the success of frameworks like RoR and the Python RoR work-alikes, Django, Subway, and TurboGears (and others).If one has the time (or is paid) to explore the full power of Z3 then why not?!? But simple applications should be definitively more intuitive to write in Z3. In particular, I like Subway, which does not generate code at all, but does a good job at simplifying the code by using convention over configuration. It would be great if Z3 was able to do that since it adds great complex object persistence and full-text indexing/search, which is why I am trying to write my app in Z3.Cheers,Dado
Posted by Mats Nordgren at Thu Oct 06 2005 19:36
"""
There are great visual-model based systems out there. The Enterprise Objects Framework which powers WebObjects is one such system. There is still a lot of coding and such beyond just designing the model.
"""Fair enough. Maybe I should have stated, ahead of any of the RoR'ish frameworks. My bad. And I agree there is still lots of coding beyond just designing models, just as there are in any of the RoR'ish frameworks. My point was simply that having software like AGX would benefit the community to ease the burden of writing models by hand. Use it if you want, if not do it by hand, but the choice is there. If there are better ways through introspection to configure the application, then great. Again, I am a programming retard and will defer design issues to the 99.9999999% of you who are far better at making them than me.
