[Grok-dev] Re: ZCML

[Martijn Faassen]

Hey,

Dennis Noordsij wrote:
[Zope 3 versus Grok]
> Playing with Grok (small so far) is completely different, it really is
> very agile to develop with (to drop some buzzwords :), very quick to add
> things, and to try out new ideas. Behind the scenes the grokking does
> the same as the zcml would do, but it's much more fun because it is so
> fast to develop with, it really makes it a lot more fun _because_
> development is so convenient.

Thanks for this comment. Some of us who created Grok come from the same 
perspective - I noticed that for applications ZCML was just causing a 
lot of overhead for the developers, and started to think about ways to 
get rid of it. It's good to get validation from others about this.

> Some areas where Grok could provide some more functionality itself:
> - pluggable authentication with session credentials and principal
> signup, basically every site dealing with user accounts needs this.
> Although the Zope 3 way is still very easy to do.

Agreed, this feature has been on the wishlist for a long time, brought 
up by many people, but we seem to have a hard time getting the work 
done. We need some "good-enough" default story for user management and 
authentication. I think our grokui work is helping with the UI framework 
to plug this into.

> - vocabulary support. I never really got the subtleties with sources and
> vocabs, my primary use is to make dynamic select dropdown boxes. This
> could be made easy and intuitive.

Good point. I think zc.sourcefactory helps a lot here. A nice tutorial 
on grok.zope.org should help a lot already, and perhaps we should 
include the dependency by default. I'd be good if people could help look 
into this and write some documentation.

> - skinning/macros. It should be easy to drop the default zope3/grok UI,
> make a template with header/footer/content/etc areas, and make it easy
> to use different layouts for mobile/web/etc. It would be really great if
> this could be made easy. The "static" concept in grok is great, but I
> can't use it for my main template to refer to javascript since every
> package which wants to fill in the "body" slot (for example) causes the
> static of the package to be used, instead of the original "global"
> static. Viewlet-based on UI's are great but you need a view to make a
> page with a different name (for the same object), which most likely
> wants to use 99% of the "main" page template.

Also on the wishlist. I hope that the pagelet story will help here 
eventually. z3c.layout and z3c.pagelet are rather hard to understand 
libraries if you go by their doctests, but the principle was fairly 
clear to me when it was explained to me - now rapidly fading away again. :)

> As for my question:
> 
> I want to build a menu-bar as a viewletmanager, with viewlets for
> entries. Thanks for view permissions, the menu always contains exactly
> the right set of menu options for the current user. So far, so good.

We have been thinking about a way to build a simple menu system for Grok 
on top of viewlets too, so this sounds like a good direction.

[snip]
> In grok, if I make a menuitem deriving from grok.Viewlet, it itself is
> registered as a viewlet directly, and the derived classes don't get
> registered.
> 
> I.e.
> 
> class menuitem(grok.Viewlet):
> 	grok.template("menuitem")
> 	def update(self):
> 		# Use self.name and self.url
>                 # Lots of complicated code you do NOT want to repeat for
> every menu item
> 
> class Home(menuitem):
> 	grok.name("home")
> 	name = u"Homepage"
> 	url = "/"
> 	grok.require("mysite.VisitHomePage")
> 
> In ZCML, you would register "Home" as a viewlet, and all would be well.
> In Grok, the grokker groks :) the menuitem itself, and I am not sure the
> "Home" would be picked up at all.

Did you try using grok.baseclass() on menuitem? grok.baseclass() 
prevents Grok from registering classes, and is meant to prevent base 
classes from being picked up.

> I actually use a similar pattern quite often in the original Zope 3
> system, and would like to have some equivalent way to do it in grok,
> i.e. keeping "Home" as lean as possible and putting as much as possible
> in the menuitem class.

Yes, this is a sensible pattern in Grok as well; you make a 
mini-framework, deriving from Grok base classes, and then your 
application code can be very small and simple.

Once you got your mini framework for menus going I'd be quite interested 
in seeing this extracted as a megrok.viewletmenu or something, so we can 
experiment with it. Note that Philipp recently ported Zope 3's menus 
system (non-viewlet based) to Grok too, with megrok.menu. I think 
eventually we need to consider including one of them into the Grok core.

Regards,

Martijn