如何将 Moose 对象转换为 JSON 以在 Catalyst 中使用?
我有一系列 Moose 对象,我希望将其提供给 JSON::XS 通过 Catalyst::View::JSON。 JSON::XS 无法对受祝福的数据结构进行编码。我知道有 MooseX: :Storage::Format::JSON 可以——有点——做我想做的事;但是,它似乎太重了。我正在寻找的信息基本上与 XXX.pm 相同 提供。我只是希望原始数据结构递归地不受祝福,所以 JSON::XS
(JSON::Any
的驱动程序 C:V:JSON
内部使用)可以显示它。
将 Catalyst::View::JSON
和 JSON::XS
与 Moose
对象一起使用的最佳方法是什么?看来我有四个明显的选择:
- 通过修补
C:V:JSON
来读取freeze<,使
Catalyst::View::JSON
与 Moose 对象一起工作。 /code> 如果暴露的参数是 Moose 对象,则完成请求。 - 修补
JSON::XS
以回退到返回$obj->freeze if $obj->isa('Moose') && 的值$obj->does('MooseX::Storage::Format::JSON')
。我应该查看 MX:S:F:JSON 来确保 JSON::Any 和代理 MX:S:F: 使用的类JSON 是JSON::XS
(如果JSON::Any
为 Moose 对象选择了不同的内部编码器,就会产生大量错误,JSON::XS
来使用。 - 调用
- > :View::JSON 只需写入 STDOUT
$obj->freeze
并手动完成请求。
我确信还有一些其他选项 。 ,有什么想法吗?
I have a series of Moose objects that I'm looking to feed to JSON::XS by way of Catalyst::View::JSON. JSON::XS is unable to encode blessed data-structures. I know that there is MooseX::Storage::Format::JSON which can -- kinda -- do what I want; but, it seems pretty overly heavy. What I'm looking for is essentially the same information that XXX.pm provides. I just want the raw-data structures recursively unblessed so JSON::XS
(the driver for JSON::Any
that C:V:JSON
uses internally) can display it.
What is the best way go about using Catalyst::View::JSON
and JSON::XS
with Moose
objects? It seems I have four obvious choices:
- Make
Catalyst::View::JSON
work with Moose Objects, by patchingC:V:JSON
to read fromfreeze
and finalize the request if the argument exposed is a Moose Object. - Patch
JSON::XS
to fallback to return value of$obj->freeze if $obj->isa('Moose') && $obj->does('MooseX::Storage::Format::JSON')
. I should look intoMX:S:F:JSON
to make sure that the class used byJSON::Any
, and by proxyMX:S:F:JSON
, isJSON::XS
(hate to think of the bugs galore ifJSON::Any
choses a different internal encoder for the Moose object thatJSON::XS
is called to use. - Figure out how to recursively-unbless and let
Catalyst::View::JSON
do its thing. - Don't use
Catalyst::View::JSON
at all. Just write to STDOUT$obj->freeze
and manually finalize requests.. This seems the most hackish.
I'm sure there are some other options, any ideas? What is my best bet?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我倾向于使用 MooseX::Storage 来执行选项 3,以提供一个
pack()
方法,该方法返回一个 Perl 数据结构,我可以将其填充到我的存储中,以便 View 可以根据需要呈现它。另请注意,可以强制 JSON::Any(通过环境,或通过将适当的参数传递给
import()
)来选择特定的后端。这就是测试套件的工作原理,并且已记录在案。I tend to do option 3 using MooseX::Storage to provide a
pack()
method that returns a Perl data structure that I can stuff in my stash so the View can render it as it chooses.Also note that JSON::Any can be forced (by the environment, or by passing the proper parameters to
import()
) to pick a specific backend. This is how the test suite works, and it is documented.如果您不关心完全取消对象的祝福并使其完全无法使用(从 Moose 的角度来看),请尝试从
Data::Structure::Util
取消祝福。我个人更喜欢
MooseX::Storage
以获得更优雅和可持续的解决方案。If you don't care about unblessing your object completely and making it completely unusable (from a Moose perspective), try unbless from
Data::Structure::Util
.I personally prefer
MooseX::Storage
for a much more elegant and sustainable solution.不管喜欢还是讨厌,我的最终解决方案是恢复到现在已弃用的 JSON::Syck 正是我想要的。以下是逻辑非 Moose 序列化为 JSON 的快速非 Moose 示例。
我给作者写了关于 JSON::XS 他不喜欢添加功能。以下是来自 的一些文本(从大量消息中断章取义,以说明为什么不存在此功能) JSON::XS 维护者 Marc Lehmann:
我不知道该如何回应,除了“我不在乎”。只是工作!喜欢::SYCK。我不期望对象能够完美地转换为 JSON。但是,我想我属于那 80% 只想让它发挥作用的人。我使用 JSON 进行 jQuery 导入,而不是在脑部手术期间执行银行交易。最终,我不想使用特殊的角色...我希望发送给它的任何内容都能神奇地转换到一定程度,使其在响应 jQuery JSON 请求时有用。
更新
抱歉,我错过了这些回复,直到有人说我在不相关的媒体上进行恶搞。 MooseX::Storage 不适用于非 Moose 类,我想要一种以 JSON 格式表示存储的通用方法。不幸的是,其中一些藏品成员是 Moose 对象。 XML::Simple 可以做到这一点,
Data::Dumper
可以做到这一点,JSON::Syck 可以做到这一点,这样的例子不胜枚举——我只想完成它。它不必与 Perl 1:1,说实话,我希望它的完成方式与JSON::Syck
默认情况下的方式相当接近。那么我在这里的论点是,“如何让JSON::XS
完全像JSON::Syck
目前那样工作”?而且,你的答案是你不能。所以我没有采用不同的解决方案。编写代码需要花钱,如果 Syck 已经做得对了,为什么我要编写to_JSON
...我想说的是,反对者有责任展示 Syck 正在序列化的内容时尚是不可取的。另外,请记住JSON::Syck
是由 Audry 播种的,他绝不是一个巨魔、白痴或“大脑受损”;或者,任何其他向我抛出的术语。我将以此结束:缺少JSON::Syck
的错误序列化路线以及所需的输出已经正在工作使我相信这是一个不错的选择我。而且,MooseX::*:JSON 对任意 Moose 对象有何不同的作用?为什么你认为不能编写代码来接受 Moose 对象而不是它的方法?如果你不这么认为,请用一些实质性的东西来回答——我希望看到更好的回应。谢谢。 (针对@jrockway和@Ether)Like it or hate it my ultimate solution was to revert back to the now deprecated JSON::Syck which does exactly what I want. Here is a quick non-Moose example of logical non-Moose serialization to JSON.
I wrote the author about JSON::XS he was not game for adding the functionality. Here is some of the text (taken out of context from numerous messages to show why this feature isn't there) from Marc Lehmann the JSON::XS maintainer:
I don't know how to respond to that, other than I DON'T CARE. JUST WORK! LIKE ::SYCK. I don't expect objects to transform to JSON perfectly. But, I think I fall in the 80% that just want it to work. I'm using JSON for jQuery import not performing banking transactions during brain surgery. Ultimately, I don't want to use a special role... I want anything sent to it to magically be transformed for me to a level that makes it useful in a response to a jQuery JSON request.
UPDATE
Sorry, I missed these replies until someone said I was trolling in an unrelated medium. MooseX::Storage doesn't work for non-Moose classes, I want a general way to represent the stash in a JSON format. Unfortunately, some of those members of the stash are Moose objects. XML::Simple can do this,
Data::Dumper
can do this, JSON::Syck can do this, the list goes on -- I just want it done. It doesn't have to be 1:1 with Perl, and to be honest I want it done fairly close to the wayJSON::Syck
does it by default. My argument here then, is, "How do I getJSON::XS
to work exactly likeJSON::Syck
does currently"? And, your answer is you can't. So I've not employed a different solution. Writing code costs money, why would I want to writeto_JSON
if Syck is already doing it right... I'd like to say the burden is on the nay-sayers to show what Syck is serializing a fashion that isn't desirable. Also, do keep in mindJSON::Syck
was seeded by Audry, who is by no means a troll, idiot, or "brain damaged"; or, any of the other terms that are being thrown my way. I will close with this: the lack of a bad serialization route ofJSON::Syck
and the desired output already just-working leads me to believe this is a good choice for me. And, what could MooseX::*:JSON be doing differently with an arbitrary Moose object? Why do you think that code can't be written to accept a Moose object rather than a method on it? If you think otherwise, answer with something of substance -- I'd like to see a better response. Thanks. (directed toward @jrockway, and @Ether)