The 'cleanest' way is your third option, we put the unmodified CSS in ResourceServer and override all of the image URLs locally in uPortal but that seems really ugly. Would you be able to attach a patch for the changes on the uPortal side of things?
-Eric On 12/21/09 9:07 AM, Gary Thompson wrote:
I completed the work for linking to the FSS themes "as-is". Currently, it works like this:* Put FSS themes on the Resource Server, \webapps\ResourceServingWebapp\rs\fluid\1.1.2\css * Add the CSS link to skin.xml, <!-- Fluid Skinning System (FSS) theme. --><css type="fss-theme" name="fl-theme-mist">/ResourceServingWebapp/rs/fluid/1.1.2/css/fss-theme-mist.css</css>* Set the FSS class on the portal <body>, universality.xsl:<xsl:variable name="SKIN_CONFIG_URL" select="concat('../../../../../',$SKIN_PATH,'/skin.xml')"/> <xsl:variable name="FLUID_THEME" select="document($SKIN_CONFIG_URL)/s:resources/c...@type='fss-theme']/@name"/><xsl:variable name="FLUID_THEME_CLASS"> <xsl:choose><xsl:when test="$FLUID_THEME"><xsl:value-of select="$FLUID_THEME"/></xsl:when><xsl:otherwise>fl-theme-uportal</xsl:otherwise> </xsl:choose> </xsl:variable> and page.xsl (unchanged): <body id="portal" class="up {$FLUID_THEME_CLASS}">I did run into an issue. The FSS theme CSS files reference images with a relative url, for example: .fl-theme-mist .fl-button-left {background-image:url(../images/themes/mist/buttons-med-cap.png);}The problem is that from the physical location where the CSS is linked in, \webapps\uPortal It can't find those images.As an immediate fix, I replaced all the image urls with a reference like this: .fl-theme-mist .fl-button-left {background-image:url(/ResourceServingWebapp/rs/fluid/1.1.2/css/images/themes/mist/buttons-med-cap.png);}Which works, but now we have a modified versions of the files. So my question is, do we serve up the CSS and associated images for FSS themes from the Resource Server (which is for UNMODIFIED, 3rd-party resources), or do we put them in the uPortal source with the skins (as MODIFIED 3rd-party resources)? A third solution - truer to the clean division of uPortal code and 3rd-party resources, but messier in the CSS - would be to serve the unmodified FSS theme files from the Resource Server, and put CSS overrides for all of the image references in the portal.css file.Thoughts? Gary Thompson User Experience Leader Unicon | www.unicon.net ----- Original Message ----- From: "Gary Thompson" <g...@unicon.net> To: uportal-dev@lists.ja-sig.org Cc: "jasig-ue" <jasig...@lists.ja-sig.org>Sent: Friday, December 18, 2009 2:11:29 PM GMT -07:00 U.S. Mountain Time (Arizona)Subject: Re:[uportal-dev] uPortal skin CSS Updates and more ideas for uPortal skin CSS:1. Thanks Jen for completing the work to combine and rename the skin CSS files (http://www.ja-sig.org/issues/browse/UP-2389). The simplicity is fantastic.2. As a follow-up I completed UP-2525 (http://www.ja-sig.org/issues/browse/UP-2525) to restructure and clean up the Ivy skin.While I was working with the skins, these thoughts occurred to me and I would like to offer them as suggestions:3. It would be great to use Fluid Skinning System themes "as-is" and (like all the other 3rd party stuff) keep them separate. This would make it easier to upgrade FSS, and we could hopefully see more efficiency, especially as we hope to move more of the portlet CSS into FSS. This keep the portal.css file simpler, though in the near-term their might still be a fair number of overrides to the FSS theme. We can include the FSS themes on the Resource Server with the rest of the Fluid files, and if necessary, a skin could create a local FSS theme if needed. I believe that with the new aggregator, we can simply call the FSS theme CSS in skin.xml, then remove the FSS theme CSS from portlet.css, which would then only contain FSS overrides.4. If #3 is accomplished, I think we could quickly generate a couple more default skins to ship with uPortal based off of the exisiting FSS themes (coal, mist, rust, high-contrast), which would be a nice addition.I know it is getting late in the release cycle to add this additional change (#3), but I believe it could be accomplished quickly.Gary Thompson User Experience Leader Unicon | www.unicon.net -- 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
smime.p7s
Description: S/MIME Cryptographic Signature
