[Grok-dev] Re: letting Grok take over the site

[Shane Hathaway]

Martijn Faassen wrote:
> Making the grok admin UI a grok application that users can select, as
> Shane suggests, sounds intriguing but I am not sure what it means. Could
> you elaborate, Shane?

Sure.

The root folder will store the name of the default application.
Initially, the default application will be "grok", an instance of the
Grok admin UI.

Until the user wants to put their own app at the root, Grok URLs will be
as simple as they are today.  "/" initially shows the list of
applications, "/hello" shows the application named "hello", etc.  Under
the covers, visiting "/hello" actually visits the default application
first.  The traverser for the default application, which is still
"grok", sees the name "hello" and reasons that the user wants to visit
an application other than Grok, so the traverser finds that application
in the root folder and traversal continues from there.

Now the user uses the Grok admin UI to select the "hello" application as
the default.  Visiting "/" takes the user to the hello application, but
without further enhancements, at this point there is no way to visit the
Grok admin UI again.

To solve that problem, a new traversal namespace called ++app++ will be
added.  Users will be able to specify which app they want to visit using
"++app++myappname" at the start of the URL.  When traversing, the step
after the root folder will prefer the object named by the URL's ++app++
parameter, falling back to the default application specified by the root
folder.  So to visit the Grok admin UI again, users will use
"http://localhost:8080/++app++grok".

The ++app++ namespace will not be necessary until the user selects a
different application at the root, so Grok doesn't have to tell the user
about ++app++ until the user is about to select an application to put at
the root.

Users could conceivably delete the grok admin UI application, but if we
allow that, they will need some simple command line procedure to put it
back.

This whole idea does suggest a discussion about whether a Grok project
ought to hold more than one application instance.  My opinion is that
it's very useful to have multiple instances in one database.  In
development, one instance might show how the app behaves with no data
while another might be filled with content.  In production, different
instances might be set up for different groups of people, with software
upgrades applying to all instances at once.

This doesn't prevent competing mechanisms.  Because of the component
architecture, advanced users could apply a different Zope configuration
that starts traversal at their application rather than the ZODB root
folder, bypassing everything I described above.  I'd really like to see
that work as well.

Shane