[Grok-dev] LoginDemo and PlainLoginDemo and BabyLoginDemo

Kevin Teague kevin at bud.ca
Wed Jan 16 13:42:29 EST 2008

> But I would not call it BabyLoginDemo because if baby steps in Grok
> authentication entail implementing your own authentication utility
> from scratch, then I am afraid hordes of potential users will just run
> away.

Well, I was calling it BabyLoginDemo because my friends had a new baby  
the other day ... but then I was thinking it would be cool to have a  
baby caveman character, kind of like Bam-Bam on The Flintstones.

> No matter how simple it is to bake your own authentication utility
> (and I think this is a quality of Zope 3 you've demonstrated) the fact
> remains that anyone who has used Django or Ruby on Rails expects these
> things to be solved with a couple of lines of configuration.

The Django folks were quite merciful, and included a full  
authentication package as part of framework. Ruby on Rails expected  
you to go and write your own stuff (http://wiki.rubyonrails.org/rails/pages/Authentication 
) and as the wiki says, "the confusing world of authentication". They  
do have a few better authentication plug-ins that have risen to the  
top though. Both of these easy authentication developer experiences  
require a lot of backing code to support them though, there is over  
1,000 lines of code in django.contrib.auth for example.

Having a pre-baked auth package for Grok that we can recommend as the  
"default" is the way to go. Figuring out what/how much should be pre- 
baked is a bit of a question. Fortunately Grok includes this wonderful  
thing called the Zope Component Architecture that makes it really easy  
to override existing behaviour :)

> So this leads to the question of who is the target audience for Grok.
> Is it current Zope 3 users or is it web developers in general?

Well, our goal is to create something that web developers in general  
would want to use, but there is still a ways to go in many areas. Web  
developers in general is also a pretty wide target, that would include  
PHP folks to J2EE/JSP people.

It's important that we don't oversell the easy-to-learn aspect too  
strongly for Grok too early on as it doesn't do anyone any good if  
someone new to Python web development tries Grok but then become  
hopelessly confused wandering through the innards of the Zope 3 api  
only to retreat back to PHP with stories of this over complex framework.

If you are a more experienced developer, or you don't mind bonking  
your head against some rough edges, there is lots of things that Grok  
and Zope offer that no other framework has. I think features that make  
putting up with the rough edges that are unique to Zope 3 / Grok are:

  * The Zope Component Architecture gives you an awesome way of  
creating extensible, customizable applications.

  * The ZODB is great for persisting objects that have a complex  
schema inheritance hierarchy.

  * Grok's unqiue configuration-through-introspection method means  
that you can put Models and Views, etc. in the same file (without  
writing XML) which is very nice.

  * zc.buildout/eggs: being able to package up any part of your  
application code as an egg and include it another application using  
the same mechanism that you use to install any normal Python package.  
Ruby on Rails takes advantage of Ruby gems quite a bit, but they have  
one method of managing "external" Ruby code (gems) and another method  
for managing framework-specific code (plugins) (although it's possible  
to package a plugin as a gem but it seems no one does it?): http://blogs.sun.com/arungupta/entry/totd_6_difference_between_ruby

  * Being able to treat data components in your Views/Forms the same  
regardless of whether they came from an object database, a document  
database, a relational database, a loose collection of text files  
database, or a web services is for me the greatest appeal to Zope 3.  
In the field of bioinformatics where I work it's very rare that all of  
your data is neatly wrapped up in a single relational database - it  
comes from everywhere in every format, being able to describe all of  
that data in a uniform method using zope.interface/zope.schema is very  
nice :)

More information about the Grok-dev mailing list