Grouper Developers Forum

[Jessica Bibbee <>]

Internet2 Middleware Initiative SW User Interface Development conference call 
February 2, 2005

*Attendees*
Tom Barton, U. Chicago (chair)
Shelley Henderson, USC
Brenden Bellina, USC
Blair Christensen, U. Chicago 
Gary Brown, U. Bristol 
Mark McLaren. U. Bristol
Andy Cohen, Stanford U.
Lynn McRae, Stanford U.
Jennifer Vine, Stanford U.
Minh Nguyen, Stanford U.
Scott Cantor, Ohio State U.
Chad La Joie, Georgetown U.
Walter Hoehn, U. Memphis
Steven Carmody, Brown U.
Peter DiCamillo, Brown U.
Ann West, EDUCAUSE/Internet2 
Jessica Bibbee, Internet2 (scribe)

*Action Items*
[AI] {Minh} will email the <grouper-dev> list with a list of tiles
that share similarities found in both Grouper and Signet.

[AI] {Gary} will circulate a description of a proposed generic tile 
controller.

[AI] {Gary} will draft conventions for directory layout of and build
procedures for I2MI source code packages.

[AI] {Tom} will organize a separate mailing list to handle all the
I2MI-UI discussions; items should be temporarily cross-posted with the
<grouper-dev> mailing list to capture the appropriate audience.

*Discussion* 
As Internet2 middleware software is being developed, particular
attention is paid to the similarities found amongst individual
strategies or elements that might be used for common purposes. This
call was designated in order to cultivate recent ideas regarding the
potential uses of adapterClasses, presentationClasses, tag libraries,
and other widgetry within User Interface methodology. It is the intent
to explore how to integrate UIs with external information sources for
multiple types of "subjects." Also discussed was the support of
site-specific customization of display elements. This discussion
reflects a continuation of efforts in support of emails sent to the
signet mailing list by {Lynn} and {Gary}. A document was recently
posted to the signet mailing list about adapterClasses and
presentationClasses, 
<https://mail.internet2.edu/wws/arc/signet/2005-01/msg00000.html>. For
more information on the Grouper UI architecture, see
<http://www.bris.ac.uk/ips-rojects/portal/groupsmanager/projectdoc/architecture/ui_architecture>.

We should give thought to proposed techniques and technology for the
integration of UIs with various external information classes, and how
might we implement these within a system. How do we go about
assembling these technologies with the UI, as we consider Grouper and
Signet? One item brewing in the initial presentation class is looking
at how to build on the technique of the adapter class – do a render
through a generic servlet, look at tiles –find a better
implementation. Basically, the switch has been made from using
adaptation classes to using tiles to create dynamic widgets; in the
future, we need to look at using Java space to do so. The idea of
using HTML in Java classes might offer flexibility initially, but
might create challenges in the long-term, when trying to do something
specific. The ideal route would be to use Java server spaces. This
approach will leave the door open to a wider range of people using the
UI. Java server spaces do not provide a mechanism lay out a page –
instead, you have an IDE where you drag and drop your widget; you copy
within the IDE for more efficient development of page design.  It
becomes more like a Java beans approach.

There might be the flexibility for us to create our own tile, but it
is dependent on the type of that context and how you would render that
object – you can define the code, or overwrite it as a sort of default
implementation. Another possibility is to have a controller generate
the HTML, and this offers flexibility to have a view of viewtypes – a
JSF or tile. There is an absence of present technology that allows a
site override function. We would need to be able to operate with a
default behavior that can be overridden by a site. A challenge is
presented, in that assumptions must be made, as a site may not know
ahead of time what they will want to override. Is this generic
controller something that a site would create independently, such that
Grouper would utilize it, as would Signet, for example? Yes, it would
be a sort of default system in how you would look for a specific key
based on a key – look for it, then come back to the default key before
trying the next, and ultimately ending up with a default key. This is
a low-cost, straightforward approach. We should work towards an
agreement, regarding the naming of algorithms that we use to find a
system type name.

What is this set of tiles, the override-able presentations or
operations, that are peculiar to the projects, and what problems do
they pose? Those built-in components within any subsystem like the UI;
Picking Scope has a tree, browse, browser, picker – someone might want
to override with something preferred in a given tile, which is site
specific. An example might be some default conditions, or the search
result. Another question leads to differentiating between the
descriptions of the architecture as a whole with the known pieces -
for example, the left-hand navigation bar is a part of the
application. One site might have a single-choice or multiple-choice
behavior, while another site may wish to override such behaviors.
There is also a need to limit or define something new – perhaps a
whole new widget; declare in the metadata, realtime.

Grouper is similar here; for example, it is difficult to know what the
custom group attributes are ahead of time. The entity, in this case,
is a group field object, which would have a specific name that might
not be known ahead of time. However, a key could include the name, and
is put into a tile of the JSP. If nothing is entered, a default will
be used. You could then choose to build that key up, based on known
groups – for example, groupfield, groupname, or whatever it is that
you are trying to render. This provides a way of working with
virtually any group field, as it is the name of the field that
determines which templates get pulled in. It is the intent for Grouper
to use these custom attributes, where attributes can be entered in
text boxes, and can then be updated, adding to the functionality.

If Signet at a site, for example, has the word developer,
administrator, owner of Signet itself – and if you wanted to make
Signet customized overall to your site, it would be a resource that
would support Signet as a site. This would mean contributed
maintenance or management of a subsystem; in a sense, some of the
widgets are contributed to Signet, regarding the layout of the
components within the applications; for example, libraries that are
overlaid by new installations, or not overlaid, in cases referring to
site-specific libraries.

There are two possible ways of doing this. You could 1) plan right and
impose the structure in a way that you know, or 2) specify the sub
project, where you would bring in and call your own
institution-specific changes. With any directory structure, working
with tiles and what they want to build – do this locally, make a
target, but it would be effectively billed from the UI. You must have
these two targets in the original bill target, and agree to copy
things as necessary.

The initial version of Grouper 0.5x would have the clean default
behaviors, and allow you to apply the specialization. This would be
straightforward, while providing an uncomplicated hook to add
something in. As for the 3rd party libraries that we are relying on
for the tiles, Struts <http://struts.apache.org> is the current
framework that we are using. There are no plans to add additional
dependencies, and it is important that everyone is communicates on
using the same 3rd party libraries, for cohesiveness.  Tiles do have a
specific configuration, an established standard in the UI.  However,
there is more flexibility with how we at Internet2 use the tiles. 
This stands, with the exception of {Gary's} idea of using a generic
controller, which would have its own configuration. [AI] {Gary} will
circulate a description of a proposed generic tile controller.

{Minh} expressed interest in coming up with a list of reusable tiles
that are used across both applications - standard headers footers,
tree tile, a tile to search and find a person, common images, or even
java script tiles, etc. These would fall under the I2MI directory. It
may not be possible to have separate tiles that include common
definitions combined with Signet tiles to provide a complete picture.
There will be some tiles that are shared – subjects in common, subject
information.  {Tom} agreed that it would be useful to have an I2MI-UI
directory, with a common UI. These sets of common tiles would be
sources for inclusion, standards for navigation, the subject interface
– all of these are found to be in common with Grouper and Signet. [AI]
{Minh} will email the <grouper-dev> list with a list of tiles that
share similarities found in both Grouper and Signet.  What other areas
might we envision these applications using portions of the other? It
will be necessary to have the ability to look up and find groups in
order to assign privileges. This would come through the subject
interface, where the group is a type of object. If Grouper already has
tiles for searching and displaying groups, there is no need to
reinvent the wheel.

This discussion will be continued over email, where it will reach a
larger audience. New topics might be generated, and it was agreed that
all would benefit from a separate mailing list devoted especially to
User Interface discussion. [AI] {Tom} will organize a separate mailing
list to handle all the I2MI-UI discussions; items should be
temporarily cross-posted with the <grouper-dev> mailing list to
capture the appropriate audience. You can locate subscription
information about the new Internet2 Middleware Initiative SW User
Interface Development <I2MI-UI> mailing list at either the Grouper
<http://middleware.internet2.edu/dir/groups/grouper/#List> or the
Signet websites <http://middleware.internet2.edu/signet/>. As with
other Internet 2 collaborative projects, participation is open to all
interested parties, subject to the Internet2 Intellectual Property
Framework: <http://members.internet2.edu/intellectualproperty.html>.

How much of the total Grouper UI personalities would in fact be loaded
in a set of tiles? Probably only a small part - for example, when you
find and search for a group, then display the results so someone could
directly select a group that is a target. This may not be necessary,
but it might be useful to view the membership. Though it might be
somewhat complicated, it is one of the ways that you could confirm the
group.

Are there any requirements to manage groups or characteristics?  The
group that you want, does not exist – so you have to create it. 
Rather than go through Signet, a second application might open – this
will keep things clean, so that you do not have to add or modify
information. You might be able to jump into using the class system to
find groups manager, for example. You would need some navigation, a
sort of umbrella around these applications – administrative
navigation, which would allow you to jump between 4+ applications.
This assumes that the UI is customizable; there would be a seamless
transfer of information. How do we bundle this into a super-tool for
full user ability?  We may not have the experience as of now to
understand what the functional requirements are. The discussion is a
good start for looking at consistency and how things might look – how
to plug things together.

Building conventions will go back to the UI, not only the API. [AI]
{Gary} will draft conventions for directory layout of and build
procedures for I2MI source code packages.

A related topic for Future discussion might be if we want to explore
HTML and how to implement dynamic content. There is an assumption that
learning Java script is a single round trip.

The next I2MI-UI conference call has yet to be established. Watch the
<grouper-dev> and <I2MI-UI> mailing lists for further information.