Been thinking about this some more (and talking it over with Chico).
I can see why you need getPeople() and getPerson() methods exposed from
the PersonService, as these help adhere to the response specifications
for a single person object and a collection of entities.
Therefore, to adhere to the spec, we need to be able to pass down the
CollectionOptions to the getPerson() function so that the PersonService
can filter the output. It would be a little confusing to pass down
'Collection' options to something that returns a single object, so I
guess that object should be renamed. You could split off the collection
related options and filter options, but I think that would just be annoying.
Anyone have an opinion?
Cheers,
Ben Smith
BBC
On 5/2/09 13:39, Ben Smith wrote:
I'm currently getting our service layer to comply with the filtering
options described:
http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml#standardQueryParameters
This is particularly because I need to be able to support calls like:
/people/@me/@self?filter...@friends&filterOp=contains&filterValue=<someUserId>
The problem is that PersonService defines a getPerson method that does
not use CollectionOptions and PersonHandler will always call getPerson
for that URL:
if (userIds.size() == 1) {
if (optionalPersonId.isEmpty()) {
if (groupId.getType() == GroupId.Type.self) {
return personService.getPerson(userIds.iterator().next(),
fields, request.getToken());
Does anyone have a strategy for dealing with this? Would it be such a
bad thing if PersonService only exposed getPeople()?
Cheers,
Ben Smith
BBC
