[Grok-dev] Re: grokui.admin 0.1.1 released
faassen at startifact.com
Wed Aug 6 11:54:10 EDT 2008
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