Sounds good to me. The other option instead of a Xalan helper would be to simply pass the CAS Login Enabled flag as an XSLT parameter. That would be a little more efficient since the Xalan helper stuff results in new instances of the helper for every transformation. You should be able to inject the CAS Login status as a property with a placeholder, I think security.properties is used for property replacement in the portal app context.

-Eric

Jen Bourey wrote:
Hi all,

I'd like to propose changing the division of labor between the CLogin channel and the theme XSL. Historically the CLogin channel has been responsible for outputting the portal welcome message ("Welcome <yournamegoeshere>"), the CAS login link or local login form, and the logout link. When Gary first updated our XSL files for uPortal 3.0, he'd designed many of those components as XSL templates, but we didn't actually use them, since the theme didn't know the name of the user or CAS login URL.

In the current trunk, the theme does have access to the user's display name, and it isn't difficult to add a Xalan helper bean that can determine if CAS login is enabled and print the login URL. I'd like to take advantage of those two facts to begin outputting the login and logout URLs, as well as the welcome message from the XSL templates directly. After that refactoring, CLogin would only be responsible for printing out the login form for local login and any login-related authentication errors.

I think this change would help make per-theme styling of the welcome message and authentication links much simpler, as well as get us closer to the original design goals of the 3.0 refactoring. Does anyone have concerns about such a change?

- Jen


--
Jen Bourey
--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to