建议详情
在某种程度上,这与 encoding/xml: context-aware XML decoders 和 encoding/json supports Marshaler/Unmarshaler interfaces with a context.Context 非常相似。不同之处在于它是针对XML编码的,但在精神上它涵盖了其他两个。
- 添加
func NewEncoderWithContext(ctx context.Context, w io.Writer) *Encoder
- 添加
func (*Encoder) Context() context.Context
- 添加包含
MarshalXMLAttrWithContext(ctx context.Context, name Name) (Attr, error)
的type ContextMarshalerAttr interface
使用案例
(转述@as)一个go程序中的HTTP处理程序在响应HTTP请求时对XML文档进行编组。举两个例子:
- XML文档包含一些本地化的属性(i18n);
- 一些属性需要完全或部分地被遮盖,因为有一些基于用户的数据遮盖策略。
上下文携带了i18n接受的语言和从中派生的数据遮盖策略的用户信息。
响应可以预先准备,以便可以为需要不同本地化的不同请求进行编组。
示例使用
type TranslatableString string
func (ts *TranslatableString) MarshalXML(e *xml.Encoder, start xml.StartElement) error {
var v string
if ts != nil {
v = i18n.GetString(e.Context(), *ts)
}
return e.EncodeElement(v, start)
}
func (ts *TranslatableString) MarshalXMLAttrWithContext(ctx context.Context, name xml.Name) (Attr, error) {
var v string
if ts != nil {
v = i18n.GetString(ctx, *ts)
}
return xml.Attr{Name: name, Value: v}, nil
}
之前的反驳
@rsc评论了之前引用的两个建议:
上下文不适用于每个操作选项。它是用于超时和更全局的东西,如授权凭据,而不是细粒度的每个调用选项。 ...
然而,https://go.dev/blog/context 具体记录了使用上下文以这种方式从请求中提取用户IP地址并将其与 Context
关联,以便稍后由不同的包在请求处理过程中使用。
5条答案
按热度按时间lpwwtiir1#
cc: @sebastien-rosset@as
dffbzjpn2#
可能的实现
nbnkbykc3#
我通常认为使用
context.Context
值的方式是作为一种建模跨领域关注点的方法,尤其是当这些关注点可能需要通过一个(且不需要知道它们)API来传递给另一个(确实共享关注点的)API时。将这个想法应用到你的建议中,我可以理解这样一个观点:将“最终用户更喜欢的人类语言”建模为跨领域关注点可能是有用的,但我认为像XML库这样的东西直接依赖于这一点会让人感到惊讶,而不是让调用应用程序做出这个决定,然后通过一个新的明确的 API将这个信息传达给XML库,而不是让XML库接受一个上下文并自己提取值。
我认为如果这看起来像是将此视为跨领域关注点是正确的想法(与我上面的论点相反),那么识别其他可能使用这种新约定的库是很重要的,并确保设计足以满足至少大部分这些用例的需求。考虑到在实践中只有一个包可能会使用它作为跨领域关注点的可能性,似乎很难证明将语言偏好在函数之间传递是一个跨领域关注点。🤔
ryoqjall4#
在我的第一个回复之后,我对此进行了更多的思考,并找到了一种不同的思考方式,这使我对它感到更加有利:
这个提议并不是真正关于将首选语言传递给XML库,而是关于通过XML库将信息传递给调用应用程序内部的编组代码。
在这种情况下,跨领域的关注点是应用程序能够将其任意数据传递给其自身的解组实现,而不管这些数据是什么。我完全可以认同这种需求,并且在过去自己也使用过上下文来实现类似的事情,但每当我最终为一个没有中断可执行I/O功能的函数添加一个上下文参数时,总感觉有点奇怪。我不知道是否有比这更好的机制来以这种方式传递跨领域的关注点。
eufgjt7s5#
这个建议并不是真正关于将首选语言传递给XML库,而是关于通过XML库将这些信息传递给调用应用程序内部的一些编组代码。
在这种情况下,跨领域的关注点是应用程序能够将其任意数据传递给其自身的解组实现,而不管这些数据是什么。
是的,完全正确。我给出的具体例子是用户首选语言(这是我的主要驱动因素),但我也提到了基于其他请求属性的数据过滤。我可以想象其他用例。
虽然
Context
开箱即用仅支持取消操作(包括超时),但它允许附加应用程序特定值的事实似乎是一个强烈的迹象,表明这种用途已经被明确预见到。