Question

我正在开发collective.imagetags的新版本，其中浏览器视图（imagetags-manage）所带来的所有功能现在都被移动到新的适配器（尚未提交），该适配器提供几乎与浏览器视图::

相同的界面

class IManageTags(Interface):
    """
    imagetags-manage view interface
    Tag management browser view
    """

    def get_tag(id, create_on_fail=True):
        """ Gets / creates a specific tag """

    def get_tags():
        """ Gets all the tags for the object """

    def get_sorted_tags():
        """ Sorted list of tags
        """

    def save_tag(data):
        """ Saves a tag with the passed data """

我真的不知道是否有人在项目中使用此产品，但是，我认为提供一些向后兼容机制是一个明智的想法，以防任何人使用外部的浏览器视图方法 - 盒子功能。

我该怎么办？使用在新适配器上中继的存根方法保持浏览器视图的界面？有什么建议吗？

Answer 1

这种变化相当困难！这不是API的问题，而是设计的问题。

浏览器视图是将使用/请求与上下文混合的组件。
适配器是您无需关心用户或其请求的组件。
实用程序是您不关心上下文的组件。

因此，您应该保留浏览器视图并使其使用适配器，这应该足以保持兼容性。

当您更改默认配置文件时，将使用升级。首先，metadata.xml版本必须是整数（1000通常用作第一个稳定版本）接下来，对配置文件的每次更改都应遵循此版本号的增加，并且必须添加升级步骤：

<gs:upgradeStep
    title="Upgrade collective.myaddon from 1000 to 1010"
    description=""
    source="1000"
    destination="1010"
    handler=".upgrades.upgrade_1000_1010"
    profile="collective.myaddon:default"/> 


 upgrades.py
 def upgrade_1000_1010(context):
    """documentation
    """
    context.runImportStepFromProfile(default_profile, 'viewlets')
    portal_javascripts = getToolByName(context, 'portal_javascripts')
    portal_javascripts.cookResources()

为zope组件提供向后兼容性

1 个答案: