Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011


Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Tom Barton <>,
  • Subject: Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
  • Date: Mon, 12 Dec 2011 14:51:26 +0000

--On 12 December 2011 08:31 -0600 Tom Barton
<>
wrote:

Gary & Chris,

From here on the sideline it seems as though something is missing from
your approach to this problem. Are you working on the same underlying
data set, ie, does Gary's have 74 Jo*'s and Chris' 8125 (or 8435)? Or
why are you each seeing two such different numbers?
I'm working against the QuickStart database, but I don't think the numbers are that critical. I'm sure on screen text can do away with any ambiguity.

By default the UI pages 50 results at a time - user can change to 10, 25, 50, 100. Independently, a source can be configured for a maximum number of results it will return (new feature). I don't see any problem with allowing a user to page up to that maximum - it is what I would expect.

The JIRA description is:

We need to remove paging buttons from subject search in admin ui, and if there are too many members (the SubjectFinder.findPage() method will tell you), then perhaps a message could be displayed that the user should narrow their search, and it should also show whatever members it found (e.g. the first 200 or whatever number is configured in the source).

I agree that it is worth letting the user see however many results are returned - but it would, in that example, be wrong to show all 200 in one page if the UI page size is set at 50.

If you search across all sources (the default) you could have too many results from only one of the sources, but not get to see the results from it.

Gary

Tom

On 12/12/2011 6:45 AM, Chris Hyzer wrote:
Is the resultset truncated because it is showing 50 of 74 items, or is
it truncated because it is showing 50 of 8125 items? When you click
"next", are you going to the next page of all results, or are you going
to the next page of a partial result set? It is misleading and we need
it removed (though as I said, if you want it there, leave an option so
that you can enable it no problem)... :)

Thanks,
Chris

-----Original Message-----
From: GW Brown, Information Systems and Computing
[mailto:]
Sent: Monday, December 12, 2011 4:01
AM
To: Chris Hyzer; Emily Eisbruch; Grouper Dev
Subject: RE: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011

The changes I checked in lead to the following:

Top of screen
-------------
Error: Too many results returned by one or more data sources -
displaying truncated result set. Please narrow your search

The summary
-----------
Showing 1-50 of 74 items (truncated result set)

I would have thought that was pretty clear...

Gary

--On 11 December 2011 20:24 +0000 Chris Hyzer
<>
wrote:

IF you do a search for "jo", and there are 8435 results, and the UI says
"There are too many results", and it say "displaying 1-50 of 149
results", that is misleading and incorrect. If there are really 8435
results, and the user sees that there are 149 results, and pages
through, and doesn't see the one they are looking for, it is really
bad. There is no reason to show the paging if we don't know how many
results there are (we got 149 results, but we don't know there are 8435
since that is not in the subject API), and if we cant page through all
the results. IF you disagree, then we need an option to not show the
paging on the screen, and it must default to not show the paging. We
do not want something on the UI that we know is misleading and
incorrect, but if you want to show it at your school, you have the
option to do that. Ok? :)

Thanks,
Chris

-----Original Message-----
From: GW Brown, Information Systems and Computing
[mailto:]
Sent: Saturday, December 10, 2011
11:23 AM
To: Chris Hyzer; Emily Eisbruch; Grouper Dev
Subject: RE: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011

--On 09 December 2011 22:02 +0000 Chris Hyzer
<>
wrote:

Also, in addition to my previous email, I forgot to respond to your
email below:

I think Chris was saying to ignore maxResults - in which case it
should be removed from the sample sources.xml. I can then see that
you can do:
Well, maxResults is useful if people do a SubjectFinder.findAll() as
opposed to SubjectFinder.findPage(). Since the UI and WS will do the
paging one, we can essentially ignore the masResults and focus on
maxPageSize, though I think it should still be in the
sources.example.properties in case people do the API findAll and in
general for belts and suspenders (if a subject source returns too many
results you can run out of memory on the server).
I haven't delved into the code to se where and how you are doing the
cutoffs, but is maxResults configured at the wrong level? i.e shouldn't
it relate to 'sources' rather than a specific subject source?

Gary
Thanks,
Chris

-----Original Message-----
From:

[mailto:]
On Behalf Of GW Brown,
Information Systems and Computing Sent: Thursday, December 08, 2011
4:16 PM
To: Emily Eisbruch; Grouper Dev
Subject: Re: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011

--On 07 December 2011 16:07 -0500 Emily Eisbruch
<>
wrote:

[AI] (Gary) will look at the issue of paging in the Admin UI
https://bugs.internet2.edu/jira/browse/GRP-716
I've looked at this again and still don't see a *paging* issue - The UI
appears to correctly page based on whatever number of results are
returned by the API - it doesn't care about what may have been
discarded.

I did find one inconsistency in the code. The UI does subject searches
in two classes:
1) DoSearchSubjectAction
2) SearchNewMembersAction

The former has:
results=source.search(processedSearchTerm);
but should have:

results=SubjectFinder.findPage(processedSearchTerm,sourceId).getResult
s( );

I'm not convinced by the semantics of:

<!-- if more than this many results are returned, then throw a too many
subjects exception -->
<init-param>
<param-name>maxResults</param-name>
<param-value>1000</param-value>
</init-param>

<!-- on a findPage() this is the most results returned -->
<init-param>
<param-name>maxPageSize</param-name>
<param-value>40</param-value>
</init-param>

(I set maxPageSize to 40 down from 100 for testing.)

I think Chris was saying to ignore maxResults - in which case it should
be removed from the sample sources.xml. I can then see that you can
do:

SearchPageResult spr = null;
spr = SubjectFinder.findPage(searchTerm);
results = spr.getResults();
if(spr.isTooManyResults()) {
request.setAttribute("message",
new Message("error.too.many.subject.results",true));
}

That way the retrieved results are shown but the user is alerted to the
fact the result set was truncated (error message might make that
clearer)

Chris: if that is what you want it is an easy enough change. If you
still think there is a UI paging issue you'll have to come up with a
screenshot...

Gary


----------------------
GW Brown, IT Services



----------------------
GW Brown, IT Services



----------------------
GW Brown, IT Services




----------------------
GW Brown, IT Services




Archive powered by MHonArc 2.6.16.

Top of Page