Subject: Grouper Users - Open Discussion List
- From: Mark McLaren <>
- Subject: UI, Pagination and the Subject interface
- Date: Thu, 20 Jan 2005 17:59:09 +0000
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=CZU58U0o7/ZDIEUkvrC+VIXtvHBQu0UFSzNkl3dZCYZjr8sS9qtnaJR8i4GBn2sM9N3sCaQc0k+t5oZXM1Qn3XWiHC96q5Xg4aGFhIJmgAdYtQ+GSsCckNHIFwkmLRIMX+eGgxpOUs9D8Vt0oYN+y0Rw2oqLXcECNRowtvlsEUI=
I have some naive comments to make (I hope not too naive), I
appreciate they may concern future API Search and Browse
functionality. I'll make them here initially as they concern the
Grouper API but if people feel somewhere else might be more
appropriate I'd be happy to take them forward to other forums.
Recently, I've been thinking about the Grouper UI, the Grouper API and
trying to acquaint myself with how Hibernate works and identify some
I was looking at the Signet mockup
struck me as the kind of functionality that I've seen in several third
party taglibs that I have come across on my internet travels.
I'm sure there are also others taglibs with this capability available.
Are there any plans to introduce some kind of pagination functionality
into the subject interface and group "finder" methods of the Grouper
API (to borrow a term from EJB arena)?
In a fully implemented Groups Registry many thousands of groups could
be returned from a single query (unless I've misunderstood something).
It strikes me that if the Grouper API is acting as an intermediary (a
Data Access Object[DAO] or proxy) between the Grouper UI and a source
of Subject data that there will be a high probability that a casual
search for "Smith" could result in many thousands of results returned
Obviously performance (time) and resource capacity (memory, network
load etc) are issues relating to paginating objects question but there
are also some quite subtle issues that an "unpaginated" model could
trip over. For instance the LDAP server at Bristol has a maximum
limit on the number of records it is happy to return to a given an
anonymous query to prevent wholesale downloading the the LDAP
directory. If we are not careful we could fall foul of this kind of
thing if we assumed that we had received all the results from a query
and had no pagination mechanism.
Are there any thoughts on this? Has it been discussed elsewhere or in
any of the existing groups literature that I've missed?
Other pagination related references I looked at (I'm sorry about this
I'm something of a link philanthropist!):
- UI, Pagination and the Subject interface, Mark McLaren, 01/20/2005
- Re: [grouper-users] UI, Pagination and the Subject interface, blair christensen, 01/20/2005
Archive powered by MHonArc 2.6.16.