Files

Dever 示例

看当前用法请用 cms/;old/ 只保存历史回归材料,不是新项目模板,也不能直接按当前应用运行。

CMS 同时维护 Dever 源码和 Markdown 源码。两套实现使用同一目录与业务合同:

module/
  platform/tenant/          平台租户
  user/account/             凭据、登录、bootstrap CMD
  user/membership/          租户成员
  user/session/             登录会话
  user/authorization/       核心角色授权的业务入口
  content/category/         分类
  content/revision/         文章编辑与修订快照
  media/asset/              上传、Storage Port/Adapter
  publishing/schedule/      定时发布与 Job
  audit/operation/          操作审计
  system/health/            健康 CMD
  news/article/
    app/editing.dever
    app/publication.dever
    api/admin/manage.dever
    api/front/browse.dever
    domain.dever
    model.dever
    model/publication.dever
test/
  content/category/lifecycle.dever
  news/article/publish.dever
  user/account/bootstrap.dever
  user/account/validation.dever
  user/session/lifecycle.dever

Markdown 项目使用相同的目录和 API/CMD 声明,仅把源码扩展名换成 .dever.md 并补齐文档合同。

数据和权限

平台租户、账号、成员和会话使用 global type,保存在平台库。文章、分类、修订、媒体、排期和审计放在各租户自己的数据库。

verify 先核实 global 身份数据。核心按站点和角色检查接口权限,成功后才访问租户数据。入口由 API、CMD、Job 声明生成,无需 main。相关方法放在同一业务主题文件里,不按函数逐个拆文件。

文章接口位于 /news/article/admin/manage/:create 创建,list/detail 查询,remove 删除草稿,publish 发布。

编辑使用 /content/revision/admin/manage/create,传入文章 ID、expected_version、标题正文和可空分类/媒体 ID。版本冲突返回 409,文章更新与修订快照一起提交。文章不用自动 REST 写接口,以免跳过这些规则;列表返回 app.ArticleView,不泄漏私有 Model。

定时发布使用 /publishing/schedule/admin/manage/schedule,传入文章 ID 和 publish_at。创建时检查作者和草稿状态;每个排期有独立任务,不会合并同时发布的文章。

执行任务前,核心再次核验身份和权限。发布、审计和排期状态一起提交或回滚,完成任务重复执行不重复写入。手动重复发布返回 409。

先检查,再运行

在仓库根目录执行:

dever check examples/cms/dever
dever check examples/cms/md
dever test examples/cms/dever --filter news.article.publish
dever test examples/cms/md --filter news.article.publish
dever fmt examples/cms/dever --check
dever fmt examples/cms/md --check

这些测试使用独立临时 SQLite,不连接部署数据库,结束后清理。命令仍会读取配置与锁中的依赖信息。检查全部应用测试时再去掉 --filter。

实际部署前先替换 JWT secret,并把两个站点的 origin 和 Host 改成真实 HTTPS 入口;origin 是用户访问的外部地址,不是内部监听地址。

用 bootstrap CMD 建立平台租户、Owner 成员和密码:

dever run examples/cms/dever -- user.account.bootstrap '{"tenant_key":"tenant-one","tenant_name":"Tenant One","email":"owner@example.com","display_name":"Owner","password":"change-me-now"}'

替换示例账号与密码,再用返回的真实 tenant_id 和 user_id 执行以下命令,不要猜测 ID 是 1:

dever tenant migrate examples/cms/dever <tenant_id>
dever tenant owner examples/cms/dever <tenant_id> admin <user_id>
dever tenant owner examples/cms/dever <tenant_id> front <user_id>

这会迁移租户数据库,并建立后台、前台的核心 Owner。之后各站点通过 user/authorization/<site>/manage 管理普通角色。运行配置在项目的 config/setting.json,数据在 data/;dever run examples/cms/dever 不带 CMD 参数时启动 HTTP 服务。

CMS 的五个应用测试覆盖分类、发布规则、账号引导/规范化和会话正常流程,放在各项目的 test/,不伪造认证上下文。

拒绝、过期、真实登录、HTTP、并发编辑、上传和 Job 重试/回滚见 业务验收说明。编译器与 CLI 的 Rust 回归测试在仓库根 test/,都不放进业务 module。

旧示例仍可供编译器维护者查阅历史语义,但不能作为新 Dever 应用的目录、可见性或调用方式范本。