[Grok-dev] LoginDemo and PlainLoginDemo and BabyLoginDemo
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
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
More information about the Grok-dev