64 lines
4.7 KiB
Markdown
64 lines
4.7 KiB
Markdown
# Dever 示例
|
|
|
|
`examples/` 只保留两个入口：`cms/` 是当前维护的应用示例，`old/` 是旧语言合同和回归材料的归档。旧目录不符合当前 component/domain/role 应用布局，不应直接执行 `dever check/run/build`。
|
|
|
|
CMS 同时维护 [Dever 源码](cms/dever/module/news/article/api/admin/manage.dever)和 [Markdown 源码](cms/md/module/news/article/api/admin/manage.dever.md)。两套实现使用同一目录与业务合同：
|
|
|
|
```text
|
|
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` 并补齐文档合同。
|
|
|
|
编译器从 API/CMD/Job 声明生成入口。平台租户、账号、成员与会话是 `global type`，保存在共享平台库；文章、分类、修订、媒体、排期和审计属于当前租户物理库。认证 verify 只读取 global Model 并建立只读用户与租户身份；接口权限由核心根据当前站点和角色自动校验，后续 API 才进入可信 tenant scope。一个职责文件可包含一组内聚方法，没有按函数拆文件。
|
|
|
|
文章通过 `/news/article/admin/manage/create` 创建，`list/detail` 查询，`remove` 删除草稿，`publish` 发布。编辑调用 `/content/revision/admin/manage/create`，传入 `selected_article_id`、`expected_version`、标题正文和可空分类/媒体 ID；版本冲突返回 409，文章更新和修订快照在同一事务内完成。文章不声明绕过这些规则的自动 REST 写接口。列表 SQL 直接返回同领域 `app.ArticleView`，不暴露私有 Model。
|
|
|
|
`/publishing/schedule/admin/manage/schedule` 接收文章 ID 和 `publish_at`；创建时验证作者与草稿状态，按真实到期时间入队。每个排期有独立任务键，同刻文章不会合并。任务执行仍由核心复验身份和权限；发布、审计和排期状态一并提交或回滚，完成任务重放不会重复写入。手动重复发布返回 409。
|
|
|
|
在仓库根目录执行：
|
|
|
|
```bash
|
|
dever check examples/cms/dever
|
|
dever check examples/cms/md
|
|
dever test examples/cms/dever
|
|
dever test examples/cms/md
|
|
dever fmt examples/cms/dever --check
|
|
dever fmt examples/cms/md --check
|
|
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"}'
|
|
dever tenant migrate examples/cms/dever 1
|
|
dever tenant owner examples/cms/dever 1 admin 1
|
|
dever tenant owner examples/cms/dever 1 front 1
|
|
```
|
|
|
|
`run/build` 只读取各项目的 `config/setting.json`，运行数据写入各自 `data/`。先用 bootstrap CMD 建立平台租户、业务 Owner membership 与 Argon2 密码，再用返回的真实 `tenant_id` 执行 `tenant migrate`，并用返回的 `tenant_id/user_id` 分别 provision admin/front 核心 RBAC Owner；示例中的 `1` 只是首次空库的常见结果，不能在生产脚本里硬编码。两个站点各自通过同站点的 `user/authorization/<site>/manage` 接口管理普通角色。不带 CMD 参数时启动 admin/front HTTP API。`test` 不读取部署配置；每个涉及 Model 的测试使用独立临时 SQLite，并在结束后清理。
|
|
|
|
CMS 的五个应用测试验证分类、发布规则、账号引导/规范化和会话生命周期的正常业务输出，位于各项目根 `test/`；拒绝、过期等负向行为，以及带真实登录的 HTTP、并发编辑、上传、Job 重试/回滚验收见 [业务验收说明](../test/cms/README.md)。普通测试不伪造认证上下文。编译器和 CLI 的 Rust 回归测试仍统一位于仓库根 `test/`，两者都不混入业务 `module/`。部署前必须替换示例 JWT secret，并把两个站点的 `origin` 和 Host 改成真实 HTTPS 入口；`origin` 描述反向代理外部地址，不是 Dever 内部监听地址。
|
|
|
|
旧示例仍可供编译器维护者查阅历史语义，但不能作为新 Dever 应用的目录、可见性或调用方式范本。
|