Closed tmlee closed 11 years ago
Hi, thanks for your contribution :)
I made a small modification to return FbGraph::Comment
instance when succeeded comment.reply!
.
If you are OK with that change, I'll publish next version of this gem with your changes.
Humm, for some reason, MultiJson::load("string")
is failing only on ruby 1.9.2 on travis..
Needs to fix it before release.
Thanks @nov for the merge! yeah :+1: , think that will help fb_graph gem users to better expect the output. Is the multijson issue resolved?
Yeah, for some reason, MultiJson.engine
is MultiJson::Adapters::JsonGem
in ruby 1.9.2, and it can't parse top-level JSON String.
Anyway, I released new version of fb_graph. Thanks again!
hey @nov & @tmlee. I know that this is merged now. Just looking at comment! and reply! I think they are both doing the same thing? According to Facebook
Creating Replies to Comments
Creating a comment reply behaves in exactly the same way as above, with a couple of extra things to look out for:
The can_comment property on individual comments indicates whether a reply can be created and should be checked before offering the option to reply in an app.
If someone attempts to create a reply to another reply comment, they will receive an error, as this is not possible.
So just wondering other than checking can_comment?
Why we need comment!
vs reply!
. If for the sake of future separation why don't we just alias reply!
to comment!
for now so we don't have two blocks of code doing the same thing?
Thanks for the awesome work guys!
comment!
and reply!
can be just an alias if FB Graph API returns same format of response.
However, for now, it returns JSON object for comment!
and JSON string for reply!
.
Let's hope FB fixes their API interface soon.
As discussed on https://github.com/nov/fb_graph/issues/308
These commits are adding
Specs are dependent on a forked branch of the https://github.com/tmlee/fb_graph-mock.git