Subject: Grouper Users - Open Discussion List
Re: [grouper-users] UI, Pagination and the Subject interface
- From: Chad La Joie <>
- Subject: Re: [grouper-users] UI, Pagination and the Subject interface
- Date: Fri, 21 Jan 2005 09:15:13 -0500
- Priority: normal
Here are some more naive questions as I try to come up to speed on Grouper.
The data source which you are pulling group information from can be
configured correct? Meaning University A could store their groups in an LDAP
while University B could store their groups in an relational database. If
that's the case a pagination API would need to be abstracted from any
particular data source.
Assuming people are subjects, are groups subjects too, or are groups some
other data object which contain subjects?
Just a few quick comments on the technical items Mark touched on.
* Hibernate does have API's for pagination (I'm sure Blair and probably Mark
saw them) which work pretty well. You usually end up have to write a wrapper
around them, but they do provide the base functionality.
* In regards to value list handling tag libs, I would suggest not use
Displaytag (which has a really bad interface for pagination) or Datagrid
(which is overly complicated for such a simple task). I've had not
experience with the Valuelist tags though that you also referenced.
Chad La Joie 315V St. Mary's Hall
Project Sentinel 202.687.0124
----- Original Message -----
From: Mark McLaren
Date: Thursday, January 20, 2005 12:59 pm
Subject: [grouper-users] UI, Pagination and the Subject interface
> 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
> best practices.
> I was looking at the Signet mockup
> (<http://middleware.internet2.edu/signet/mockup/main.html>), this
> 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!):
- Re: [grouper-users] UI, Pagination and the Subject interface, Chad La Joie, 01/21/2005
- Re: [grouper-users] UI, Pagination and the Subject interface, Tom Barton, 01/21/2005
Archive powered by MHonArc 2.6.16.