ZopeFind susceptible to acquiring builtin names through Acquisition

[dataflake]

ZopeFind content searches fail if certain built-in names are shadowed by ZODB content. In my particular case there are Page Templates named list in the folder structure.

This only affects attempts to search for substrings inside content ("Containing:" search). The list object is called and thus an attempt to render it is made, which fails because it doesn't have the normal web request context. So for some reason ZopeFind acquires list in preference over the builtin name.

[dataflake]

After looking at it closer, it's not ZopeFind that has the issue, it's the template at OFS/dtml/findForm. There are a couple places when it tries to coerce a submitted form value to a list. This happens inside a DTML expression. The list being picked up here is the ZODB object named list, because the client object's acquisition chain is used to look it up.

Something must have changed in the DTML namespace lookup between Zope 2 and Zope 4. This was not an issue under Zope 2.13.

The "best" fix would be to convert the DTML template to a Page Template. The easiest fix would be to just forego those list coercions completely.

[icemac]

Yes there are changes between Zope 2 and 4 regarding the namespace lookup. The Python and C implementations in Zope 2 did not behave equally and there have been some tickets before showing such differences. But they are hard to debug. Maybe in short term it is easier to convert the view to a PageTemplate.

[dataflake]

I have actually spent several hours on that yesterday but had to give up. tal:repeat in conjunction with ZTUtils.Batch is missing a ton of functionality compared to dtml-in. Especially the sorting was impossible to do inside the template itself. In the end a ZPT version would have to lose too many features.

I'll try to come up with a workaround in the DTML template instead.