[Grok-dev] Giving viewlets "the grok treatment"?

Ethan Jucovy ejucovy at openplans.org
Fri May 9 16:47:26 EDT 2008


Hey,

My apologies if this has already been discussed, or if the problem I'm
raising has a better solution besides viewlets; I'm having a bit of
trouble following all the discussion about viewlets, pagelets, etc
right now.  And I know that a grok.Viewlet already exists, but my
understanding of that, from conversations with Rob Marianski, is that
it's basically just a set of directives and some Convention Over
Configuration to let the user bypass some of the hooking up of the
various components.  But what I'm talking about here is, rather,
giving them the full-on "grok treatment" -- making viewlets easier to
use and conceptually simpler, and more accessible to newcomers.

So, my motivation: zope's viewlets are tremendously powerful and
flexible.  But, like much of zope, they're designed to solve all the
possible cases, and they don't make any real attempt to "make the
common cases easy" on their own.  Well, to me that sounds like a
perfect opportunity for Grok to step in and do some smashing...

So, there are three parts to hooking together viewlets: the
page/view/template, the viewlet, and a viewlet manager.  The view and
the viewlet know nothing about one another; the viewlet manager is the
only piece that knows about the other two, and handles hooking all
appropriate viewlets into a particular page, with sorting and
filtering and all sorts of other nice features.  This allows you to
define a single viewlet which can be reused on multiple pages and a
single page which can contain multiple viewlets, and any arbitrary
permutations thereof.

But at least in my experience, I've found that this flexibility simply
isn't what I need.  Many times, I only use viewlets as a way of
injecting content into a page in a nice decoupled way.  That is,
usually I don't care about reusing viewlets -- I just want to define a
couple of viewlets that can plug into a single page, without needing
them to plug into multiple pages.  Heck, most of the time I don't even
care about sorting and filtering.

In other words, most of the time I don't really care about any of what
a viewlet manager provides.

So what I'm wondering is whether it might be valuable for Grok to give
me some directives which magically simplify the whole process of
hooking viewlets up with pages "the simple way", without worrying
about a viewlet manager at all.  I'm envisioning something where a
viewlet can be hooked directly in to a view; behind the scenes, Grok
creates a default viewlet manager and actually configures the view and
the viewlet to that manager, but the user needn't know about this at
all.  If at some point in the future the user wants to dive deeper
into the world of viewlets and start to use the power of viewlet
managers, he can simply switch the directive to point to a custom
viewlet manager.

Something like ...

class MyViewName(grok.View): pass
class MyViewlet(grok.Viewlet):
  grok.viewlet_to_view('myviewname')  #this is a horrible name, but
you get the idea
class MyOtherViewlet(grok.Viewlet):
  grok.viewlet_to_view('myviewname')  #this is a horrible name, but
you get the idea

And when you later discover you need a custom viewlet manager after
all, you just create one per the current syntax:

class MyViewName(grok.View): pass
class MyViewlet(grok.Viewlet): pass
class MyOtherViewlet(grok.Viewlet): pass
class MyViewletManager(grok.ViewletManager): # now we actually care to
do some advanced stuff here
grok.viewletmanager(MyViewletManager)

Of course, add another dose of hook-up-things-in-the-same-module
Convention Over Configuration and the first example can be even
simpler:

class MyViewName(grok.View): pass
class MyViewlet(grok.Viewlet): pass
class MyOtherViewlet(grok.Viewlet): pass

(Of course, it's my understanding that the template will still need to
refer to a viewlet manager; I think this is okay, though; the default
manager for the view could get a conventional name and the template
could say "structure provider:myviewname.viewlets" for example.)

Do people think this is worthwhile?  And is it something that's
already solved, either by grok's viewlets or by some other technique?
If so, I'd love to learn about it, because I sure could use this.  :)

egj


More information about the Grok-dev mailing list