[Grok-dev] Re: SVN: Sandbox/ulif/grokintrospector/ Create a sandbox
for Grok-related introspector stuff.
faassen at startifact.com
Tue Jun 17 19:03:35 EDT 2008
As a general point; you're not stupid, I don't think you're stupid and
you're doing good work. You're not taking away my time; I'm your mentor
and I'm supposed to help you and guide you along. I am trying to offer
you feedback and engage in discussion, not to discourage you. I also
reserve the right to be wrong or uninformed, and you'll just have to
point out to me where I am. :) So please stop apologizing. Now that
basic context is out of the way, let's get back to the details:
Uli Fouquet wrote:
> Sorry, the split was motivated by separating the tasks of (1) decoupling
> grok.admin from grok and (2) introducing new/modified functionality into
> what now is grok.admin and will be something else.
I think decoupling grok.admin is a good idea, so I understand the
grokadmin project. I was confused by the introspector project as this
seemed to be taking place in Grok but is intended to go into grokadmin,
> It was not motivated by splitting up something like megrok.admin,
> megrok.introspector etc. Instead I planned introspector to be a
> subpackage of admin, wherever this (admin) will be (and that's what I
> actually did in the sandbox).
I think it's fine to let the Grok introspector be a sub-package of
grokadmin. We may want to take it out at some point, but upon
consideration I tihnk making it part of the admin UI is the right
approach at this point in time.
It was just confusing to me that this was happening not in grokadmin but
in a branch of Grok. I was assuming you'd start modifying grokadmin with
such functionalities. If you make another sandbox package my first
assumption is that this is its own project.
>> grokintrospector does appear to be a straight copy of Grok (and thus
>> should be a branch of Grok). I'm confused why this isn't a grok
>> extension as well.
> As said in my other posting, it is currently modifying grok.admin,
> something that will vanisch from grok.
Yes, I understand it better now.
> Because I expect some heavy problems during the switch from grok.admin
> to a separate grokadmin (or megrok.adminui or whatever) package, I
> *started* it as a real grok.admin extension, to make sure the
> functionality is available, although there should be major problems with
> the outfactoring. grok.admin is therefore not the place not the place,
> the introspector is supposed to be in future.
I'm not sure whether doing this on two tracks is the best idea. Why not
focus on getting the separate grokadmin to work first and then starting
on the grok introspector? This avoids um.. complicated merges. :)
> This way I can track the changes needed to implement introspector
> functionality and the changes needed to factor out grok.admin from grok
> better. But that does not seem to be a reasonable thing for others, so I
> will put that all together tonight and see, how I can differ that
> changes later on.
If it's just prototyping I think it's a reasonable approach.
I do think that an independent grokadmin is hopefully not *that* far
away, and I was assuming you were going to get that working and then
would start with the introspector. If you introduce a different skin or
something, it might even run in parallel with the current built-in admin
UI so we have less to coordinate and can take out the built-in grok
admin when we're ready.
> Anyway, I will make it all grok branches, if that is better traceable by
Yes, I think sandbox copies of existing projects should be discouraged
in favor of branches (with externals pointing to them). They're
technically the same thing, but it's a bit more clear to the project
what's going on if you do it this way.
>> I think we should be focusing on simple light-weight packages that are
>> developed independently of other packages (such as Grok) as much as
>> Note that Grok extensions tend to be called 'megrok.*'. So I'd suggest
>> megrok.admin and megrok.introspector for the package names.
> megrok packages, as far as I've seen, are extensions of grok
> functionality. I got the impression, that they give _developers_ the
> possibility to do new things. The admin UI will instead become a
> standalone application (depending on grok, but not really 'extending'
> it) and giving _end users_ the possibility to do new things. Therefore I
> thought it would be better placed in `grokapps` or similar places than
> in megrok. I might be wrong on this as well and will change also that
There is a difference, indeed. The admin UI itself (without
introspector) is something a non-developer might want to install,
possibly, though I'd say it's still mostly a development tool. The
introspector is definitely a development tool. So in a way it does give
new features to Grok, though it's not a traditional extension. I do
think there is a different however.
We could introduce a 'grokui' namespace for what you're doing. A future
automatic always-present CRUD UI along the lines of the Django admin UI
could also be in this namespace (though I hope we'll also see a CRUD
development framework that allows people to develop custom CRUD UIs.
So, what if we put everything into the following for now?
If we ever split out the introspector (not now!), we'd have:
Eventually we might be able to split off some basic templates and such
which could be a UI that the other UI bits can plug into. It's not
intended to be a full CMS or a way to create a CMS, just a framework for
We might get:
or whatever at some later stage.
Christian Theune has also talked about a application management UI, sort
of like the admin UI on steroids for large scale hosting. I believe the
'zam' packages in svn.zope.org also offer features something like that.
Anyway, my recommendations. I think if you continue what you were doing
with something called:
I hope that this can be made into a working extension to Grok soon
(hopefully in parallel to the current admin UI), so that you can build
up the Grok-specific introspector in it too.
My apologies for any lack of comprehension and brusqueness on my part.
More information about the Grok-dev