[Grok-dev] grokadmin: separating admin UI from grok.core

[Uli Fouquet]

Hi there,

there are many reasons to separate the admin UI from the grok 'core'. To
make this possible I started a separate branch in my sandbox, which
provides a new package, currently called ``grokadmin``. I am not sure,
whether this is a good name.

``grokadmin``: current status:
------------------------------

Current status is, that with this package, grok can (but don't has to)
include a package ``grokadmin`` which behaves almost identically to the
``admin`` subpackage currently provided with the grok trunk. All this
already works.

In my sandbox there is also a grok branch, which has all the ``admin``
related stuff removed and that could replace the current grok core
(after merging in the last changes to the trunk). I might copy it to
grok/branches.

The ``grokadmin`` package is currently only a package and not available
as egg, nor listed on cheeseshop or similar. That's because I have never
created eggs for the public before and would like to get hints and help
in that matter. Is there anyone, that can support me with that?


Possible plans to separate the ``admin`` stuff from grok:
---------------------------------------------------------

Step one:
~~~~~~~~~

In a first step, ``grokadmin`` could be distributed as egg and then the
``admin`` stuff be removed from the grok core.

Alternatively, the grokadmin package could be provided as an
accompanying developer package (like ``grokwiki``) with the trunk (also
removing ``admin`` stuff from the core).

I am undecided which way would be the better one, or whether there is a
better, third way.

For a soon release, all this might be too hairy. I would therefore
prefer to do UI related works on the basis of the current ``admin``
subpackage. It should be easy to merge changes with ``grokadmin`` when
we decide to release it.


Step two:
~~~~~~~~~

In a second step I would like to make the grokadmin a real
``grok.Application``, such that it doesn't have to be bound to the ZODB
root anymore. This however, could be done very fast or slowly. Fast, if
I only do the needed changes to bind the application to another kind of
object. Slowly, if I take the chance to refactor some things, that after
working a few months with grok do not any longer look very elegant to
me. I would really prefer the slow approach and refactor the
``grokadmin`` package carefully and step by step.

When ``grokadmin`` becomes a real ``grok.Application`` we have to
provide a way to instantiate (or not to instantiate) it on startup.

It is also an option to skip step one and directly jump into step two.

Kind regards,

-- 
Uli