-Eric
Jen Bourey wrote:
OK, so we'd need someone to find a way to get those values injected into the theme. My understanding is that to date the header and footer channels have existed not for stylesheet reasons, but because the theme doesn't have access to that information. Eric, is that true? The header and footer channels are both cached; would setting that information in the theme instead cause any performance issues?- Jen Gary Thompson wrote:I doesn't. Yet :)I am hopeful we can change it, but currently, the header and login channels are still being called. I am not purposely trying to orchestrate the downfall of the those channels, but it would be best if the contents of the header and login channel could be customized the same as the rest of the theme and that any text being used in the theme would be localized like the rest. If nothing else, the standardization and simplification would be beneficial. But I am not familiar with what issues that might raise on the back end, and am certainly open to input to reach the best solution.Those changes may be for a 3.x release, along with dealing with the preferences.Gary Jen Bourey wrote:By the way, how does the theme get the information that used to be included in the header and footer channels? (username, date, uP version, etc.)- Jen Gary Thompson wrote:Eric,I am making good headway on the theme and hope to be finished by tomorrow. Here's a couple of notes as I am progressing:1. The theme assumes a parameter AUTHENTICATED with values of true or false. Is this state currently available to the theme? Jen had come up with a workaround for our 2.6 solution for Brooklyn, but it seems that the 2.6 theme had no knowledge of the authenticated state.2. All variables and parameters use an uppercase with underscores naming convention as in the case of AUTHENTICATED. This changes the name of some variables and parameters that are populated by the java. For instance, skin is now SKIN and baseActionURL is now BASE_ACTION_URL and isAjaxEnabled is now USE_AJAX.3. The theme takes the same approach as that of the now defunct uP3 branch in that it has an XSL file that is meant to be configured. The goal is to have all customization happen in this one XSL and leave the rest of the theme files untouched. I have found some really nice ways to allow customization of the resultant portal interface without having to alter the theme "code". In doing this, I believe that I have made both the footer channel obsolete. It might also be worth discussing whether or not to keep the header and login channels, or if they should also be included in the theme.I'll let you know if I think of anything else. Gary
smime.p7s
Description: S/MIME Cryptographic Signature
