Chris Withers wrote:
Philipp von Weitershausen wrote:
Practically, it will very rarely hinder you to add attributes (such as
"locale") to the request.
I think "locale" and "debug" are just common enough to be form variables.
Funny, I've never used either in 6 years of zoping ;-)
Me neither, but are we prepared to break the apps of the people who do?
(Btw, just thought of another one possible name clash: 'response')
You'd be surprised (I was too). Plus, TALES path expressions first try
attribute access, then item access.
ZPT sux ;-)
TALES path expression sux (for various reasons).
Sure, but it's a BBB foul. It's not *me* who has the legacy code, so I
wouldn't mind. But I'm sure others would.
I thought adapters were for this exact kind of thing?
Existing Zoep 2 code would use a Zope 2 request, the Zope 3 components
should be presented with a Zope 2 request that has been adapted to
present IBrowserRequest rather than just being marked as implementing
it, no?
This would have been a possible solution at the time, but it wasn't
chosen. Neither the people who introduced IBrowserRequest to Zope 2 nor
I who pretty much took on Five maintenance afterwards realized this
problem back then.
I've thought about introducing the adaption approach now. I think we'd
be opening a can of worms since the request objects are likely to be
passed from old style code to new style code and vice versa.
Perhaps. A configuration option (that would usually be turned to 'off')
What do you mean by "off" here? The config option should make the stfuf
that ships (like the widgets!) work by default...
I'll repeat this again: Just because Zope 3 libraries ship with Zope 2
doesn't mean that everything from the 'zope' namespace has to work. Five
has never made that promise.
That said, *if* we choose to go with such a configuration option, I
think it woudl probably be a good idea to have it disabled by default in
the first release and enabled in subsequent releases. That way
applications could opt in for the new behaviour earlier than necessary
(much like Python's __future__ imports).
Philipp
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )