You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Ben Smith <be...@gmail.com> on 2009/02/05 14:39:22 UTC
PersonService precludes filtering
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?filterBy=@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
Re: PersonService precludes filtering
Posted by Ben Smith <be...@gmail.com>.
FYI: I've created a simple patch[1]. No worries if there is a prefered
solution, I just want to push this issue as we want to deliver this
functionality asap.
Cheers,
Ben Smith
BBC
[1] https://issues.apache.org/jira/browse/SHINDIG-904
On 6/2/09 10:47, Ian Boston wrote:
> Sorry, yes you are right, re-reading the spec more carefully.
>
> Does that change the call to getPeople() or just the underlying
> implementation.
>
> I would rather not change the getPerson() signature when correct use
> of getPeople() even with a collection of 1 has the required
> functionality.
>
> I think however what is confusing is the layered functionality of the
> getPeople query, and the overlaid meaning of /people/@me/@self to mean
> the object in on instance and the existence of a friend in another.
>
> To my mind /people/@me/@friends/{friendGuid} which returns the friend
> if the fiend is a friend, and a blank or 404 if not. But that is a
> spec issue.
>
> Is it worth bringing up on the spec list or are the URL semantics Ok?
>
> Ian
>
>
>
> On 6 Feb 2009, at 10:27, Ben Smith wrote:
>
>> My interpretation of
>> /people/@me/@self?filterBy=@friends&filterOp=contains&filterValue=<someUserId>
>> seems to be different from yours.
>>
>> I understood it to mean that, as long as you are friends with
>> <someUserId>, then you would get the same response as a straight call
>> to /people/@me/@self. If, however, you are not friends, then you
>> would get back an empty response, as that person (you) whould have
>> been filtered.
>>
>> To return a collection, with it's full RestfulCollection wrapper and
>> entries, for the same resource /people/@me/@self, if you send a
>> different query string, would be pretty un-RESTful.
>>
>> This means that these requests have to be served by getPerson(), as
>> they return the single object that gets marshaled as a
>> <response><person>..</person></response>.
>>
>> On 6/2/09 10:19, Ian Boston wrote:
>>> Well, I am not certain that a change to the interface is required
>>> since the handler should be calling getPeople if the
>>> CollectionOptions are specified and then the implementation of
>>> getPeople should be able to work out that its a friends query.
>>>
>>> Naming, thats debatable:
>>> One view is that the query string specifically relates to how the
>>> collection that is returned should be filtered and sorted and not
>>> generic options on the whole request, in which case
>>> CollectionOptions is correct.
>>>
>>> The other view is that this is a generic container for all request
>>> options, which if true RequestOptions is correct.
>>>
>>> Looking at CollectionOptions as it stands, IMHO its the former. What
>>> could be helpful is better javadoc on the class, there is plenty on
>>> the methods just none on the class (me bad I think).
>>>
>>> Ian
>>>
>>>
>>> On 6 Feb 2009, at 09:58, Ben Smith wrote:
>>>
>>>> A simple fix would be to include passing CollectionOptions to
>>>> PersonService. This would mean that the implementations can perform
>>>> the appropriate filtering. I'd also recommend renaming
>>>> CollectionOptions to RequestOptions as this would be less confusing.
>>>>
>>>> I'm happy to supply a patch for this, but I'd like some steer from
>>>> the community as this will require everyone tracking the trunk to
>>>> change their interface.
>>>>
>>>> On 6/2/09 09:50, Ian Boston wrote:
>>>>> I think the handler is wrong.
>>>>> Although the URL is pointing to the person profile of the current
>>>>> user /people/@me/@self
>>>>> The query is selecting the friend collection within that person
>>>>> and filtering it by the supplied user ID.
>>>>>
>>>>> ie is someUserId one of the current users friends ?
>>>>>
>>>>> The implementation is just getting the person object and
>>>>> completely ignoring the filter on the friends collection.
>>>>> IMHO, the PersonHandler needs to be fixed.
>>>>>
>>>>> Naturally the bare url should return the person, so getPerson() is
>>>>> valid.
>>>>>
>>>>> In the light of the above, the PersonService might also be
>>>>> lacking, I hope to get some time soon to do some 0.9 work.
>>>>>
>>>>> Ian
>>>>>
>>>>>
>>>>> On 6 Feb 2009, at 09:10, Ben Smith wrote:
>>>>>
>>>>>> 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?filterBy=@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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: PersonService precludes filtering
Posted by Ben Smith <be...@gmail.com>.
On 6/2/09 10:47, Ian Boston wrote:
> Sorry, yes you are right, re-reading the spec more carefully.
>
> Does that change the call to getPeople() or just the underlying
> implementation.
Should just be the underlying implementation. All the necessary
information is in the method signature.
> I would rather not change the getPerson() signature when correct use
> of getPeople() even with a collection of 1 has the required
> functionality.
>
> I think however what is confusing is the layered functionality of the
> getPeople query, and the overlaid meaning of /people/@me/@self to mean
> the object in on instance and the existence of a friend in another.
>
> To my mind /people/@me/@friends/{friendGuid} which returns the friend
> if the fiend is a friend, and a blank or 404 if not. But that is a
> spec issue.
The problem is, the response from getPeople will not suffice (I hoped it
would) as it returns a RestfulCollection:
<response><entry><person></person></entry></response> while getPerson()
just returns a Person: <response><person></person></response>. While I
have my own personal feelings on the spec's format, we need to honor the
difference in response between getPerson requests (/people/@me/@self and
/people/@me/@friends/{friendGuid}) and getPeople requests
(/people/@me/@friends...).
> Is it worth bringing up on the spec list or are the URL semantics Ok?
There are problems with the semantics, but we can simply deal with this
specific problem by passing CollectionOptions to getPerson() and have
the implementation deal with it. Any other solution requires changing
the spec or adding more complexity to PersonHandler.
If you think it's worth bringing up on the spec list for a longer-term
resolution, then I'm happy to.
Still might be worth renaming CollectionOptions.
> Ian
Ben
Re: PersonService precludes filtering
Posted by Ian Boston <ie...@tfd.co.uk>.
Sorry, yes you are right, re-reading the spec more carefully.
Does that change the call to getPeople() or just the underlying
implementation.
I would rather not change the getPerson() signature when correct use
of getPeople() even with a collection of 1 has the required
functionality.
I think however what is confusing is the layered functionality of the
getPeople query, and the overlaid meaning of /people/@me/@self to mean
the object in on instance and the existence of a friend in another.
To my mind /people/@me/@friends/{friendGuid} which returns the friend
if the fiend is a friend, and a blank or 404 if not. But that is a
spec issue.
Is it worth bringing up on the spec list or are the URL semantics Ok?
Ian
On 6 Feb 2009, at 10:27, Ben Smith wrote:
> My interpretation of /people/@me/@self?
> filterBy=@friends&filterOp=contains&filterValue=<someUserId> seems
> to be different from yours.
>
> I understood it to mean that, as long as you are friends with
> <someUserId>, then you would get the same response as a straight
> call to /people/@me/@self. If, however, you are not friends, then
> you would get back an empty response, as that person (you) whould
> have been filtered.
>
> To return a collection, with it's full RestfulCollection wrapper and
> entries, for the same resource /people/@me/@self, if you send a
> different query string, would be pretty un-RESTful.
>
> This means that these requests have to be served by getPerson(), as
> they return the single object that gets marshaled as a
> <response><person>..</person></response>.
>
> On 6/2/09 10:19, Ian Boston wrote:
>> Well, I am not certain that a change to the interface is required
>> since the handler should be calling getPeople if the
>> CollectionOptions are specified and then the implementation of
>> getPeople should be able to work out that its a friends query.
>>
>> Naming, thats debatable:
>> One view is that the query string specifically relates to how the
>> collection that is returned should be filtered and sorted and not
>> generic options on the whole request, in which case
>> CollectionOptions is correct.
>>
>> The other view is that this is a generic container for all request
>> options, which if true RequestOptions is correct.
>>
>> Looking at CollectionOptions as it stands, IMHO its the former.
>> What could be helpful is better javadoc on the class, there is
>> plenty on the methods just none on the class (me bad I think).
>>
>> Ian
>>
>>
>> On 6 Feb 2009, at 09:58, Ben Smith wrote:
>>
>>> A simple fix would be to include passing CollectionOptions to
>>> PersonService. This would mean that the implementations can
>>> perform the appropriate filtering. I'd also recommend renaming
>>> CollectionOptions to RequestOptions as this would be less confusing.
>>>
>>> I'm happy to supply a patch for this, but I'd like some steer from
>>> the community as this will require everyone tracking the trunk to
>>> change their interface.
>>>
>>> On 6/2/09 09:50, Ian Boston wrote:
>>>> I think the handler is wrong.
>>>> Although the URL is pointing to the person profile of the current
>>>> user /people/@me/@self
>>>> The query is selecting the friend collection within that person
>>>> and filtering it by the supplied user ID.
>>>>
>>>> ie is someUserId one of the current users friends ?
>>>>
>>>> The implementation is just getting the person object and
>>>> completely ignoring the filter on the friends collection.
>>>> IMHO, the PersonHandler needs to be fixed.
>>>>
>>>> Naturally the bare url should return the person, so getPerson()
>>>> is valid.
>>>>
>>>> In the light of the above, the PersonService might also be
>>>> lacking, I hope to get some time soon to do some 0.9 work.
>>>>
>>>> Ian
>>>>
>>>>
>>>> On 6 Feb 2009, at 09:10, Ben Smith wrote:
>>>>
>>>>> 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?
>>>>>> filterBy=@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
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: PersonService precludes filtering
Posted by Ben Smith <be...@gmail.com>.
My interpretation of
/people/@me/@self?filterBy=@friends&filterOp=contains&filterValue=<someUserId>
seems to be different from yours.
I understood it to mean that, as long as you are friends with
<someUserId>, then you would get the same response as a straight call to
/people/@me/@self. If, however, you are not friends, then you would get
back an empty response, as that person (you) whould have been filtered.
To return a collection, with it's full RestfulCollection wrapper and
entries, for the same resource /people/@me/@self, if you send a
different query string, would be pretty un-RESTful.
This means that these requests have to be served by getPerson(), as they
return the single object that gets marshaled as a
<response><person>..</person></response>.
On 6/2/09 10:19, Ian Boston wrote:
> Well, I am not certain that a change to the interface is required
> since the handler should be calling getPeople if the CollectionOptions
> are specified and then the implementation of getPeople should be able
> to work out that its a friends query.
>
> Naming, thats debatable:
> One view is that the query string specifically relates to how the
> collection that is returned should be filtered and sorted and not
> generic options on the whole request, in which case CollectionOptions
> is correct.
>
> The other view is that this is a generic container for all request
> options, which if true RequestOptions is correct.
>
> Looking at CollectionOptions as it stands, IMHO its the former. What
> could be helpful is better javadoc on the class, there is plenty on
> the methods just none on the class (me bad I think).
>
> Ian
>
>
> On 6 Feb 2009, at 09:58, Ben Smith wrote:
>
>> A simple fix would be to include passing CollectionOptions to
>> PersonService. This would mean that the implementations can perform
>> the appropriate filtering. I'd also recommend renaming
>> CollectionOptions to RequestOptions as this would be less confusing.
>>
>> I'm happy to supply a patch for this, but I'd like some steer from
>> the community as this will require everyone tracking the trunk to
>> change their interface.
>>
>> On 6/2/09 09:50, Ian Boston wrote:
>>> I think the handler is wrong.
>>> Although the URL is pointing to the person profile of the current
>>> user /people/@me/@self
>>> The query is selecting the friend collection within that person and
>>> filtering it by the supplied user ID.
>>>
>>> ie is someUserId one of the current users friends ?
>>>
>>> The implementation is just getting the person object and completely
>>> ignoring the filter on the friends collection.
>>> IMHO, the PersonHandler needs to be fixed.
>>>
>>> Naturally the bare url should return the person, so getPerson() is
>>> valid.
>>>
>>> In the light of the above, the PersonService might also be lacking,
>>> I hope to get some time soon to do some 0.9 work.
>>>
>>> Ian
>>>
>>>
>>> On 6 Feb 2009, at 09:10, Ben Smith wrote:
>>>
>>>> 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?filterBy=@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
>>>>
>>>
>>>
>>
>
>
Re: PersonService precludes filtering
Posted by Ian Boston <ie...@tfd.co.uk>.
Well, I am not certain that a change to the interface is required
since the handler should be calling getPeople if the CollectionOptions
are specified and then the implementation of getPeople should be able
to work out that its a friends query.
Naming, thats debatable:
One view is that the query string specifically relates to how the
collection that is returned should be filtered and sorted and not
generic options on the whole request, in which case CollectionOptions
is correct.
The other view is that this is a generic container for all request
options, which if true RequestOptions is correct.
Looking at CollectionOptions as it stands, IMHO its the former. What
could be helpful is better javadoc on the class, there is plenty on
the methods just none on the class (me bad I think).
Ian
On 6 Feb 2009, at 09:58, Ben Smith wrote:
> A simple fix would be to include passing CollectionOptions to
> PersonService. This would mean that the implementations can perform
> the appropriate filtering. I'd also recommend renaming
> CollectionOptions to RequestOptions as this would be less confusing.
>
> I'm happy to supply a patch for this, but I'd like some steer from
> the community as this will require everyone tracking the trunk to
> change their interface.
>
> On 6/2/09 09:50, Ian Boston wrote:
>> I think the handler is wrong.
>> Although the URL is pointing to the person profile of the current
>> user /people/@me/@self
>> The query is selecting the friend collection within that person and
>> filtering it by the supplied user ID.
>>
>> ie is someUserId one of the current users friends ?
>>
>> The implementation is just getting the person object and completely
>> ignoring the filter on the friends collection.
>> IMHO, the PersonHandler needs to be fixed.
>>
>> Naturally the bare url should return the person, so getPerson() is
>> valid.
>>
>> In the light of the above, the PersonService might also be lacking,
>> I hope to get some time soon to do some 0.9 work.
>>
>> Ian
>>
>>
>> On 6 Feb 2009, at 09:10, Ben Smith wrote:
>>
>>> 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?
>>>> filterBy=@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
>>>
>>
>>
>
Re: PersonService precludes filtering
Posted by Ben Smith <be...@gmail.com>.
A simple fix would be to include passing CollectionOptions to
PersonService. This would mean that the implementations can perform the
appropriate filtering. I'd also recommend renaming CollectionOptions to
RequestOptions as this would be less confusing.
I'm happy to supply a patch for this, but I'd like some steer from the
community as this will require everyone tracking the trunk to change
their interface.
On 6/2/09 09:50, Ian Boston wrote:
> I think the handler is wrong.
> Although the URL is pointing to the person profile of the current user
> /people/@me/@self
> The query is selecting the friend collection within that person and
> filtering it by the supplied user ID.
>
> ie is someUserId one of the current users friends ?
>
> The implementation is just getting the person object and completely
> ignoring the filter on the friends collection.
> IMHO, the PersonHandler needs to be fixed.
>
> Naturally the bare url should return the person, so getPerson() is valid.
>
> In the light of the above, the PersonService might also be lacking, I
> hope to get some time soon to do some 0.9 work.
>
> Ian
>
>
> On 6 Feb 2009, at 09:10, Ben Smith wrote:
>
>> 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?filterBy=@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
>>
>
>
Re: PersonService precludes filtering
Posted by Ian Boston <ie...@tfd.co.uk>.
I think the handler is wrong.
Although the URL is pointing to the person profile of the current
user /people/@me/@self
The query is selecting the friend collection within that person and
filtering it by the supplied user ID.
ie is someUserId one of the current users friends ?
The implementation is just getting the person object and completely
ignoring the filter on the friends collection.
IMHO, the PersonHandler needs to be fixed.
Naturally the bare url should return the person, so getPerson() is
valid.
In the light of the above, the PersonService might also be lacking, I
hope to get some time soon to do some 0.9 work.
Ian
On 6 Feb 2009, at 09:10, Ben Smith wrote:
> 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?
>> filterBy=@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
>
Re: PersonService precludes filtering
Posted by Ben Smith <be...@gmail.com>.
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?filterBy=@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