Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] RE: grouper 2.2 ui redsign

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] RE: grouper 2.2 ui redsign

Chronological Thread 
  • From: "McDermott, Michael" <>
  • To: Chris Hyzer <>
  • Cc: Jim Fox <>, Nathan Kopp <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] RE: grouper 2.2 ui redsign
  • Date: Sun, 23 Oct 2011 09:56:23 -0400

On Sat, Oct 22, 2011 at 1:50 PM, Chris Hyzer <> wrote:

Well, I want to leverage the existing lite UI screens, and when I created the lite UI, I considered that design (and even started down that path), it was not chosen because:


1.       I think a strongly typed language (Java) is the way to go for long term reliability / maintenance / low-cost / reducing-bugs / ease-to-debug / consistency-with-other-grouper-code / ability-to-unit-test / etc

I've seen plenty of terrible codebases in Java, and tight ones in Python or Ruby.  I don't think Java or static typing make web applications easier to maintain of debug.  Having programmers that care about such things is the leading indicator on whether or not they are built into a project (and Grouper is a case where maintainability is a cultural value).  

2.       _javascript_ is obviously necessary, but if you don’t have to write _javascript_ for each new UI piece (only at a framework level), then I think your app will be more likely to work across various browsers that you didn’t test for each UI piece

_javascript_ frameworks, being closer to web developers and their world, are probably more likely to be cross browser compatible than and Java Server based framework. 


3.       The UI has its own web services which are not packages into an unchanging API, but using the Grouper WS for the main admin UI would either be too limiting or not performant enough I think…


The sentiment I pull from Jim's comment is that if you have a robust web service API, it sets web developers free to do what they want to do.  I understand the concern about performance, but it may well be the case where the performance concerns come into play is where the MVC/Model2 layer all sit on the server. This may not be the case in a _javascript_ based application, the web services serve as a back end for the model layer which reside at the client.


At some point before too long I will make a wiki about how the UI works (the _javascript_/Java connector framework).  If you need to work with it, Im sure you will find it very easy to work with (easier than any other framework I have seen).

This would be great to see, maybe I'm talking about the same thing as you already envision, but just haven't grokked it yet.  

I guess my main use case is that I want to expose Grouper as a web service and let developers around campus use it, or use their "part of the tree" however they want, and not have to know Java or require our IdM group to build/incorparate components for them.


Note: David Champion made some other comments on the wiki which we will take into consideration






From: Jim Fox [mailto:]
Sent: Saturday, October 22, 2011 12:52 AM
To: Chris Hyzer; Nathan Kopp; Grouper Dev
Subject: RE: grouper 2.2 ui redsign


I know it's a bit of a rewrite, but have you considered implementing the UI entirely in _javascript_?  using the grouper webservice as a resource?  We do something like this at UW.  It has been quite successful.  It can make use of standard tools, e.g. dojo, and is easily customized.


From: [] on behalf of Chris Hyzer []
Sent: Friday, October 21, 2011 10:06 AM
To: Nathan Kopp; Grouper Dev
Subject: [grouper-dev] RE: grouper 2.2 ui redsign

Thanks, added those suggestions to the wiki.  A majority of Grouper deployers do not use CAS, and I want to leverage the existing “Lite UI” screens so I don’t think we will use Spring.  I think we do have includes for headers and footers, and things should be CSSable, but maybe we can discuss more specifics later on





From: [mailto:] On Behalf Of Nathan Kopp
Sent: Friday, October 21, 2011 1:00 PM
To: Grouper Dev
Subject: [grouper-dev] RE: grouper 2.2 ui redsign


I’ve got a few requests/suggestions for the new UI:


I’m not sure how many Grouper installers also use JA-SIG CAS, but we do, and I know that it would be helpful for us if the new Grouper UI used the same technologies as that of CAS, namely Spring MVC and Spring Web-Flow.  This would decrease the skill-sets necessary to customize and maintain an identity solution that includes both CAS and Grouper.


It would also be very convenient if the HTML structure was designed so it could be themed using CSS (along the lines of csszengarden) and if the JSP pages used customizable header and footer “includes” built in from the start.




From: [mailto:] On Behalf Of Chris Hyzer
Sent: Friday, October 21, 2011 12:29 PM
To: Grouper Dev
Subject: [grouper-dev] grouper 2.2 ui redsign


I have ideas for the Grouper UI 2.2 redesign, and I have discussed them with Shilen who will implement it with me.

I will consult with a user experience expert at Penn.  I don’t know how involved people want to be in this, but I will document progress on the wiki.  Here is a preliminary document, if you have suggestions or want to discuss something please edit the doc or let me know.


Check back periodically to the wiki to see how things are progressing… there will also be emails to this list about it…




Michael J. McDermott
Lead Developer, Identity and Access Management
Brown University

Archive powered by MHonArc 2.6.16.

Top of Page