Skip to content. | Skip to navigation

Sections
Personal tools
You are here: Home → News & views → FreakyWiki: a simple wiki banged out in Grok

Posted Jul 21, 2008

FreakyWiki: a simple wiki banged out in Grok

— filed under: ,

A restructured text wiki written in about a day by two guys who never used Grok (or even pure Zope 3) before

Last week’s Zope 3 training was actually more of a Grok training, which I dug, since I don't care to expose humans (myself included) to XML. Grok’s a nice piece of kit—it really does get rid of practically all ZCML—and Zope 3 is ever so much cleaner to develop in than the legacy-bound Zope 2 hairball I’m used to.

To get our feet wet with a somewhat real-world problem, Eric Steele and I spent the last day of class whipping up a simple wiki we called FreakyWiki. It demonstrates a nice cross-section of Zope 3 and Grok in about 200 lines of code:

  • Skinning
  • Event subscription
  • Custom traversers
  • Formlib
  • Indexing and search

Take a look

Once you get FreakyWiki running, just write your pages in standard restructed text, and spell your wiki links LikeThis_ (with the trailing underscore, in true ReST fashion).

This is, of course, an extremely early release, but gentle feedback is welcome!

Document Actions

the purpose of...

...the update-method (re: page.py) is not to prepare data that will only ever get used once, e.g. ``rendered_content``, but rather to provide a chance to peek or poke at the rendering environment before any page element gets rendered.

I think it causes less confusion to simply have a method ``get_rendered_content`` and call it straight from the template.

\malthe

I disagree

The purpose of the update() method on a Grok view is exactly preparing stuff for the template. That's how we've been advertising this method in Grok and I think it makes sense that way. Because with it you can write templates that are push-like: You prepare data in the update() method, push it onto the view class and then just use it from the template.

I don't see the advantage of writing abitrary methods on the view class (and thereby introducing some custom interface of how to talk to the view code).

I'm not disagreeing with the fact that update() could be used to implement more, for instance form handling, updating database objects, or take a peek at the environment. I'm just saying it's nice to have one well-documented entry-point for view code. And I like "push" for templates rather than "pull" and the update() method together with view attributes are a neat way to get there, I think.

-- philiKON
Need help now?

Immediate assistance is available during university work hours: