cdrf-expert

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

CDRF Expert

CDRF专家

Instructions

操作说明

  1. Classify the request.
Map the user request to one or more categories:
  • Class selection (APIView vs GenericAPIView vs concrete generics vs ViewSets)
  • Lifecycle tracing (request-to-response flow)
  • Override strategy (which hook to customize)
  • MRO debugging (method came from mixin/base class)
  • Version differences (behavior changed between DRF versions)
  1. Read only the required reference file(s).
Load the minimum needed context:
  • references/class-selection-matrix.md
    for class selection
  • references/lifecycle-and-overrides.md
    for hook placement and lifecycle
  • references/mro-debugging-playbook.md
    for MRO/source-of-method tracing
  • references/version-check-workflow.md
    for DRF-version comparisons
  1. Navigate cdrf.co with version-first discipline.
  • Identify the project DRF version from user context.
  • If unknown, ask for version or provide a version-agnostic answer and explicitly mark assumptions.
  • Open the matching CDRF version namespace first (for example
    https://www.cdrf.co/3.16/
    ).
  • Open the target class page and extract:
    • Ancestors and MRO
    • Available methods and source class for each method
    • Default attributes that affect behavior (
      queryset
      ,
      serializer_class
      , pagination/filter backends)
  1. Choose the minimal override point.
  • Prefer narrow hooks (
    perform_create
    ,
    perform_update
    ,
    perform_destroy
    ) before broad methods (
    create
    ,
    update
    ,
    destroy
    ).
  • Prefer
    get_queryset
    and
    get_serializer_class
    for per-request behavior over hardcoding class attributes.
  • Keep HTTP orchestration in view methods and business/domain logic outside views.
  • Preserve DRF defaults unless the request needs behavior changes.
  1. Produce an answer grounded in method flow.
Return:
  • Recommended class
  • Method(s) to override
  • Why these methods are correct in the MRO/lifecycle
  • Concise code patch or skeleton
  • Risks/regressions and tests to add
  1. Validate before finalizing.
Check for common regressions:
  • Accidentally bypassing permission/authentication/filter/pagination hooks
  • Duplicating object-save logic between serializer and view
  • Overriding broad methods when narrow hooks are sufficient
  • Depending on methods not present in the selected DRF version
  1. 对请求进行分类。
将用户请求映射到一个或多个类别:
  • 类选择(APIView vs GenericAPIView vs 具体通用视图 vs ViewSets)
  • 生命周期追踪(请求到响应的流程)
  • 重写策略(自定义哪个钩子)
  • MRO调试(方法来自mixin/基类)
  • 版本差异(DRF版本间的行为变化)
  1. 仅阅读必要的参考文件。
加载所需的最少上下文:
  • 类选择:
    references/class-selection-matrix.md
  • 钩子放置与生命周期:
    references/lifecycle-and-overrides.md
  • MRO/方法来源追踪:
    references/mro-debugging-playbook.md
  • DRF版本对比:
    references/version-check-workflow.md
  1. 遵循版本优先原则使用cdrf.co。
  • 从用户上下文确定项目的DRF版本。
  • 若版本未知,询问用户版本,或提供与版本无关的答案并明确标记假设。
  • 首先打开匹配的CDRF版本命名空间(例如
    https://www.cdrf.co/3.16/
    )。
  • 打开目标类页面并提取:
    • 父类与MRO
    • 可用方法及每个方法的来源类
    • 影响行为的默认属性(
      queryset
      serializer_class
      、分页/过滤后端)
  1. 选择最小化的重写点。
  • 优先选择窄范围钩子(
    perform_create
    perform_update
    perform_destroy
    )而非宽泛方法(
    create
    update
    destroy
    )。
  • 对于每个请求的行为,优先使用
    get_queryset
    get_serializer_class
    而非硬编码类属性。
  • 将HTTP编排保留在视图方法中,业务/领域逻辑放在视图之外。
  • 除非请求需要更改行为,否则保留DRF默认设置。
  1. 生成基于方法流程的答案。
返回内容包括:
  • 推荐的类
  • 应重写的方法
  • 这些方法在MRO/生命周期中为何正确的原因
  • 简洁的代码补丁或框架
  • 风险/回归问题及需添加的测试
  1. 最终确认前进行验证。
检查常见回归问题:
  • 意外绕过权限/认证/过滤/分页钩子
  • 在序列化器和视图间重复对象保存逻辑
  • 当窄范围钩子足够时却重写了宽泛方法
  • 依赖所选DRF版本中不存在的方法

Error Handling

错误处理

  1. If cdrf.co is unavailable, state that limitation and fall back to DRF official docs and installed source code.
  2. If the user cannot provide DRF version, provide a version-agnostic path and clearly mark assumptions.
  3. If multiple override points appear valid, recommend the narrowest hook first and explain tradeoffs.
  1. 若cdrf.co不可用,说明该限制并改用DRF官方文档和已安装的源代码。
  2. 若用户无法提供DRF版本,提供与版本无关的方案并明确标记假设。
  3. 若多个重写点看似都有效,优先推荐最窄的钩子并解释权衡。

Output Rules

输出规则

  • Cite exact class and method names from CDRF.
  • State assumptions when DRF version is unknown.
  • Keep responses focused on DRF CBV internals and actionable code changes.
  • 引用CDRF中的精确类和方法名称。
  • 当DRF版本未知时说明假设。
  • 回复内容聚焦于DRF CBV内部机制和可执行的代码变更。