[Grok-dev] Re: ZCML

[Dennis Noordsij]

Let me abuse this thread for a comment and a question ..

The comment: I have built and maintain a Zope 3 (plain ZCML) site, on
average there is one ZCML file for every 6 .py files, and only 4 lines
of python per line of zcml! (33k versus 8.5k)

The ZCML does get very verbose at times, and it's very repetitive. Make
an interface, ok, make the actual class, ok, define the class completey
in zcml, the whole permissions (which are fantastic, but do get in the
way at times), cover all attributes, etc. Want a view? Ok, define
everything in zcml, write the view, assign a template, etc.
After a while it does slow you down and it does start to get annoying to
go through the motions just to add a small thing here or there.

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.

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

So summarized: Grok is all the zope 3 goodness, but much more convenient
to work with!


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.

In Zope 3, you can build a nice menuitem class based on a viewlet, and
in the zcml register only those derived classes (where you would only
provide a "name" and "link" attribute, and let all the
calculations/layout/etc be done by the menuitem base class). A single
template suffices for the menuitem baseclass.

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.

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.

I hope that made sense :)

Cheers,
Dennis