[Grok-dev] Possible story board for grok 1.0

[Behrang Dadsetan]

First off, apologies for the long mail. To quickly introduce myself,
my background is some one who fell in love with Zope2 years back and
who "dived" into Python because of it.
I have not done too many web applications so far.

   We have been contemplating a soon coming release of grok 1.0 with
the potential self-marketing that comes with it. This community has
come a long way in resolving many of the issues some found unbearable
or difficult not so long ago [1].

   Still there are so many issues that are correctly assessed, where
good ideas are brought up but where the community tends to forget
about after a dozen +1 +0 -0 -1 votes. This happens even when the
community mostly agrees with an idea.

   To try to counter this effect, I will write up a summary at the end
of the discussion and ask for people to step up for actions the
community mostly agrees on going forward to.

Before we reach grok 1.0, I still would love to see the following
happening to improve the newcomer's story board. The newcomer I am
talking about might not even know too much of python just yet.

1- In the download section, I would like to see pre-packaged "getting
started" grok 1.0 install with all batteries included.

  I feel we could make this a package that is mostly based on "grok
core" but where we could allow ourselves to add some "getting started"
extras. For example we could include some of the neat widget factories
and have the gettingstarted.py app already "added" to the Data.fs from
the start.

  I am willing to prepare a Windows installer, MacOS installer and
Debian package. Apart from Mac (where python2.5 is already installed
without any fancy options), I would like to even distribute cpython as
part of the package. Also for all the above platforms, I would like to
pre-compile all the C-written parts so no compiler is required. For
Mac, this could automatically "virtualenv" an area and for the rest it
could use the included independant python. Ideally we should want to
commit ourselves to support at least those 3 platforms (Windows, Mac,
Linux)

  I am willing to host the resulting massive packages on my HK
dedicated server if we have a bandwith limit issue on *.zope.org
servers.

2- We have one of the nicest tutorials, but let's keep a good eye on it

  I believe the beauty of the grok tutorial comes from two elements:
a) Great authors who have spent time breaking down each step and make
it a nice story
b) It is not easy to document software which has too complicated or
too much magic. I think grok shows through its tutorial how nicely it
was designed and how compelling it is.

   Like others mentioned before, it is still difficult to go beyond
the tutorial right now. Maybe more links to other tutorials ought to
be there. And if we do make a special "gettingstarted release" maybe
the tutorial should be oriented towards that installation. Also to
help out a little bit developers who are not into web design too much
(yet), let us give them basic tips on CSS so that our forms don't look
too ugly or some basic ideas for navigation rendering.

3- User authentification story

  We should agree on some simple solution which would give out of the
box user authentification. This could be in the "gettingstarted"
release only but I feel it would not hurt being in grok core. To me
the gettingstarted release includes people who don't know python. Grok
core should still have a good starter story for python users which
must include a good user authentification story.

   I believe this should be something very basic where users get added
through basic forms

   Let us discuss how this could look like. And how we could integrate
it in a grokproject template but allow "advanced developers" to easily
remove it from their setup.py and rerun buildout.

4- Changes to grok.Model subclasses

  We need a good story board for people who make changes to their
models and need to update their persistent objects with reasonable
defaults. There used to be some kind of versioning concept but I have
lost all information on it and I did not see too much advertised from
the grok world for a "recommended solution".

  Why I feel this is important? Chances are most developers have
experience with RDBMS where they add columns to a table and figure out
how to make it have a default for existing data. For ZODB, very few
people have an equivalent experience.

5- Auto-reload of changed .py files

  When you start playing with a framework like zope3/grok you will
make plenty of changes to your code by just tweaking a character or
two at a time. It is quite painful to restart your server every time
(I did not have any good experience with paster doing it well for me
either). Many web frameworks [2] do this.

  I understand it is dangerous and dirty to reload brainlessly. I am
suggested we put our brains to it and come up with a reasonable
solution. Maybe one that can be switched off if the devmode is off.
Maybe one where you have to explicitly declare   which class should be
autoreloaded. Maybe a solution where you need to explicitly (and maybe
verbosely) define what should happen when you reload. I just feel we
should not drop this entirely for a good newcomer story board.

  I will come up with an example implementation from my thoughts in
the next few days but this is of course related to my point 4. Please
do not wait for my example to at least answer point 4, I need your
input :)

6- A five minutes youtube "getting started" screencast

  Ideally I do not want it to contain too much magic [3]. Just
something simple done by an experienced trainer/developer which can
compensate for a lack of "screenshot" possibilities for web
frameworks.


I apologize once more for the lenghty email and thank you for your
consideration.

Kind regards,
Ben.
[1] Background: http://faassen.n--tree.net/blog/view/weblog/2006/09/24/0
[2] At the very least GAE and RoR
[3] I feel the RoR 5 minutes youtube cheats way too much...