[Grok-dev] GrokAdmin separated from 'grok.core' [was: Re: Admin UI name change suggestion]

[Uli Fouquet]

Hi there,

just managed to separate the admin stuff from the 'grok.core'. I did so,
by simply moving all admin related things into a separate package and
building a grok version, which does not include grok.admin anymore.

A few things still have to be finished, namely the ftests and versions
of eggs have to be fixed/pinned.

Currently all this resides in

	http://svn.zope.org/Sandbox/ulif/grokadmin

What would be the best way to proceed from here (given, the above tasks
are done)?

This version of grokadmin works like the old one, i.e. it is bound to
IRootFolder and therefore appears automatically, when you install grok
and grokadmin and fetch localhost:8080/.

The next step (IMHO) would be, to build another version, where the
grokadmin is a regular grok.Application. This application then had to be
instantiated on startup or later to make it appear somehow.

Thus, we would have the grokadmin out of the way and the one problem of
Philipp's trainees (Why don't I see my app but this strange UI?) should
be solvable.

For the other problem (code changes and instantiation of application
objects) you already discussed solutions:

Martijn Faassen wrote:
> Philipp von Weitershausen wrote:

> > [snip]
> > 
> > It might also be nice if we could mark outdated application objects 
> > somehow. People will add a local_utility definition or a grok.Indexes 
> > definition without realizing that they have to recreate the application.
> 
> Yes. This will be an interesting task to implement. In fact I think 
> eventually we'll get a nice library out of the dev UI project to ask 
> things like "give me the views for this object in all known skins" and 
> so on. I think asking a question like "are all utilities installed that 
> could be installed" would be a good one there too. I think though it 
> needs some extra guidance from the code that it won't get now though.
> 
> Besides this we need a 'install all local utilities and indexes needed' 
> button.

All this is basically about 'outdated' objects, i.e. objects, whose code
changed in filesystem and differs from code, that once created the
objects, that are stored in the ZODB, right?

If I understood correctly, a developer currently has to perform two
steps to make changes in the codebasis effective: (1) restart zope, (2)
instantiate a new object of his application class. Often enough, there
are also 'old' applications in the ZODB, for which after restart the
code basis is missing, so that they are (explicitly or implicitly)
broken and should be removed. Therefore an extra step is required: (1b)
delete outdated apps.

I wonder, whether it would be possible, to reduce this three steps to at
least two, at least for grok.Application objects.

Most current developers are used to the three steps, but for newbies and
people from other frameworks it obviously is a strange experience, that
they can simply reload a browser page after (heavily) modifying a
template, but have to restart the whole machinery after adding a single
line of Python code. That was at least my impression from the workshop
at FrOSCon.

Would it technically be possible to make working 'update' or 'renew'
buttons for existing grok.Applications objects? Eventually without
restarting? That should include installing of local utilities and
indexes needed.

BTW: 'renew' would be more adequate from my point of view, because
changed information in containers etc. would most probably be lost.

Last not least: if it should be possible to offer 'renew' functionality
on-the-fly, would it also be desirable? One could say, that people
working with Zope should get used to the ZODB way of storing
(persistent) information and that offering a 'renew' button would hide
away important things.

What do you think?

Kind regards,

-- 
Uli