grokui.admin 0.1.1 released

[Uli Fouquet]

Hi there,

grokui.admin 0.1.1 was released today. Just some minor bugfixes left
over from the refactoring (thanks to Michael Haubenwallner!).

As said before on this list, this package provides the same
functionality as the old grok.admin subpackage.

Current status is:

 * with the current Grok trunk (0.14dev) you can use the package out of
   the box. Just add 'grokui.admin' to the dependencies of your
   grokproject in `setup.py`, rerun `buildout` and enjoy :-)
   At least it worked like a charm when I tried it today.

 * with the current Grok release (0.13) you have to perform the step
   above and then you must modify your configure.zcml so that

       <include package="grokui.admin" />

   appears before any `<include package="grok" />` directive. I tried
   to fiddle around with `includeOverrides`, but had no luck yet.

   Note, that there is not much sense currently in using grokui.admin
   with Grok <= 0.13, because you will get the same functionality as
   before.

Plans:

 * Move all to `++grokadmin++`

   Next step is to move all functionality into an own URL namespace
   like `++grokadmin++`.

 * Bind rootfolder

   There _will_ however, stay a view bound to the rootfolder, that
   offers the same (or a similar) intro screen as now. There are some
   pros and cons about this behaviour, but I think it is important for
   starters with grok to have something they can play around with.

   You can, of course, define your own view for the rootfolder and
   override the one defined by 'grokui.admin' in your own projects.

   Another option would be to move everything in an own URL namespace
   and people had to enter `localhost:8080/++grokadmin++/ to get the
   intro screen.

 * Remove `documentation`

   As soon as grokui.introspector is in a nice shape, the whole docgrok
   thing ('documentation' in the menu), will be removed from
   `grokui.admin` and you then have to require the introspector package
   explicitly in `setup.py`.

 * Add `grokui.admin` to grokproject

   I would like to add `grokui.admin` to the requirements of new
   grokprojects, so that they will have an admin-UI by default.

   Developers could remove that from their projects if they want.

   This would mean some minor changes in `grokproject`.

What do you think?

Best regards,

--
Uli



_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Peter Bengtsson]

>
>  * Move all to `++grokadmin++`
>
>   Next step is to move all functionality into an own URL namespace
>   like `++grokadmin++`.
>
+1

>  * Bind rootfolder
>
>   There _will_ however, stay a view bound to the rootfolder, that
>   offers the same (or a similar) intro screen as now. There are some
>   pros and cons about this behaviour, but I think it is important for
>   starters with grok to have something they can play around with.
>
>   You can, of course, define your own view for the rootfolder and
>   override the one defined by 'grokui.admin' in your own projects.
>
>   Another option would be to move everything in an own URL namespace
>   and people had to enter `localhost:8080/++grokadmin++/ to get the
>   intro screen.
>

+1
Keep it. It's a nice start for beginners. Having to RTFM to get the
admin interface is a no-no.

>  * Remove `documentation`
>
>   As soon as grokui.introspector is in a nice shape, the whole docgrok
>   thing ('documentation' in the menu), will be removed from
>   `grokui.admin` and you then have to require the introspector package
>   explicitly in `setup.py`.
>
>  * Add `grokui.admin` to grokproject
>
>   I would like to add `grokui.admin` to the requirements of new
>   grokprojects, so that they will have an admin-UI by default.
>
>   Developers could remove that from their projects if they want.
>
>   This would mean some minor changes in `grokproject`.
>

+1

> What do you think?
>
> Best regards,
>
> --
> Uli
>
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> http://mail.zope.org/mailman/listinfo/grok-dev
>
>

--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Philipp von Weitershausen]

Uli Fouquet wrote:
> Plans:
>
>  * Move all to `++grokadmin++`
>
>    Next step is to move all functionality into an own URL namespace
>    like `++grokadmin++`.

It's technically a good idea not to interfere as much as possible and
therefore put things on this traversal namespace. However, I think from
a practical perspective, it would be a bit more useful if grokui.admin
simply put all its views on a special layer, say, IGrokAdminLayer. Thi
layer would be part of the Grok default skin, but you could easily opt
out of it and with one big bang, the whole admin UI was disabled (very
useful for production), but you could still get at it manually, e.g. by
using the ++skin++ traverser (e.g. when you're trying to debug a running
instance).

What do you think?

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Uli Fouquet]

Hi there,

Philipp von Weitershausen wrote:

> Uli Fouquet wrote:
> > Plans:
> >
> >  * Move all to `++grokadmin++`
> >
> >    Next step is to move all functionality into an own URL namespace
> >    like `++grokadmin++`.
>
> It's technically a good idea not to interfere as much as possible and
> therefore put things on this traversal namespace. However, I think from
> a practical perspective, it would be a bit more useful if grokui.admin
> simply put all its views on a special layer, say, IGrokAdminLayer. Thi
> layer would be part of the Grok default skin, but you could easily opt
> out of it and with one big bang, the whole admin UI was disabled (very
> useful for production), but you could still get at it manually, e.g. by
> using the ++skin++ traverser (e.g. when you're trying to debug a running
> instance).
>
> What do you think?

That sounds exactly like what I want :-) I was not aware, that there is
a Grok default skin. Where is it defined?

Kind regards,

--
Uli




_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Philipp von Weitershausen]

El 6 Aug 2008, a las 16:05 , Uli Fouquet escribió:

> Philipp von Weitershausen wrote:
>> Uli Fouquet wrote:
>>> Plans:
>>>
>>> * Move all to `++grokadmin++`
>>>
>>>   Next step is to move all functionality into an own URL namespace
>>>   like `++grokadmin++`.
>>
>> It's technically a good idea not to interfere as much as possible and
>> therefore put things on this traversal namespace. However, I think  
>> from
>> a practical perspective, it would be a bit more useful if  
>> grokui.admin
>> simply put all its views on a special layer, say, IGrokAdminLayer.  
>> Thi
>> layer would be part of the Grok default skin, but you could easily  
>> opt
>> out of it and with one big bang, the whole admin UI was disabled  
>> (very
>> useful for production), but you could still get at it manually,  
>> e.g. by
>> using the ++skin++ traverser (e.g. when you're trying to debug a  
>> running
>> instance).
>>
>> What do you think?
>
> That sounds exactly like what I want :-) I was not aware, that there  
> is
> a Grok default skin. Where is it defined?

There isn't one. I'm suggesting we introduce one.

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.

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Hey there,

Philipp von Weitershausen wrote:
[snip]
> 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.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev