[Grok-dev] Re: grokui.admin 0.1.1 released

Martijn Faassen faassen at startifact.com
Wed Aug 6 11:54:10 EDT 2008

Hey there,

Philipp von Weitershausen wrote:
> We should try to see how this cooperates with the z3c.form effort. 
> z3c.form also defines all its views in a special layer, so when 
> megrok.z3cform and grokui.admin are installed at the same time, you'd 
> probably want both layers to be activated by default.

Hm, I think grokui.admin is fundamentally different from megrok.z3cform.

I'd suggest we have a grokui skin. Uli right now sets up a special 
++grokadmin++ namespace which is essentially the skin, we can debate on 
whether it should just be a skin or have a special namespace. I'd call 
it grokui by the way, I think it's better than 'admin'. It's just the 
"Grok UI", which could contain all kinds of functionalities.

I'd *not* want ++grokui++ to be visible by default. I think it's good to 
have a separate URL space for Grok (admin) UI related activities. This 
can then contain the introspector and the future utility settings screen 
and so on. Separating this away strictly from any real content views 
sounds like a good idea. When you look at an actual grok application, 
there should be absolutely no chance anything from the Grok UI gets 
pulled in. This is a separate view on things altogether. We will go as 
far as override the 'index' for the grokui skin to be the object 
introspector after all.

Now megrok.z3cform's layer story is quite different, this is a layer you 
*want* to see when you actually look at your application.

So I would suggest we keep these things quite separate. We should indeed 
have a layer for Grok UI stuff, but we shouldn't include this layer by 
default in some "grok default skin" at all.

What we want for megrok.z3cform concerning layers - I think we need a 
discussion on what a "grok default layer" would even mean, what the 
consequences would be for developers that use grok, and so on, first.



More information about the Grok-dev mailing list