Support Frontmatter Via Document Attribute

[frostime]

您在什么场景下需要这个功能？

参见： https://ld246.com/article/1780601528021

描述最优解决方案

TLDR：官方正式支持对 frontmatter 的兼容，允许用户编辑设置

1. 为文档块增加一个官方保留的特殊内部属性，例如 sy__doc-frontmatter
2. 在前端实现一个专门的 Frontmatter 编辑区。

过去相关 Issue 表明（ #1016 #10878、#12962 ），官方倾向不把 YAML Front Matter 作为新的独立数据模型，而是优先纳入思源既有块属性 / 导入导出体系处理。

本提案亦是尝试在块属性框架内解决问题。

描述候选解决方案

No response

其他信息

No response

[TCOTC]

• 文档块可以转换为非文档块，如果是文档块专用属性的话如何处理？
• 如果要加属性，合适的命名是 custom-sy-doc-frontmatter
• “在前端实现一个专门的 Frontmatter 编辑区”感觉定位跟数据库属性面板重叠 编辑器顶部添加数据库属性面板 #11371

[TCOTC]

个人认为应该实现全局属性 #13121 ，所有类型的块都可以用，文档块则单独在开头用一个面板来显示它的全局属性和数据库字段

[frostime]

• 文档块可以转换为非文档块，如果是文档块专用属性的话如何处理？

  • 如果要加属性，合适的命名是 custom-sy-doc-frontmatter

1. 丢弃保留均可；最简单的作为属性存储，那就一致保留，只在块是文档类型的时候才被解释为文档的 frontmatter
2. 我的想法是 frontmatter 应该类似「文档隐藏」那样作为一个官方支持的内置属性；我记不清系统属性是啥样了，只是模糊记得有个 sy 前缀， sy__doc-frontmatter 只是一个例子而已。
3. frontmatter 和数据库是两回事，这点我在论坛的文章里说清楚过

[TCOTC]

• custom-sy- 是思源内置属性前缀
• 我没有混淆 frontmatter 和数据库

[frostime]

个人认为应该实现全局属性 #13121 ，所有类型的块都可以用，文档块则单独在开头用一个面板来显示它的全局属性和数据库字段

全局属性提了但是遥遥无期，而基于块属性的 frontmatter 实现起来要简单很多；前者很好但是如果长期无法实现，就不应该作为否定其他方案的缘由。

[TCOTC]

单独实现 frontmatter 将会跟全局属性冲突，故应当实现全局属性

[frostime]

• 文档块可以转换为非文档块，如果是文档块专用属性的话如何处理？

  • 如果要加属性，合适的命名是 custom-sy-doc-frontmatter

1. 丢弃保留均可；最简单的作为属性存储，那就一致保留，只在块是文档类型的时候才被解释为文档块

2. 我的想法是 frontmatter 应该类似「文档隐藏」那样作为一个官方支持的内置属性；我记不清系统属性是啥样了，只是模糊记得有个 `sy` 前缀， `sy__doc-frontmatter` 只是一个例子而已。

3. frontmatter 和数据库是两回事，这点我在论坛的文章里说清楚过

此外，frontmatter 是直接和导入导出 MD 相关联的

[frostime]

单独实现 frontmatter 将会跟全局属性冲突，故应当实现全局属性

如果全局属性是一个盼得到的东西，那我可能会赞同。

但问题是全局属性从 24 年提出到现在一年半了，甚至连动的苗头都没有。你不能拿一个没影的东西来搪塞。

此外我不理解你的“冲突”是什么意思。说白了这个提案的 frontmatter 也不过是一个特殊的属性而已，和文档隐藏、文档是日记没有什么本质区别，不过是需求：1）定下来一个特殊属性；2）前端支持 ；我不理解冲突在哪。如果这种冲突仅存在于某种形式上的统一美感，那么我认为这种‘设计上的完美主义’不应成为解决实际问题的阻碍。