> What happens in a CAS deployment is that the login JSP files are input to > creative professionals who then customize the JSP, craft the markup and CSS > and even JavaScript, apply the institutional brand, and get to the central > login experience for the institution adopting CAS, right?
That's what happens for big deployments, yes; farm out the UI to the UX folks and get back beautiful stuff that devs or deployers shove into place. That's what we did for the login UI you cited (except I did the UI, which is why it's far from beautiful). For small deployments the default UI in many cases is sufficient except for the logo and possibly the color scheme/theme. I'd love to see a way that you can skin the login UI without touching the JSP files to support those folks. As soon as you customize the JSP files, you're into Maven Overlay world, which is a high bar for the Unix guy that gets stuck trying to set up a small CAS deployment. Telling him to configure a cas.properties file that has the following would be infinitely better: cas.css.url = file:///opt/local/cas/my.css cas.logo.url = file:///opt/local/cas/my-logo.png I have a lot of sympathy for that poor Unix guy. I really want to make his life easier for a CAS deployment. > I don't relate to the allusion to an installer. No installer wizard would > be sufficient to get to a login UI appropriate to the central authentication > brand of most CAS adopters. Perhaps a bad analogy. But the core idea is that I agree there are UI elements that are commonly changed, and I would argue that CSS file and logo are the two most common. We could easily factor those out of the UI into a properties file and require editing as part of deployment, where the installer is a person instead of software. >Just better starting JSP > templates that are more helpful to the adopters starting from those > templates. I'm fine with the JSP files serving as templates that are driven in part from a properties file with common configurable UI components; you can always edit the JSP if the templates don't serve you. I still don't think, however, that deployer instructions are unsuitable for those templates. As a compromise, how about one-time messages driven by some kind of simple logic implemented in code. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
