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

[kevin at mcweekly.com]

Hi friend, let me buy you a drink :)

After using viewlets in earnest, I basically experienced exactly what  
you are saying and thought how do I grokkify viewlets? I call them  
Groklets, they work pretty close to the way you suggest, except that  
groklets merge the concept of viewletmanager with 'viewlet, without  
dependencies on zope.viewlet.

You can do everything with a groklet that you can do with a standard
viewlet  (sort, filter, whatever) while cutting out the middleman.

For an example see this post
http://groups.google.com/group/zope-grok-dev/browse_thread/thread/3e60a5301adc683c/a183d56a3792cd81?lnk=gst&q=groklets#a183d56a3792cd81

For proof of concept code (based on grok 0.9) see
http://svn.zope.org/grok/branches/ksmith_mcweekly-groklets/

Works for me, I use it everyday, but I think there is a lot of work that needs
to make it ready for a release.


Kevin Smith

Quoting Ethan Jucovy <ejucovy at openplans.org>:

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

yup, I hear you.

   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
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>