#1 - 2024-5-29 10:50
Hyary (✩ <ゝω・)
EXEC_WIKI=BGM/. 工程项目:
❏ [组件] 音乐条目显示各曲目参与制作人员信息(本帖)
❏ [组件+] 维基音乐条目可视化编辑套件
组件:https://bgm.tv/dev/app/3136
(联动 [组件 / 脚本] 动画条目显示各章节参与制作人员信息)
2023 年 6 月,班古米维基系统新增了制作人员「参与」章节/曲目的功能,简单来说就是关联制作人员的时候,可以记录每个人具体负责哪几个章节/哪几首曲目。但是好像因为太麻烦了,就没有太多维基人有动力去填参与信息
每次写维基,去看到 MusicBrainz 每条曲目的制作人员信息,我就心痒痒,想着什么时候我们班古米也能整一个。
朝思暮想,悱恻之情终于化作开坑的勇气。所以就,锵锵✨

现在填写曲目参与信息能显示在条目页面上了,希望这能让诸位维基人能更方便地检查参与信息,也更有动力填写参与信息。
什么?每个关联都去核实填写实在是太麻烦了?分かる、分かるよ。其实我有一套自用的脚本和小组件,可以做到现在还在打磨,我会在接下来几个月里整理发布出来的
(现在是 python 脚本,但我想做成开箱即用的组件或网页 app,另外尽量衔接现有的自动关联组件
希望、希望大家很快就不再需要这个小组件了!
❏ [组件] 音乐条目显示各曲目参与制作人员信息(本帖)
❏ [组件+] 维基音乐条目可视化编辑套件
组件:https://bgm.tv/dev/app/3136
(联动 [组件 / 脚本] 动画条目显示各章节参与制作人员信息)
2023 年 6 月,班古米维基系统新增了制作人员「参与」章节/曲目的功能,简单来说就是关联制作人员的时候,可以记录每个人具体负责哪几个章节/哪几首曲目。但是好像因为太麻烦了,就没有太多维基人有动力去填参与信息
每次写维基,去看到 MusicBrainz 每条曲目的制作人员信息,我就心痒痒,想着什么时候我们班古米也能整一个。
朝思暮想,悱恻之情终于化作开坑的勇气。所以就,锵锵✨

现在填写曲目参与信息能显示在条目页面上了,希望这能让诸位维基人能更方便地检查参与信息,也更有动力填写参与信息。
什么?每个关联都去核实填写实在是太麻烦了?分かる、分かるよ。其实我有一套自用的脚本和小组件,可以做到
只需要从特设网站页面复制整段的曲目 credit,就可以几乎全自动生成 infobox、曲目列表,然后精确自动关联制作人员
(现在是 python 脚本,但我想做成开箱即用的组件或网页 app,另外尽量衔接现有的自动关联组件
希望、希望大家很快就不再需要这个小组件了!
顺序
#2 - 2024-5-29 13:54
#11 - 2024-7-11 13:25
#15 - 2024-9-7 19:23
#16 - 2024-11-30 14:08
唯独惑
#16-1 - 2024-11-30 17:26
#16-2 - 2024-11-30 23:22
唯独惑
感谢拷打~
已经在着手去除内嵌的 div,原本的门槛在 li.style.overflow = 'hidden' 时,如果要保持高度的一致性,会有2px高度的文字溢出到 padding-bottom 区域...通过附加分层遮罩算是解决了,然后不知道为什么折叠的上下文防迷失功能在特殊情形下会出现Bug?再研究研究...
对于插入的 SVG,虽然图标用伪元素就可以呈现,但要实现触控点击...不直接依赖父辈的实体元素,实现有些困难...暂不考虑了
好的~音乐条目的职位排序会采纳的
嗯...是指你从 infobox 中获取用户自定义 / 默认设置排序后的职位顺序信息吗?应该是可以实现的,只要用户启用了该脚本,同时你的组件后于其获取
Hyary 说: 好诶
仔细看了一下,你不仅加了元素,还额外包了一层div,好强的侵入性,修了
提议一下个人认为的音乐条目职位排序供参考,基于 #15 的讨论拓展而来:
"制作人", "艺术家", "作词", "作曲...
已经在着手去除内嵌的 div,原本的门槛在 li.style.overflow = 'hidden' 时,如果要保持高度的一致性,会有2px高度的文字溢出到 padding-bottom 区域...通过附加分层遮罩算是解决了,然后不知道为什么折叠的上下文防迷失功能在特殊情形下会出现Bug?再研究研究...

对于插入的 SVG,虽然图标用伪元素就可以呈现,但要实现触控点击...不直接依赖父辈的实体元素,实现有些困难...暂不考虑了
好的~音乐条目的职位排序会采纳的
嗯...是指你从 infobox 中获取用户自定义 / 默认设置排序后的职位顺序信息吗?应该是可以实现的,只要用户启用了该脚本,同时你的组件后于其获取
#16-3 - 2024-12-1 08:19
Hyary
感谢精益求精!
基于渲染结果还得考虑启动顺序,希望能直接读取 localStorage 之类的
唯独惑 说: 感谢~
已经在着手去除内嵌的 div,原本的门槛在 li.style.overflow = 'hidden' 时,如果要保持高度的一致性,会有2px高度的文字溢出到 padding-bottom 区域...
基于渲染结果还得考虑启动顺序,希望能直接读取 localStorage 之类的
#16-4 - 2024-12-4 20:50
#16-5 - 2024-12-5 15:39
Hyary
啊?我启发了什么?我也不好意思说什么,或者说“我看不懂啊”,因为你写得好认真好认真
谢谢你专门写这个 API !但是对不起,可我还是想说这有点过度工程了
TL;DR: 遵照 schema 定义的结构化数据本身就是一种 API
我原来的想法是:在你的组件里,用户用 StaffMapListJSON 设置,你在规范化 (normalize) 成 JSON 后存 localStorage 里。加载时,你的组件和我的组件都可以读这个 JSON,这样大家都不需要 parse StaffMapListJSON,只需要 JSON.parse() 过后按照你给的 schema 读自己需要的部分就行。
未来你那边想对这个 JSON 的 schema 做 breaking change 的时候,可以 1) 私信轰炸我催我升级组件;2) 新 schema 的存另一个 localStorage key,保留旧 schema 存原 key 兼容没跟着升级的组件
唯独惑 说: 实现了一个基于 localStorage 的异步通信 接口
谢谢你专门写这个 API !但是对不起,可我还是想说这有点过度工程了TL;DR: 遵照 schema 定义的结构化数据本身就是一种 API
我原来的想法是:在你的组件里,用户用 StaffMapListJSON 设置,你在规范化 (normalize) 成 JSON 后存 localStorage 里。加载时,你的组件和我的组件都可以读这个 JSON,这样大家都不需要 parse StaffMapListJSON,只需要 JSON.parse() 过后按照你给的 schema 读自己需要的部分就行。
未来你那边想对这个 JSON 的 schema 做 breaking change 的时候,可以 1) 私信轰炸我催我升级组件;2) 新 schema 的存另一个 localStorage key,保留旧 schema 存原 key 兼容没跟着升级的组件
#16-6 - 2024-12-5 17:43
唯独惑
原来是这个意思,我原本以为你是想让我来帮忙完成排序这个动作...我文档写得确实专业性不足,我再尝试解释一下。
目前这个接口就是用来完成固定场景的排序工作的,例如你的组件中各曲目参与制作人员信息基本只固定包含“艺术家、作词、作曲、编曲、声乐、乐器”,就可以将该信息按照接口声明内的方式封装写入 localStorage 的约定键值中,随后可以直接从 localStorage 另一个约定键值中读取排序后的结果。
你的想法是,想让我我将 StaffMapListJSON parse 后的数据存入 localStorage 中,嗯...其实是没有必要的,因为只要是存在键值中的数据都已经是被我规范化后的,能保证它一定能被 JSON.parse() ,只要是用户是通过我提供的UI进行设置的而不是直接修改键值对。
也就是其他脚本可以对存储 StaffMapListJSON 数据的 BangumiStaffSorting_${subjectType}StaffMapList 进行直接解析,获取职位次序,方法如下:
以上算法不是最高效的,只是这样链式写功能分离地比较清晰
我发现我俩误解之源就是 StaffMapListJSON parse 的方式
,如代码所示你让我来帮你 parse 完全没这必要,我顶多可以帮你完成2,3两步,但没这必要,只是少两行代码...
要实现你的想法,我这边唯一要修改的就是要将默认设置写入 localStorage (目前是只存于脚本内的)
Over
接口写就写了,要不你先用用试试,再看哪种方法更好吧...
Hyary 说: 啊?我启发了什么?我也不好意思说什么,或者说“我看不懂啊”,因为你写得好认真好认真 谢谢你专门写这个 API !但是对不起,可我还是想说这有点过度工程了
TL;DR: 遵照 schema 定义的结构...
原来是这个意思,我原本以为你是想让我来帮忙完成排序这个动作...我文档写得确实专业性不足,我再尝试解释一下。目前这个接口就是用来完成固定场景的排序工作的,例如你的组件中各曲目参与制作人员信息基本只固定包含“艺术家、作词、作曲、编曲、声乐、乐器”,就可以将该信息按照接口声明内的方式封装写入 localStorage 的约定键值中,随后可以直接从 localStorage 另一个约定键值中读取排序后的结果。
你的想法是,想让我我将 StaffMapListJSON parse 后的数据存入 localStorage 中,嗯...其实是没有必要的,因为只要是存在键值中的数据都已经是被我规范化后的,能保证它一定能被 JSON.parse() ,只要是用户是通过我提供的UI进行设置的而不是直接修改键值对。
也就是其他脚本可以对存储 StaffMapListJSON 数据的 BangumiStaffSorting_${subjectType}StaffMapList 进行直接解析,获取职位次序,方法如下:
const jobOrder =
// 1.保证能直接被JSON.parse,且获得一个数组
JSON.parse(localStorage.getItem(`BangumiStaffSorting_${subjectType}StaffMapList`))
// 2.扁平化多维数组
.flat(Infinity)
// 3.只获取排序信息,过滤boolean型的折叠信息
.filter(item => typeof item === "string")
// 4.活化字符串类型的正则表达式
.map(item => item.startsWith('/') ? parseRegExp(item) : item)
// 最终获得一维的数组,其元素包含用于精确匹配的字符串与用于正则匹配的RegExp,元素顺序就是所匹配的职位顺序
function parseRegExp(regexString) {
const match = regexString.match(/^\/(.+)\/([gimsuy]*)$/);
if (match) return new RegExp(match[1], match[2]);
else return null;
}
我发现我俩误解之源就是 StaffMapListJSON parse 的方式
,如代码所示你让我来帮你 parse 完全没这必要,我顶多可以帮你完成2,3两步,但没这必要,只是少两行代码...要实现你的想法,我这边唯一要修改的就是要将默认设置写入 localStorage (目前是只存于脚本内的)
Over
接口写就写了,要不你先用用试试,再看哪种方法更好吧...









启用之后收藏不了单曲了

