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: Chris Hyzer <>
  • To: "GW Brown, Information Systems and Computing" <>, Emily Eisbruch <>, Grouper Dev <>
  • Subject: RE: [grouper-dev] Action Items: Grouper-dev call 7-Dec-2011
  • Date: Sun, 11 Dec 2011 20:24:56 +0000
  • Accept-language: en-US

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).getResults();
>
> 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




Archive powered by MHonArc 2.6.16.

Top of Page