1

我正在开发一个新版本的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 """

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

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

4

1 回答 1

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()
于 2011-05-11T12:06:38.683 回答