[Grok-dev] Re: SVN: Sandbox/ulif/grokintrospector/ Create a sandbox for Grok-related introspector stuff.

[Martijn Faassen]

Hey Uli,

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:
[snip]
> 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, 
correct?

> 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
> others.

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 
>> possible.
>>
>> 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
> namespacing.

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. 
Different discussion).

So, what if we put everything into the following for now?

grokui.admin

If we ever split out the introspector (not now!), we'd have:

grokui.introspector

Eventually we might be able to split off some basic templates and such 
and get:

grokui.core

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 
"management screens".

We might get:

grokui.autocrud

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:

grokui.admin

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.

Regards,

Martijn