Grok News and Blog

Grok 1.4 released!

jw — 2011-04-04T15:27:45Z

Grok 1.4 is a feature release of Grok based on the Zope Toolkit 1.1.1.

The Grok development team is happy to announce the Grok 1.4 release!

This release brings several new features and bugfixes.

The list of Grok specific package version can be found here:

http://grok.zope.org/releaseinfo/1.4/versions.cfg

To upgrade existing project you might find the upgrade notes helpful, to be found here:

http://grok.zope.org/doc/1.4/upgrade.html

Amongst other changes, Grok 1.4 brings:

New features in grokcore.view like allowing for the use of the grok.provides() directive in view components, the addition of a grok:ignoreTemplates ZCML directive to configure what template filename extensions are to be ignore when reporting unassociated templates, improved reporting of unassociated templates and improved grok.template() directive inheritance.

New Subscriptions and MultiSubscriptions components from grokcore.component

Includes the latest zope.testbrowser version that is based on WebOb and WebTest.

Besides working on code, the Grok community is also working on improving the documentation, both the "official" documentation and the "community"-driven efforts. This is quite an undertaking and not yet finished.

Grok 1.3 released!

jw — 2011-01-20T21:36:49Z

Grok 1.3 is a feature release of Grok based on the Zope Toolkit 1.1c1.

The Grok development team is happy to announce the Grok 1.3 release!

Where the previous release was mostly about slimming down the dependency hierarchy of packages that comprises Grok, this release brings several important changes in functionality typically found Grok-based applications.

Grok 1.3 is based on the Zope Toolkit 1.1c1 release!

Since the ZTK 1.1 release drops Python-2.4 support and gains Python 2.7 support, it was able to update quite a number of packages, most notably the ZODB. Grok does currently not need to override any version of packages defined in the ZTK!

The list of Grok specific package version can be found here:

http://grok.zope.org/releaseinfo/1.3/versions.cfg

To upgrade existing project you might find the upgrade notes helpful, to be found here:

http://grok.zope.org/doc/1.3/upgrade.html

Amongst other changes, Grok 1.3 brings:

The long awaited support for the most recent martian version.

The long awaited merge of the template registry refactoring. This should result in considerable less spurious warnings concerning unassociated templates.

Integration of the Fanstatic library and WSGI components. From the Fanstatic website:

""" Fanstatic is a small but powerful framework for the automatic publication of resources on a web page. Think Javascript and CSS. It just serves static content, but it does it really well. """

The "static" directory functionality in Grok based projects is now based on Fanstatic and the compatibility layer provided by zope.fanstatic.

Removal of the automatic test discovery and registration that was provided by the z3c.testsetup package. For newly created projects, the grokproject tool will layout examples of setting up test suites. Note that this is a first step in the way towards more drastic improvements in regards to test discovery and running tests.

Other important notes:

The updated grokproject tool will not be able to build new project based on Grok version < 1.3.

Besides working on code, the Grok community is also working on improving the documentation, both the "official" documentation and the "community"-driven efforts. This is quite an undertaking and not yet finished.

We realize this release will again bring quite some structural changes that might affect your projects in some way. Please let us know when you run into problems upgrading your projects on the grok-dev mailinglist or on the #grok IRC channel. We will try to help and it will also help us, the Grok developers, by fixing bugs and other issues.

Grok 1.2 released!

jw — 2010-10-26T19:30:10Z

Grok 1.2 is a feature release of Grok based on the Zope Toolkit 1.0, zc.buildout-1.5.2. A very large number of zope.app.* dependencies have been removed to have a smaller, more manageable footprint.

This release took a huge effort from the Grok development team to reduce the number of (legacy) dependencies, most importantly removing a very large number of zope.app.* packages from the stack! This results in a smaller and more manageable footprint.

The Grok (Toolkit) 1.2 uses zc.buildout-1.5.2 and the new features it brings. Most importantly, the possibility to safely use the system Python for creating new projects. This should especially help newcomers who want to try out Grok. We can simplify the installation instructions by leaving out the "virtualenv" steps.

The Grok (Toolkit) 1.2 is based on the Zope Toolkit 1.0 release!

The Grok (Toolkit) does diverge a little from the ZTK 1.0 for a couple of its dependencies. These are listed separately in the Grok Toolkit versions file that can be found here:

http://grok.zope.org/releaseinfo/1.2/versions.cfg

The list of changes can be found here:

http://grok.zope.org/doc/1.2.1/changes.html

To upgrade existing project you might find the upgrade notes helpful, to be found here:

http://grok.zope.org/doc/1.2.1/upgrade.html

The 1.2 release will __not__ bring two still long awaited changes:

Support for the latest martian version.
The improved template registry merge.

They will have to wait for the 1.3 release.

Another important note:

Because of the update to zc.buildout-1.5.2 and other structural changes, the new grokproject version will not be able to install projects for Grok < 1.2.

We realize this release will bring quite some structural changes that might affect your projects in some way. Please let us know when you run into problems upgrading your projects on the grok-dev mailinglist or on the #grok IRC channel. We will try to help and it will also help us, the Grok developers, by fixing bugs and other issues.

Grok 1.1 released!

faassen — 2010-05-18T19:09:08Z

Grok 1.1 is a feature release of Grok preparing for the Zope Toolkit.

The major user visible changes are Python 2.6 support and new version of the Grok UI. The main changes in Grok 1.1 are under the hood: now Grok builds on a prerelease version of the Zope Toolkit.

Grok 1.1 should be compatible with Grok 1.0. Grok 1.1 lets you prepare for the upcoming Grok 1.2 release by updating your imports.

For more information about this release, see the release info:

http://grok.zope.org/project/releases/1.1

Book on Web Development with Grok Published

cguardia — 2010-03-24T16:08:01Z

Packt Publishing just made available the first book on Grok development, by Carlos de la Guardia.

The Grok book from Packt Publishing has just been made available for sale at their site:

http://www.packtpub.com/grok-1-0-web-development/book

The book is intended for developers more or less familiar with the concepts of web applications who want to write their applications using the Python programming language. No familiarity with Zope is assumed from the start. The approach is practical, focusing on getting working code right from the beginning.

The foreword is by Philipp von Weitershausen, Author of Web component Development with Zope 3 and an early Grok contributor. He made a blog post out of it, which can be read at his site.

Reviews on the Web :

Spotlight on: megrok.traject

cguardia — 2010-02-10T05:30:10Z

megrok.traject is a package that allows a different way to publish your models than the traversal that is most commonly used in Zope applications. By Martijn Faassen.

megrok.traject is a package that allows a different way to publish your models than the traversal that is most commonly used in Zope applications. With megrok.traject you can define explicitly what kind of URLs you want to publish your models on, instead of having to construct an object hierarchy.

A model can be anything that you want to have views for, and doesn't need to be a persistent grok.Model. In fact megrok.traject is most suitable for objects that are not stored in the ZODB, as the ZODB makes traversal easy.

What kind of models could you publish with megrok.traject then? It could be just Python objects you design yourself. In this case you can use traject.Model. You tell it under what URL pattern it should appear and how it is to be constructed, and you're done. traject.Model is very lightweight: it's just a grok.Context that can be hooked up by a "traject pattern".

Alternatively you may want to treat your models even more lightly: you may wish to hook up models that are defined by a package that is not under your control at all. You could have for instance an ORM such as SQAlchemy define the models in an entirely different package that knows nothing about how these models should be presented on the web in your application. You can then use traject.Traject to associate such models with a URL pattern in your application.

You can look at the megrok.traject documentation for more information:

http://pypi.python.org/pypi/megrok.traject

The low-level implementation is a reusable library called traject, and its documentation can give you more details:

http://pypi.python.org/pypi/traject

If you still don't understand why megrok.traject would be useful for you, don't worry. Grok's traversal method of publishing objects isn't going anywhere, and megrok.traject is just an option. If you have questions, we'd very much like to hear them on grok-dev however, so that we can improve megrok.traject and its documentation.

Volunteers who would want to write a tutorial oriented towards beginners that uses megrok.traject would also be very welcome!

Spotlight on: dolmen.content

cguardia — 2010-02-09T06:22:00Z

The package `dolmen.content` is a convenient way to define content types. Written by Souheil CHELFOUH.

This spotlight is about dolmen.content, which is the first package I wrote for Grok and the Dolmen project. It first was a Plone package, using five, and five.grok, and it was called "spear.content" (in 2007). I refactored it partially, while I stopped Ploning and first started the Dolmen project (ex-spear) It's used outside of the Dolmen project in another Grok project called uvcsite, coded by Christian Klinger.

dolmen.content

The package dolmen.content is a convenient way to define content types. Content types usually have several attributes : a type, a schema, an icon. In addition, they need security to control the creation, pages to edit them, easy ways to control the display, and the widgets. This is what provides dolmen.content, with an easy-to-use set of grok directives.

Example

A dolmen.content content is declared as a simple class. Some directives are available to define your content: name, icon, schema and factory. To have detailed information about these directives, please have a look at the package tests.

Defining the content

Let's demonstrate the package's features with a simple and non-exhaustive test:

>>> import dolmen.content
>>> from zope import schema

>>> class IContentSchema(dolmen.content.IBaseContent):
...    text = schema.Text(title=u"A body text", default=u"N/A")

>>> class MyContent(dolmen.content.Content):
...  """A very simple content
...  """
...  dolmen.content.schema(IContentSchema)
...  dolmen.content.name("a simple content type")

Schema

The content can now be instanciated. As we can see here, the object is effectively providing the schema, even without grokking:

>>> MyContent.text
<zope.schema.fieldproperty.FieldProperty object at ...>

>>> IContentSchema.implementedBy(MyContent)
True

>>> obj = MyContent()
>>> obj.text
u'N/A'

Grokking

We now let Grok register our component:

>>> from grokcore.component import testing
>>> testing.grok_component('mycontent', MyContent)
True

Factory

When the content is registered, a factory is registered, using the full module and class dotted names. It allows us to query and instanciate the content easily:

>>> from zope.component import getUtility
>>> factory = getUtility(dolmen.content.IFactory,
...                      name="dolmen.content.MyContent")
>>> factory
<dolmen.content.factoring.Factory object at ...>

Foot notes for the grokkers out there

If you thought that Spotlight was too much code, or not detailed enough, please let me know I'll try to cover most of the interesting packages I released lately. Please note, also, that dolmen.content is currenty under heavy surgery. At the moment, the schema fields boostrap is done by a grokker. I decided to drop this and use a zope.interface ClassAdvisor, to allow very straightforward bootstrapping, even on non grokked objects. Also, the 'icon' directive should disapear, soon, if I can get a decent release of megrok.icon (another package I need to work on !)

Spotlight on: z3c.recipe.usercrontab

cguardia — 2010-02-09T06:23:50Z

z3c.recipe.usercrontab is a zc.buildout recipe. With this recipe you can define crontab rules that will be installed in the user's crontab. Written by Jan-Wijbrand Kolman.

z3c.recipe.usercrontab is a zc.buildout recipe. With this recipe you can define crontab rules that will be installed in the user's crontab. As such it is probably only useful on unix-like systems. It has been tested on Linux and Mac OS X.

With this recipe it is easy to define recurring actions related to the deployment of your application. Examples are: periodically checking the event log file for irregularities, sending emails from a mail queue, or have cron start your application after a system reboot.

The usercrontab part in your buildout.cfg file could look like this:

[buildout]
...
parts = ...
        logcheck
        reboot

[logcheck]
recipe = z3c.recipe.usercrontab
times = 39 * * * *
command = [cmd]

[reboot]
recipe = z3c.recipe.usercrontab
times = @reboot
command = ${buildout:directory}/bin/zopectl start

After running ./bin/buildout you can inspect the result of the recipe with:

$ crontab -l

There you will see something like:

# Generated by /home/jw/projects/sandbox/usercrontab [logcheck]
39 * * * *    /home/jw/projects/sandbox/usercrontab/bin/[cmd]
# END /home/jw/projects/sandbox/usercrontab [logcheck]

# Generated by /home/jw/projects/sandbox/usercrontab [reboot]
@reboot       /home/jw/projects/sandbox/usercrontab/bin/zopectl start
# END /home/jw/projects/sandbox/usercrontab [reboot]

The markers around the actual crontab line are important: z3c.recipe.usercrontab will use this markers to see if the buildout part already did its work in order to prevent duplicates. The markers are also used to remove these lines from the crontab, when uninstalling the part.

The Python Package Index page for z3c.recipe.usercrontab explain the use of the times and command directives in more detail.

Grok 1.1a1 released!

faassen — 2009-11-17T20:56:10Z

The Grok team is happy to announce the release of Grok 1.a1!

For more information see the release notes.

Grok 1.1a2 released!

faassen — 2009-12-22T22:37:40Z

The Grok team is happy to announce the release of Grok 1.a2!

For more information see the release notes.

Grok 1.0 released!

faassen — 2009-10-07T19:52:57Z

The Grok team is happy to announce the release of Grok 1.0!

For more information see the release notes.

Grok 1.0b2 released!

faassen — 2009-09-17T17:21:08Z

The Grok team is happy to announce the release of Grok 1.0b2. We should be close to Grok 1.0 now.

For more information see the release notes.

Grok 1.0a3 released!

jw — 2009-04-10T20:25:55Z

The Grok team is happy to announce the release of Grok 1.0a3. This is the second step on the way to the release of Grok 1.0!

For more information see the release notes.

Grok 1.0a4 released!

jw — 2009-05-21T20:41:10Z

The Grok team is happy to announce the release of Grok 1.0a4. This is the fourth step on the way to the release of Grok 1.0!

For more information see the release notes.

Grok 1.0a2 released!

jw — 2009-04-08T19:52:50Z

The Grok team is happy to announce the release of Grok 1.0a2. This is the second step on the way to the release of Grok 1.0!

For more information see the release notes.