This is really great! We badly need someone to own this and sort it out, and I think you’re the right man for the job.

I’ve got a few comments/suggestions below. We may want to move the discussion to plone-dev if it requires more input as well.

I think there’s an important thing missing from the ‘why Zope 3 resources’ argument: A portal_skins page template is a standalone template. It is not tied to a backing Python class where ‘view logic’ lives. In this past, this led to some pretty dodgy practices, where people would either try to do far too much with python: TAL expressions, or where we had code spread around skin layer python scripts that again were all part of one gigantic namespace.

The one-namespace, template-only portal_skins programming model doesn’t scale well (TTW security causing it to be slower doesn’t help either). Thus, we have adopted views in a big way. The challenge now is bringing some of the good things about the portal_skins UI/integrator experience to Zope 3 resources.

I’m not 100% sure we need yet another way of configuring views. We need to unify this with z3c.jbot, five.grok, and the ZCML way of registering views. Personally, I think the five.grok approach is most worthy of exploration, because it is something used elsewhere (in Grok itself, via grokcore.view). That said, it’d need to be updated to work without any Python at all, since the grokkers looks a python files to find registrations.

I’m not sure we need both .metadata files and tags in templates. Even if tags are cool, I’m a bit dubious about having yet more ways of doing the same thing.

And if we have a per-template .metadata file, that’s not very far away from a single XML file with a .zcml extension… still, I’ve seen ZCML files get very complex and messy, so forcing some structure and dealing with small files is probably a good idea.

Personally, I don’t see why people get so worked up about ++resource++ in the URL. People will never see that in their URL bar, only in generated links. Having a unique namespace is useful. What do you do when you put an ‘images’ folder in Plone?

I agree with Hanno, by the way - I’d rather we used simple, non-CMF classes, and forgot about skin layer python scripts and CMFFormController. This will be easier to maintain, less magical, and less prone to abuse.

As for plone.browserlayer changes, note that plone.theme and plone.browserlayer are built so that plone.theme layers take precedence. I think instead of creating the concept of a’ theme’ layer in plone.browserlayer, you should just use the support already in plone.theme. plone.theme could certainly be improved, as well.

Martin