Weblog

published Nov 03, 2021, last modified Nov 04, 2021

Grok sprint wrapup Sunday

published May 04, 2008

I will just briefly list what has been done.

  • Jasper and Reinout finished work on traversable stuff.
  • We have ordered containers.
  • Peter and Christian Klinger worked on caching response headers.
  • The grok.url method got cleaned up.
  • In grok.require you can point to a Permission class.
  • A lot got done for Relational Database integration with SQLAlchemy, without actually needing a lot of code.
  • We have a sample implementation for a BREAD/CRUD application; will be checked into the grokapps subversion section.
  • We worked on KSS integration.
  • We talked about resource directories and the static directory.
  • Peter made a sample application and tutorial about skins and layers.
  • Philipp released grokcore.component and merged the needed changes to core grok.
  • Wim made a mockup for the Grok homepage.
  • A lot of documentation was written. Automation is done using grokdocs.
  • z3c.testsetup/grok.testing was added by Uli.
  • "Zope 2 stuff" was worked on by Godefroid and Eric. So five.grok.
  • JW and Philipp worked on martian directives. Three merges need to happen, which we will work on now. Makes it easier to write new directives and easier to get information from directives. All existing third party grokkers will then not more work anymore; we feel it is still early enough to do this, but the merge should happen sooner rather than later.
  • Christian Theuni worked on the testrunner and the zodb.

A Grok Tour and Todo

published Apr 30, 2008

Welcome to the Grokkerdam sprint!

The Grokkerdam sprint has just started in Rotterdam. Martijn gave a big introduction to Grok, throwing in things that can be done in the Sprint, and with comments by the audience.

Some core Grok concepts

  • DRY: Don't repeat yourself. By not needing to add code to lots of files, you save time and errors.
  • Convention over configuration: sensible defaults. You can more easily look at other people's code and still understand where everything is.
  • We have "grokkers" that deduce declarations from python code. So hardly any zope 3 configuration (zcml) is necessary.

Grokking

Grokking is triggered from zcml, with the grok directive. This should be the only zcml that is needed. It scans modules in your code for classes that subclass grok's base classes. Grok then registers these components with the Zope Component Architecture (ZCA).

If you follow standard patterns, you can leave out grok directives (grok.name, grok.require, etc) from your code, but if you need more control, you can use them.

Storage

grok.Model is usually your base class. Very light weight. It should be contained in a class with grok.Container as base class. There is no ordered container class yet; we will add it to the todo list of the sprint.

Traversal

Traversal in Grok is very easy. There is of course the default traversal that just works. But if you need more control, you add a traverse method to your model. This can instantiate virtual objects on the fly.

You can also use grok.Traverser to implement custom behaviour for someone else's context.

Sites

Sites is Zope 3 is a place to store local utilities and tools. Grok has grok.Site for this. As todo we may want to add locally defined views and adapters. And having non-persistent local utilities would be useful as well. And we want to be able to install local utilities in an existing site, instead of only in a new site, without hairy upgrade code.

grok.Application is a special kind of grok.Site.

Todo: look at GenericSetup to make upgrades easier.

grok.Indexes makes working with the catalog easier. Todo: upgrading indexes in an existing site should be possible.

Components

grokcore.component has several components you can use, also in plain Zope 3:

  • grok.Adapter
  • grok.GlobalUtility for looking up e.g. the global email sending utility.
  • grok.MultiAdapter if you need to adapt more than just one context (for which you would use grok.Context. Not used a lot currently.
  • @grok.subscribe is a decorator for subscribing to zope 3 events

Todo: set up caching for views.

Miscellaneous other utilities

Using persistance:

  • grok.LocalUtility
  • grok.Annotation: you don't need to mess around with own generated keys anymore.

Views

  • grok.View: the most magic of the grok base classes, as we wanted to make this really simple. There is the url method which you can give some parameters (optional context and optional string for an alternative view). Todo: explore keyword arguments for these parameters. And explore improving flash messages (compare with Plone portal status message), which does not always show in combination with redirection.
  • grok.Skin: this is just a name and a single layer (grok.Layer) that is associated with it. grok.Layer is just an interface; you can use inheritance to combine layers. Todo: more skin based control of what views exist. From a security perspective it is not nice that anyone can just add e.g. @@contents and see the ZMI. We need to make that easy (grokking it).
  • grok.GrokTemplate: ugly name, needs more implementation. Some integration to use e.g. Genshi instead of Zope page templates. Todo: write Jinja (from Django) integration and other template languages.
  • grok.ViewletManager, grok.Viewlet: You register viewlets (html snippets) for a viewlet manager. In zope 3 you need to do quite a bit of stuff to set up viewlets and viewlet managers. Grok of course makes that easier. Having viewlets available at a specific url is good for caching; the Lovely guys have done something for this. Todo: look at z3c.traverser for maybe making that easier and default. KSS (or any Ajax) likes viewlets. Todo: viewlet documentation.

Alternative views

  • grok.XMLRPC
  • grok.REST
  • grok.RESTProtocol
  • grok.JSON

Security

Security is all view related.

  • grok.Permission is used to define permissions. The grok.require directive is used to require a permission. Todo: see if we can refer to classes instead of strings in grok.require.
  • Todo: default authentication UI. With Zope 2 you have the acl_users. With Grok we currently ask people to roll their own code. There is a good base in Zope 3 to use.
  • Todo: authorization APIs.
  • Todo: model-level security instead of only on views. You can give local permissions. But security checks are currently only be done on views. We threw the object checks out as it is a pain to work with, but we can look into making this easier. The zope security is very powerful.

Formlib

zope.formlib based forms.

  • Use grok.Form as base.
  • grok.EditForm uses the schema of your class. The standard template is pretty ugly though and does not integrate nicely with your UI. Todo: better templates for forms. Viewlets might be handy here.
  • grok.DisplayForm just displays stuff.
  • Todo: z3c.form support. Perfect candidate for making easier by grokking it.

That concludes the component tour.

What else?

Grok is more than just the API. It is a sort of language with base classes, decorators, methods. It is an attitude to be friendly to beginners.

We want smooth installation for Grok.

  • Goal: smooth installation for Grok and Grok applications.
  • We maintain a list of versions of libraries we use: pinned versions. That works for core Grok. But it did not work for megrok.form recently. Todo: update to the Zope 3 KGS list of versions (from Stephan Richter). All tests in the KGS pass; with the Grok version list the Grok tests pass, but the other tests did not all pass. That is not good.
  • Todo: downloads sometimes fail. Sourceforge sometimes moves stuff around, the cheeseshop can be down, zope.org can be down. Todo: look at zc.sourcerelease to make one tarball of Grok.
  • Todo: version pinning for extensions. buildout.cfg may or may not be better than setup.py for this.

Relation database integration

  • This should be a first-class citizen in the zope world.
  • Todo: figure out default story for RDB integration. This can be a big discussion/fight about what we choose.
  • Todo: auto generation of Zope 3 schemas from database table schemas. Often you will find you are repeating yourself here.
  • Todo: Model and Container base classes for RDB. So these would not have persistence as they are not stored in the ZODB.
  • Todo: patterns for security integration. You need a bit too much methods currently.
  • Todo: obviously add documentation.

WSGI

Web Services Gateway Integration. We have code for this, but we need to make this easier; possibly put it in grokproject by default.

  • Todo: check the differences between grokproject and zopeproject; there should not be much differences.
  • Todo: make grokproject really available as a paster template. It can be done already, but we need to document this.
  • Todo: put in a few useful WSGI components for development. Look at repoze too.
  • Todo: development and deployment profile.

AJAX

  • Todo: finalize KSS integration.

Resources

  • Todo: consider what is the right way for Grok to do this.
  • Todo: think about making it possible to overwrite static resources in extensions.

Introspector

  • Uli has done work here and will be working on it for Google Summer of Code.
  • Todo: improve the object browser UI. Show which defaults are used for directives that are not explicitly in the code. In Firebug you can see the calculated style; something like that would be useful.
  • Todo: new directive implementation in Martian. grok.name has different defaults depending on where it is called. We can make that more explicit, guard against unforeseen uses.

Miscellaneous

  • Back to the future: through the web (TTW) development. This made Zope 2 popular. We can look at five.customerize for overriding views. Defining a schema TTW would be cool, if we can avoid the problems from ZClasses.
  • Make CRUD UIs TTW.

Documentation

  • We have the beginner's tutorial. It gets you started, but it can be longer. This is maintained in subversion. For other documentation: just add it to the website and publish it.
  • We have developer's notes in subversion.
  • Todo: The Reference.
  • Todo: website improvements. I could not update the link and text in the sidebar. This was hardcoded. Kevin Teague has done a lot of work here, but we need more people here.

Rule: a sprint project is not finished without documentation!

First impressions of Ubuntu Hardy Heron

published Apr 26, 2008, last modified Apr 27, 2008

No big issues, but watch out for not yet compatible Firefox extensions.

A new Ubuntu Linux was released on 21 April. It is version 8.04, with codename Hardy Heron. So I upgraded my home desktop machine. Emacs still works and mutt still works so I am happy. ;-) For me there were two snags until now:

  • I want the Caps Lock key to behave as an extra Control key. This worked before and it still works, but now when I press the Caps Lock key the light indicating that Caps Lock is on starts or stops shining, even though I only really use it as a Control key. See this bug report, which also mentions some remedies. I ended up adding some lines to my ~/.bashrc file:

    xmodmap | grep lock | grep Caps_Lock > /dev/null
if test $? -eq 0; then
    xmodmap -e "remove Lock = Caps_Lock" -e "keysym Caps_Lock = Control_L" -e "add Control = Control_L"
fi

  • Firefox 3.0b5 is used. There are not yet versions of Firebug and Live HTTP Headers that are compatible with this. That is not good when you are doing web development. I expect that this will get fixed soon.

In light of that last issue I think I will keep the laptop from my work at the previous Ubuntu for a while until those extensions are available.

Update: Both Wichert Akkerman and Jeroen Vloothuis tell me that there is a Firebug 1.1 beta that works with the new Firefox. This was not automatically found when Firefox looked for updates. This version indeed works, though for me it only works when opening Firebug in a new Window.

All in all a big thank you to everyone who made another Ubuntu version happen!

Missing files from eggs

published Jan 30, 2008, last modified Jan 31, 2008

That egg you just build might be missing some files. Check that egg! Update: I received some pointers for more info.

Today I discovered that an egg I just made for a package was missing some files. Most noticeable was the missing of some zcml files.

It turns out that when you do an svn export and then a python2.4 setup.py bdist_egg to create your egg, you are missing some files. At least I was. When you do an svn checkout and then make your egg, all files are there.

In neither case was any zcml file mentioned in the SOURCES.txt file in the automatically created egg-info directory.

For the tar ball created by a python2.4 setup.py sdist I did not notice any difference.

Does anyone know what is going on here and how to solve this so it works from an svn export too?

Cooking lesson for today: check that egg!

Oh, and sorry for spamming http://planet.plone.org today. I changed the language of a lot of weblog entries from neutral into English. Now they all needlessly show up on that home page.

Update

Daniel Nouri pointed me to the setuptools docs that explain what is going on; plus the docs for disutils, especially the part about adding a manifest file. And Andreas Zeidler pointed to a thread on the Plone developers list. And Florian Schulze pointed me to both. :-) I have the feeling there are a few people reading this weblog. :-) Thanks everyone!

In my case the tar ball problems pointed out by Florian did not affect me. In fact, when I uploaded just the tar ball and tried to easy_install it, this went fine: an egg was automatically created from the tar ball. But it is good to know that there can be problems in that area too.

Conclusion for me: easiest is just to create and upload an egg from a subversion checkout, not from an export. And if you want more control, read those setuptools docs.

Skin switching with pre-traversal

published Jan 30, 2008, last modified Aug 02, 2008

collective.skinswitcher uses a pre-traversal hook now instead of an access rule.

For collective.editskinswitcher David Convent gave me the idea to get rid of the Access Rule and use a pre-traversal hook instead. That turned out to be pretty easy to do. This looks far cleaner to me. So collective.editskinswitcher is now available as version 0.3. Thanks for the idea David!

It now has an own Product page on plone.org too. Not much is there yet. For downloads just use the cheese shop. If you are using it, drop me a note: it would be nice to know.

Let me show some code. We subscribe to an event in configure.zcml:

And in traversal.py you then have this code:

def switch_skin(object, event):
    """Switch to the Plone Default skin when we are editing.
    """
    context = object
    request = event.request
    portal_props = getToolByName(context, 'portal_properties')
    editskin_props = portal_props.get('editskin_switcher')
    edit_skin = editskin_props.getProperty('edit_skin', '')
    ...
    context.changeSkin(edit_skin, request)

Well, the code is slightly longer, but this should give you an idea. Except for details this is the same code as was in the External Method, which is now gone.

All in all, for this change one file was added: traversal.py. And various files could be removed, mainly: Extensions/* and setuphandlers.py.

More importantly: if you now remove this package from your zope instance without properly uninstalling it, you are not left with an ExternalMethod in your Plone Site that gives errors because the file is not available anymore.

BTW, if you are using this package already, it is best to uninstall version 0.2 and then install version 0.3; that way the quick installer will take care of removing that external method with the access rule for you.