[Grok-dev] Neanderthal sprint topics
Kevin Smith
kevin at mcweekly.com
Fri Sep 28 12:07:01 EDT 2007
Hi There,
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 MyView(grok.View):
grok.context(App)
grok.name('index')
class MyGroklet(Groklet): # registers directly with the view
grok.context(MyView)
grok.name('center') # the 'provider' name
order = 10 # optional
def render(self):
return "<h2>groklet 1</h2>"
class MyGroklet2(Groklet):
grok.context(MyView) # associate with a specific view or shared
interface
grok.name('center')
order = 20
def render(self):
return "<h2>groklet 2</h2>"
The groklets are available using the 'groklet' tal namespace.
app_templates/myview.pt
<span tal:replace="structure view/groklet:center" />
output...
<h2>groklet 1</h2><h2>groklet2</h2>
Whereas with a traditional viewlet...
class MyView(grok.View):
grok.context(App)
grok.name('index')
class MyViewletManager(ViewletManager):
# unless customized, this is a dead chicken
grok.context(MyView)
grok.name('center')
class MyViewlet1(Viewlet):
grok.viewletmanager(MyViewletManager)
order =10
def render(self):
return "<h2>viewlet 1</h2>"
class MyViewlet2(Viewlet):
grok.viewletmanager(MyViewletManager)
order = 20
def render(self):
return "<h2>viewlet 2</h2>"
app_templates/myview.pt
<span tal:replace="structure view/provider:center" />
output...
<h2>viewlet 1</h2><h2>viewlet2</h2>
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
needed.
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.
Kevin
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:
>
> http://thread.gmane.org/gmane.comp.web.zope.grok.devel/1749
> http://thread.gmane.org/gmane.comp.web.zope.grok.devel/1752
> http://thread.gmane.org/gmane.comp.web.zope.grok.devel/1781
>
> * Associating additional info to events (probably more of an Zope-3
> issue initially). See also:
>
> https://bugs.launchpad.net/zope3/+bug/98483
> http://jw.n--tree.net/irclogs/%23grok/%23grok.2007-09-04.log.html
>
> * 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:
>
> http://thread.gmane.org/gmane.comp.web.zope.grok.devel/885
>
> 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
> list.
>
> http://svn.zope.org/Products.CMFCore/trunk/Products/CMFCore/CatalogTool.py
>
>
> * Review, extend and merge the REST branch I did.
>
> Please add your sprint topics!
>
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>
More information about the Grok-dev
mailing list