You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Cassie Doll (JIRA)" <ji...@apache.org> on 2008/09/06 03:14:44 UTC
[jira] Created: (SHINDIG-574) The restful/rpc apis should be
producing a displayName field on the person object.
The restful/rpc apis should be producing a displayName field on the person object.
-----------------------------------------------------------------------------------
Key: SHINDIG-574
URL: https://issues.apache.org/jira/browse/SHINDIG-574
Project: Shindig
Issue Type: Bug
Components: RESTful API (Java)
Reporter: Cassie Doll
Priority: Blocker
This should be a pretty easy change.
- a String displayName field needs to be added to Person
- the JsonDbContainer should fill it out
- the javascript person.js should be changed to not implement getDisplayName
- jsonperson.js should be changed to retrieve the displayName from the json from the server that it is constructed with
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-574) The restful/rpc apis should be
producing a displayName field on the person object.
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631979#action_12631979 ]
Cassie Doll commented on SHINDIG-574:
-------------------------------------
I'm not sure I understand.
person.js is still appropriate for containers which aren't backed by the restful apis yet - which is why jsonperson overrides the method.
When opensocial 0.9 gets discussed on the spec list hopefully the fields on the javascript side will change to match the restful apis. At that time the "displayName" field will be part of the opensocial js spec and the jsonperson implementation can be pulled up to replace the person.js code.
Until then, person.js does not know that such a displayName field exists (because it isn't in the spec) and so shouldn't reference it.
Also, the comment on person.js still stand because that comment comes from the js spec, which hasn't changed. So, all restful/rpc container implementors must guarantee that the displayName person field is populated to remain compliant. That doesn't affect the js code though.
I'm not sure if I explained that well :)
Please let me know if you understand what I'm trying to get at.
Thanks!
> The restful/rpc apis should be producing a displayName field on the person object.
> -----------------------------------------------------------------------------------
>
> Key: SHINDIG-574
> URL: https://issues.apache.org/jira/browse/SHINDIG-574
> Project: Shindig
> Issue Type: Bug
> Components: RESTful API (Java)
> Reporter: Cassie Doll
> Assignee: Cassie Doll
> Priority: Blocker
>
> This should be a pretty easy change.
> - a String displayName field needs to be added to Person
> - the JsonDbContainer should fill it out
> - the javascript person.js should be changed to not implement getDisplayName
> - jsonperson.js should be changed to retrieve the displayName from the json from the server that it is constructed with
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-574) The restful/rpc apis should be
producing a displayName field on the person object.
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633839#action_12633839 ]
Cassie Doll commented on SHINDIG-574:
-------------------------------------
So, you are right, the user shouldn't have to care what person object is backing their js calls. However, the key point here is that the server -must- be returning a displayName from the restful/rpc calls in order for the js to guarantee a display name value. If the server always returned a value then jsonperson would be a perfectly fine impl of person.
Perhaps we should just make displayName a required field in the java restful code somehow?
It is in the main constructor but we don't have any sort of checks for required fields right now. We could put a simple check in the PersonHandler if we felt that was a good idea.
What do you think?
> The restful/rpc apis should be producing a displayName field on the person object.
> -----------------------------------------------------------------------------------
>
> Key: SHINDIG-574
> URL: https://issues.apache.org/jira/browse/SHINDIG-574
> Project: Shindig
> Issue Type: Bug
> Components: RESTful API (Java)
> Reporter: Cassie Doll
> Assignee: Cassie Doll
> Priority: Blocker
>
> This should be a pretty easy change.
> - a String displayName field needs to be added to Person
> - the JsonDbContainer should fill it out
> - the javascript person.js should be changed to not implement getDisplayName
> - jsonperson.js should be changed to retrieve the displayName from the json from the server that it is constructed with
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-574) The restful/rpc apis should be
producing a displayName field on the person object.
Posted by "Robert Bissett (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631515#action_12631515 ]
Robert Bissett commented on SHINDIG-574:
----------------------------------------
I see that jsonperson has been changed to include this function:
JsonPerson.prototype.getDisplayName = function() {
return this.getField("displayName");
}
but person, from which this object inherits, still implements getDisplayName with logic to create a name if the 'displayName' field is undefined (which is the case currently in Project SocialSite). So there is a conflict between the two files and the comments in person.js are now misleading that that the method is "guaranteed to return a useful string."
Can person.js be updated so that there is no conflict?
> The restful/rpc apis should be producing a displayName field on the person object.
> -----------------------------------------------------------------------------------
>
> Key: SHINDIG-574
> URL: https://issues.apache.org/jira/browse/SHINDIG-574
> Project: Shindig
> Issue Type: Bug
> Components: RESTful API (Java)
> Reporter: Cassie Doll
> Assignee: Cassie Doll
> Priority: Blocker
>
> This should be a pretty easy change.
> - a String displayName field needs to be added to Person
> - the JsonDbContainer should fill it out
> - the javascript person.js should be changed to not implement getDisplayName
> - jsonperson.js should be changed to retrieve the displayName from the json from the server that it is constructed with
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-574) The restful/rpc apis should be
producing a displayName field on the person object.
Posted by "Robert Bissett (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634496#action_12634496 ]
Robert Bissett commented on SHINDIG-574:
----------------------------------------
I think your point about the server is the main thing. If it's not returning the correct information, then the client code can't guarantee anything. I don't think it's worth the change to PersonHandler. Thanks for all the explanations.
> The restful/rpc apis should be producing a displayName field on the person object.
> -----------------------------------------------------------------------------------
>
> Key: SHINDIG-574
> URL: https://issues.apache.org/jira/browse/SHINDIG-574
> Project: Shindig
> Issue Type: Bug
> Components: RESTful API (Java)
> Reporter: Cassie Doll
> Assignee: Cassie Doll
> Priority: Blocker
>
> This should be a pretty easy change.
> - a String displayName field needs to be added to Person
> - the JsonDbContainer should fill it out
> - the javascript person.js should be changed to not implement getDisplayName
> - jsonperson.js should be changed to retrieve the displayName from the json from the server that it is constructed with
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-574) The restful/rpc apis should be
producing a displayName field on the person object.
Posted by "Robert Bissett (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633270#action_12633270 ]
Robert Bissett commented on SHINDIG-574:
----------------------------------------
Thanks for the explanation. I see now why there's a difference in the behavior between the two objects at least.
I still have a minor issue with the wording in the docs of person.js (but now at least I know jsonperson isn't wrong). If someone is writing a gadget that relies on the Person objects returned from some request, s/he may not know whether the container is implementing the new APIs yet or whether it supports rpc/rest/both. All that is known is that a person object is returned, since that's what's in the API (no JsonPerson in "OpenSocial API Reference (v0.8)"). However, given the way things are implemented now, in some containers this object will calculate a display name and in some containers it will return the displayName value from the back end, which may or may not exist (*). Therefore, the blanket "guaranteed to return a useful string" text is a little misleading without maybe some qualifying text.
If that makes sense, let me know and I can file an RFE. I see that this could go away in the 0.9 spec though, so it may not be worth the time. I'm just a stickler for API compliance, so if a JsonPerson "is" a Person, then it should do what Person says it does :)
(*) In the case of our container, we were relying on the behavior or person.getDisplayName. It's easy to work around though.
Cheers
> The restful/rpc apis should be producing a displayName field on the person object.
> -----------------------------------------------------------------------------------
>
> Key: SHINDIG-574
> URL: https://issues.apache.org/jira/browse/SHINDIG-574
> Project: Shindig
> Issue Type: Bug
> Components: RESTful API (Java)
> Reporter: Cassie Doll
> Assignee: Cassie Doll
> Priority: Blocker
>
> This should be a pretty easy change.
> - a String displayName field needs to be added to Person
> - the JsonDbContainer should fill it out
> - the javascript person.js should be changed to not implement getDisplayName
> - jsonperson.js should be changed to retrieve the displayName from the json from the server that it is constructed with
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SHINDIG-574) The restful/rpc apis should be
producing a displayName field on the person object.
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cassie Doll resolved SHINDIG-574.
---------------------------------
Resolution: Fixed
Assignee: Cassie Doll
> The restful/rpc apis should be producing a displayName field on the person object.
> -----------------------------------------------------------------------------------
>
> Key: SHINDIG-574
> URL: https://issues.apache.org/jira/browse/SHINDIG-574
> Project: Shindig
> Issue Type: Bug
> Components: RESTful API (Java)
> Reporter: Cassie Doll
> Assignee: Cassie Doll
> Priority: Blocker
>
> This should be a pretty easy change.
> - a String displayName field needs to be added to Person
> - the JsonDbContainer should fill it out
> - the javascript person.js should be changed to not implement getDisplayName
> - jsonperson.js should be changed to retrieve the displayName from the json from the server that it is constructed with
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.