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 necessary. 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... -- Dieter _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com