Gabe
Gabe
请教一下： 1、能不能在路由的前缀树节点中直接记录分组以及中间件函数呢？`node`中增加一个是否分组的标记，以及中间件列表。省去`Engine`和`RouterGroup`相互引用 2、另外，我觉得路由的`handler`是否也可以直接挂载到路由节点中呢？ 大概这样： ```go // router.go type router struct { root *node } ``` ```go // trie.go type node struct { pattern string part string children []*node isWild bool...
> This should work, set false to true if this header is required > > ```go > // @Param accept-language header string false "some description" > ``` Yes it works,...
穷举法？其实也不多，看了下，大概有这两种： ```html ... ... ... ``` ```html ... ... ```
@quoid @ACTCD 如果是技术上的原因，无法实现`unsafeWindow`，我也无话可说。但如果是其他什么原因，我还是同意前面 @fyy99 的观点，应该把选择权交给用户，而不是对油猴脚本标准随意进行割裂。 首先我来说下我的`unsafeWindow`用例： > 我开发了一个脚本（[查看代码](https://github.com/fishjar/kiss-translator)），需要一个很复杂的`设置页面`来使用。常规的做法可以把`设置页面`的代码写到脚本里面，但这会导致脚本的体积膨胀臃肿。其实这是完全没有必要的，因为使用的时候，不需每个页面都加载`设置页面`的代码。 > 所以我把`设置页面`的庞大代码分离了出来，并单独部署。然后`设置页面`的代码利用了`unsafeWindow`来访问`GM`的接口，这样非常的方便。特别是我的脚本和页面共用许多代码的情况下，并不需要考虑某段代码是在`油猴脚本`执行还是`页面脚本`执行。 > 否则的话，按你描述的方式，利用`@inject-into`代码注入，通过事件来通讯，我实在不知如何处理。因为事件模型一般用在单向信号传递，用来做数据交互非常麻烦而不实际。 所以我认为 `unsafeWindow` 是有必要的： - 如我的用例所描述，`unsafeWindow`在某些情况可以极大方便开发者。 - 而且 `unsafeWindow` 在 `Tampermonkey` 里是标准提供的。 关于安全性的问题： - 根据我的理解，如果提供`@inject-into`注入代码的功能，那么是否提供`unsafeWindow`，安全性都是一样的。因为`unsafeWindow`可能触发的风险，`@inject-into`也能一样可以触发。唯一区别是`unsafeWindow`更方便而已。 - 而且因这种不安全性受到损失的概率我想也是极低，不能因微小的几率而放弃极大便利，就如人们不会为了避免车祸而拒绝乘坐汽车。 当然，如果我的理解有误，欢迎指出。 或者针对我的用例，您有更好的解决方案，欢迎提出。...
@ACTCD 感谢您的及时回复！ - 如果没有办法在 safari 实现 `unsafeWindow`，那真的比较遗憾。 - 看来我只能利用`@inject-into`来实现了，虽然复杂性增加了许多。 - 需要设计一个机制来区分`listener`与`dispatch`的一一对应关系。 - 或许还需要将`Event`进一步封装成一个`Promise`方便使用。 - 关于安全性的理解，如果你很肯定，那也许你是对的，我接触油猴脚本的时间并不长。
@ACTCD 感谢您的提示及帮助，虽然麻烦了一些，还好工作量比想象的要少。 目前我的项目([kiss-translator](https://github.com/fishjar/kiss-translator/releases))可以在`Userscripts Safari`下运行了。
@ACTCD 您好！ 我的项目本来是在 `FireFox` 工作良好的，突然出现bug，然后就发现下面的事实： - `@inject-into` 方式在 `Userscripts Safari` 可以运行，但在 `FireFox + Tampermonkey` 却不行。 - 在`Firefox`中，油猴脚本提示 `window.dispatchEvent` 方法不存在。 - `unsafeWindow` 方式在 `Userscripts Safari` 不能用，但在 `FireFox + Tampermonkey` 却工作良好。 真是够折腾，为了弥补割裂的现实，或许只能增加更多的适配代码...
> @fishjar 是的，这就是我上面提到的[不同的扩展以不同的方式](https://github.com/quoid/userscripts/issues/252#issuecomment-1299560649)实现了该方法。包括是否真实注入到了页面上下文，也是存在实现差异。这也是我撰写上述评论的初衷，即我们不想再为这些已经存在的混乱添加更多的“自定义”兼容实现，制造更多混乱。 > > [`dispatchEvent`](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/dispatchEvent) 是 Event API 的标准方法，在页面和内容脚本范围都适用。您可以测试到我上面提供的示例脚本在 Firefox + Greasemonkey / FireMonkey 等环境中都是正常工作的。 > > 也就是说该项目并没有添加任何差异实现，或造成进一步割裂的自定义实现。而这些也是为什么我建议不要再实现该 `unsafeWindow` 方法，以及使用推荐的通用方式制作示例用户脚本的原因。这是目前我们能够做的。 请问最新版`userscripts`是否已经支持 `unsafeWindow` 了？
chromecast的问题有什么好的解决办法吗？
> 不知道是不是和今天twitter.com重定向到X.com有关，只能等等作者有时间排查一下了。 可能是这个原因，我刚才添加了`x.com`，稍后同步一下订阅规则试试。