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