[Grok-dev] Neanderthal sprint topics
kevin at mcweekly.com
Fri Sep 28 12:07:01 EDT 2007
Possible sprint topic: Groklets
A Grok take on viewlets. I've been using some prototype code that
simplifies 'viewlet' registration for the
common-case by eliminating the need for a 'viewletmanager'.
In a nut shell...
class MyGroklet(Groklet): # registers directly with the view
grok.name('center') # the 'provider' name
order = 10 # optional
return "<h2>groklet 1</h2>"
grok.context(MyView) # associate with a specific view or shared
order = 20
return "<h2>groklet 2</h2>"
The groklets are available using the 'groklet' tal namespace.
<span tal:replace="structure view/groklet:center" />
Whereas with a traditional viewlet...
# unless customized, this is a dead chicken
return "<h2>viewlet 1</h2>"
order = 20
return "<h2>viewlet 2</h2>"
<span tal:replace="structure view/provider:center" />
In this example it may not seem obvious, but when you have a 'left',
'center', 'right', 'header', 'footer' providers, the dead chickens pile
up quick, since in the common case the viewletmanager does nothing more
than associate the provider name.
Each groklet can act as a viewletmanager if indeed a custom manager is
If this is something the community is interested in persuing, I can
send along the relevant code, but won't have time to do anything proper
with it for a month or two.
PS: +10000 for pinning versions (before I pull all of my hair out :) )
Martijn Faassen wrote:
> Hi there,
> Here is a summery of the proposed sprint topics, with some added by
> myself as I think of them. I'd like all sprint attendees to think
> about picking 2 topics:
> * a smaller topic that they think they can get completed and checked
> in by the end of day 1 or early day 2.
> * a larger, possibly more risky/experimental topic that would take
> more time for the rest of the sprint.
> I'd like to get at least all topics listed here discussed with various
> people at the sprint.
> The idea is that we'll get more chance to actually get things
> finished. Of course on monday we'll need to plan it out in more
> detail, as people are intended to work in pairs, and some people are
> will only be there for part of the sprint as well.
> The sprint topics
> * The Grok website. Let's get a Plone skin going with Sebastian's
> skin in there. Then let's start organizing content. (large topic,
> but could be split into multiple smaller ones)
> * Continue the work on making it easier to write (f)tests for
> applications written *with* Grok. See also:
> * Associating additional info to events (probably more of an Zope-3
> issue initially). See also:
> * Reference documentation. Publishing this online would be good.
> * ZCML configuration actions for grok. Currently grok does CA
> registrations immediately. We should change this so grok generates
> zope.configuration actions so that it works better with ZCML.
> * KSS for Grok. Godefroid will be there for at least the first half of
> the sprint I heard, so I hope we'll get some KSS integration work
> done. Having this would make me really excited, as there's all sorts
> of cool things we can do with KSS. Besides integration code, I hope
> this can also result in some form of tutorial.
> * Viewlets in Grok. Some work was already done on this. Let's step back
> and see how we can make this look natural with Grok.
> * Theming hook for Grok. I know JW and Lennart need to talk on this.
> * Improving the Admin UI. The Admin UI is now there and looking good.
> Now that we start using it, there are a ton of ideas on how to improve
> it, let's get some of them done.
> * Supporting 'pinning versions' in Grok. We should make a good list of
> versions of Grok dependencies, and publish a list on some URL that
> buildout can then reuse. grokproject needs some adjustments too
> to support this.
> * Grok and WSGI. Philipp, who unfortunately won't be there, has done
> quite a bit of work on Zope 3/Grok and WSGI. We could investigate this
> work, experiment with some WSGI middleware, and devise a plan to
> get this integrated into Grok.
> * Grok release planning. It would be good to sit together and discuss
> the planning of the next release(s).
> * Security; make the Grok security "policy" optional/configurable.
> Partially related to this:
> This could be looking into supporting model-level security. JW also
> wants to consider the option to be able to switch from "views
> are public by default" to "views are closed by default".
> * Security and the catalog
> An interesting security feature would be to port the catalog magic
> that CMF does to the Zope 3 catalog, as discussed recently on this
> * Review, extend and merge the REST branch I did.
> Please add your sprint topics!
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev