Jeff Shell wrote at 2006-3-15 14:26 -0700:
>Anyways, I don't mind if someone wants 'browser:addform' as an add-on.
>But I don't think those things belong in the core. If someone wants to
>make a package that lets them "build a web site using nothing but ZCML
>to glue a bunch of crap together!" then lets have it. But not in the
>core. It's limiting. It's restrictive. The bit that it makes hard is
>the bit that most people get to at some point in the lifecycle of
>their web application. Why make them switch paradigms at that point?
Maybe, because until that point it made life easier?
I am very happy to use high level abstractions (provided
they have well chosen names -- "browser.addform" seems quite
good -- and a clear semantics) and start only to dig deeper when
I treat a car as a black box with a well defined set
of functions. Only when I reach the limits, I search
deeper and may learn that there is a motor that can be tuned...
>That makes the integrators job much harder. If browser:view,
>browser:page, and zope:view all went away today in favor of
>subclassing from formlib.Page, BrowserView, or something else common
>that provided the core full-view-page pieces (publishTraverse,
>browserDefault, __call__) and only zope:adapter was used as the ZCML
>directive, it would be much easier (I think) to start providing views
>that can be better augmented by integrators. (Besides, I think
>'integrators' are better served by the programming language. Anyone
>who thinks they can just download a bunch of random components and
>build a unique web site with nothing but XML is deluding themselves).
Things I agree with...
Zope3-dev mailing list