[Zope-dev] EMarket and 2.2.0b3

[R. David Murray]

On Thu, 29 Jun 2000, Steve Spicklemire wrote:
> I'm sure a lot of this is because EMarket was a 1.x product that has
> seen relatively little change, in basic structure, since. I'm working

It doesn't look that way, actually.

> on some patched to allow (1) ZClasses to act as MarketItems and
> Shoppers and (2) ZPatterns integration so that most objects can
> be optionally stored in RDBM or ZODB. .. I'll go ahead and 
> checkin my ZClass stuff. I'm not running 2.2x much, since I'm

This would be really great, thanks.

> really busy on other development... but I can at least
> see if the product installs! ;-)

I figured out a way to fix the problem I was seeing, but I don't really
understand why it caused the problem, though it does not seem unreasonable
that it did (which is why I thought to experiment in this area of the
code).

MarketItem.py has the following code snippet near the beginning of
the class definition:

    for item in OFS.Folder.Folder.manage_options:
        if item['label'] == 'Contents':
            manage_options.append(copy(item))  # be sure to muck with a *copy*
            manage_options[-1]['action'] = 'manage_contents'
        else:
            manage_options.append(item)

Changing the last line to

            manage_options.append(copy(item))

makes the management interface behave normally with the product installed.

It does not seem unreasonable to me to not make copies of things not
being changed: why clutter up memory with copies?  But clearly there are
unexpected interactions later because of this, interactions that
produce obvious strange behavior in 2.2.0 but seem to work fine in 2.1.x.
I don't know if this has any security implications someone from DC should
look at, but it's probably worth a note in the product author's security
guide.

I also have no idea whether or not the similar eTailor problem has a
similar cause and solution.

--RDM