难度：高
- 模板地址，为一个 GitHub repo URL
- 拉取模板
- 从模板生成静态页面，生成方案需要探索
- 打包
静态页面生成方案一定要使用 Python 的技术栈吗？我觉得在这一块可以使用前端的技术方案，因为前端的 SSG 方案更为成熟，我的设想是：
- 模板可以是一个 Nuxt 或者 Astro 的仓库，生成阶段去调用 Bamboo 的 API 生成静态页面；
- 模板仓库提供 GitHub Workflows，管理员可以在 Bamboo 后台调用 GitHub 提供的 API（应该有这类 API）触发模板构建。
这是一个好建议
但这似乎对模板的要求有点高：
- 要调正确的API（要配置好API地址）
- 相当于打包发布不是归bamboo管了，那就要有自己的发布的workflow
还有一个问题，就是如果bamboo down了，那这个前端项目就build不出来了。
前端技术栈确实很诱人，如果能抽象出一个统一的接口，同时支持bambo构建和自己构建就好了。
这个库确实在我的脑海中，而且它最近支持到了Flask 3.0
可以试一下，如果搞不通可以自己撸
我先说说我的实现想法：
- 模板使用 Jinja 编写，并且让 Jinja 的 Template Loader 支持从 Repo 拉取模板及使用本地模板，便于支持模板开发；
- 静态页面的蓝图也注册到 Flask APP 上，便于预览；
- 生成的过程放到任务队列中去，生成过程中使用 Frozen-Flask。
2 个赞
可以有一个预先拉取的动作，就不用支持远程读取了。而且也会需要经常拉取模板的最新改动。
2 个赞
这个 PR 的测试用例跑不过，但是单跑测试文件（pytest backend/tests/test_ssg.py）是能跑过的，但是用 pytest 跑就出问题了，显示 APScheduler 的 Job ID 冲突，我晕了。
这是个挺重要的功能，也是输出阶段的，不用太着急，有几个点
- 网站的相关路由应该是一个独立的蓝图
- 这个蓝图有自己的静态路径
- 模板生成的 url 最好是相对 url，这样方便网站部署在某个子路径下，比如现在的 pycon url 前缀都是/2023，你可以看下 html 内容能理解我说的相对路径的意思，可以封装成一个函数注入到模板里使用
我目前的实现和上面有差异。
我实现了一个 Web 接口作为预览接口，这个接口会类似于 /ssg/<site_id>/<path:file> 这种形式，如果 file 参数的前缀是 static 我就认为是静态资源，并且将静态资源返回，否则，我就认为是模板，就会交给 Jinja 渲染。
在我的理解是这个接口应当只是用于网站管理员预览界面，所以应该有鉴权，不知道理解是否正确。
其次是生成的 URL，我的设计是我会遍历所有的模板，然后用类似于文件树路由的方式去组装网站的路由，所以模板编写者在编写模板的时候，只要在模板内写相对路径就行了，并不需要程序去干预。
不过还有一个问题我还没想清楚，就是动态路由怎么做，现在的逻辑只能保证一个模板页生成一个页面。
你可以看看 frozen-flask，肯定大部分都是动态生成啊，不然这个 cms 有啥意义
OK
对不起，工作还没着落，我最近找些时间把之前的代码整理一下吧，没完成的功能点完成一下 
1 个赞
@greyli @frostming 对不起这是延期好久的 PR，目前这版还是草案，请看看这个实现方式是否恰当，目前的实现思路还是依赖 Frozen-Flask，视图层面 通过 @freezer.register_generator 来实现动态路由的 URL 发现。目前这版我的预想中只能实现一个参数的动态路由，诸如 city/<int:city_id> 这种形式，同时这一整个视图会共用同一个模板文件，我会 Site 和 City 对象都注入到模板中。
另外还有一个问题，目前后端的认证是基于 Token 的，但是这个模板的预览页面无法使用 Token 认证，或许应该使用 Session / Cookie？这个需要和实现认证的同学协商。
还有目前视图实现了静态文件和首页，因为还没确定有哪些对象需要通过模板静态渲染。确定之后补上视图就 OK 了。
PS：大家多喝水多运动，结石真的很痛苦，痛到在床上打滚。
3 个赞
认证和授权部分是我实现的，这个问题我们之前注意到过，可以分别走两个校验逻辑，一个Token，一个Sessoin/Cookie。
不过，我不太明白的一点是：这个模板预览是直接在后端生成、预览，不通过前端页面的吗？
PS：默默地放下了手中的饮料…