[Grok-dev] grok mini-sprint progress

[Martijn Faassen]

Hi there,

Yesterday and today we're having a mini-sprint at the offices of the 
Health Agency in Rotterdam. It's just me, Jan-Wijbrand Kolman, Sylvain 
Viollon and Jan-Jaap Driessen. I'm writing this so that people who 
aren't at the sprint have some idea of what is going on and where we 
think Grok should be going.

What we are doing is to try to devise a way to make Grok work on top of 
as few zope.app.* packages as possible.

The zope.app.* packages that we'll need to keep for now (or extract 
from) are:

zope.app.appsetup

This sets up the database, puts a root object in there, sets up 
sessioning, etc.

zope.app.publication

This hooks up the actual publishing so that requests can be created and 
handled.

zope.app.wsgi

This is a WSGI frontend to the publisher. It is needed to make our 
paster integration in grokcore.startup works.

We have a few packages that are particularly difficult to get rid of:

zope.app.testing

Tests in the above packages and grokcore.* packages depend on this. This 
package itself depends on lots of stuff.

zope.app.zcmlfiles

This package also depends on a lot of stuff, and loads tons of ZCML.

We believe that if we can cut the links on these two packages, we'll end 
up with a pretty minimal configuration.

Here's a rough plan for how to do that:

zope.app.testing:

This provides two major features:

* functional test setup

* browser test setup so zope.testbrowser can be used

We want to make the functional test setup work differently and based on 
clean zope.testrunner layers. In a zope.* package, we'd have a test 
layer that could be imported from it, that if used in a test, sets up a 
functional test for this package.

So, if you'd wanted to test against a fully set up database, you'd 
import the test layer from zope.app.appsetup, and if you'd want to test 
against just a set up component architecture, you'd use zope.component's 
test layer. The test layers should build on each other.

Finally if you want to do a browser set, you'd use the test layer from 
zope.app.wsgi. We've been doing work to let zope.testbrowser talk to 
WSGI instead of to zope.app.testing, and zope.app.wsgi can provide this.

zope.app.zcmlfiles

We need to cut the dependency on zope.app.zcmlfiles in all packages. We 
experimentally tried this in grokcore.view. It turns out that if we 
include enough package's ZCML by hand, it works. It's a long list of 
includes, however.

We ran into a philosophical issue. We use browser tests to test 
grokcore.view's functionality. This however tests too much. 
grokcore.view's task is to *register* views correctly with the component 
architecture. The tests should only test whether those registrations are 
correct. This can be done by browser tests, but that also tests whether 
the whole publication process works. But grokcore.view doesn't really 
need to depend on the publication process.

We believe that grokcore.view's tests should only test the 
registrations. Browser tests are therefore shouldn't be part of 
grokcore.view. But we also recognize that such tests are probably more 
readable and writable than registration tests. It would be nice to have 
a clean API (NOT zope.app.testing.ztapi, which is terrible) to check 
such registrations. And the API to actually look up the registrations 
should ideally be used by the query as well. The idea is that any 
component registration pattern should have a higher level registration 
and lookup API. And if we take the browser tests out, we might want to 
move them elsewhere, but where? Grok itself?

Regards,

Martijn