> I really would like to reuse the simpler directives as much as possible
> which is why I'm trying to mention <view />. Perhaps we'll have to end
> up using <browser:view /> because of the layer problem I mention. In
> analogy, perhaps the browser:pages directive should be named
> browser:views so that we can ditch the "page" nomenclature once and for all.
> "...what gets viewed and for what request as well as the names of the
> actual browser pages, are intrinsic to the implementation. Why are
> the page names intrinsic? Because the different method refer to each
> other in URLs, form handlers and redirect calls."
But that's no more intrinsic than any other naming. So again, either
all naming should be in python, or all in ZCML. And I think it should
be in ZCML, if for no other reason ten that the @-syntax reminds me
way to much about security.declareProtected shims and I don't like it.
To me it feel like you are trying to force non-code into the code. So
then, why not have it in the ZCML? We need to have the ZCML-statements
Besides, somebody might like to override a page but keep the old page
under a new name (although admittedly that would be unusual).
> >> Naaaah. I don't like this, but I can't tell you why. Maybe just
> >> because it's too complicated.
> It's not my invention. It's in zope.formlib and it's being used, whether
> you like it or not :).
To be clear here, what I'm unsure about is getting rid of the
automated class generation in the case of page templates with no
> > What's the difference between boiler plate class and boiler plate ZCML?
In this case, the difference is that you have to do it twice. ;-)
Having these "empty" boilerplate viewclasses does not get rid of the
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
Zope3-dev mailing list