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

by Erik Rose
— 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...

Posted by Anonymous User at Jul 22, 2008 03:16 AM

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

Posted by Anonymous User at Jul 22, 2008 10:26 AM

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:

News & views…
Posted Oct 13, 2009 Portlets gone wild with ContentWellPortlets 2.0.1 This new release adds the ability to add portlets to the footer area. It also has 6 portlet managers per area. This means 20 total portlet managers including the 2 on the sides that ship with plone.
Posted Sep 17, 2009 Plone 4 – An interview with Zope News Jan Ulrich Hasecke interviews me for Zope News.
Posted Aug 31, 2009 Web Services API for Plone Alpha 3 Release Details the release of the wsapi4plone.core package and the plans for future releases. The final report of the AtomPub for Plone Google Summer of Code project.
Posted Aug 28, 2009 Content editing and creation in Plone is faster with archetypes.schematuning Some bench marks of content editing and creation in Plone with and without archetypes.schematuning installed.
More news & views…