This would be a particularly helpful piece of information to be captured in the manual. Could someone volunteer to find a place for it?
Thanks, Jonathan ---------- Forwarded message ---------- From: Jen Bourey <[email protected]> Date: Wed, Mar 25, 2009 at 9:35 AM Subject: Re: [jasig-ue] Stylesheet imports in uPortal 3.1.x To: [email protected] Hi Kathy, You're correct; the code actually does cache the javascript and CSS resources. Right now all javascript and CSS resources are GZipped by a servlet filter, and since these resources are the same for all users and aren't expected to change frequently in a production environment, the filter is optimized to cache the GZipped result for a short time period. However, I've also found that it's not particularly convenient while doing skin development. If you'd like to turn this feature off during development, you can comment out the filter mapping for the pageCachingFilter in webxml: <!-- Temporarily commenting out this filter for development purposes --> <!--<filter-mapping> <filter-name>pageCachingFilter</filter-name> <url-pattern>*.js</url-pattern> <url-pattern>*.css</url-pattern> </filter-mapping>--> - Jen On Wed, Mar 25, 2009 at 9:10 AM, Moore, Kathleen E <[email protected]> wrote: > I routinely use shift-reload, and I’ve tried “Clear Private Data” in FF > and “Delete Files” in IE. Nothing but stop and restart seems to work, in > either FF or IE (win). > > > > (If this were a local caching issue, would restarting the server even fix > it?) > > > > Kathy > > > > Kathleen Moore > > Web Manager > > Boston University School of Management > > [email protected] > > 617-353-2685 > > > > *From:* Eric Dalquist [mailto:[email protected]] > *Sent:* Tuesday, March 24, 2009 4:32 PM > *To:* [email protected] > *Subject:* Re: [jasig-ue] Stylesheet imports in uPortal 3.1.x > > > > CSS shouldn't be cached in memory on the server but a cache header is set. > Try using shift-reload on the page while developing to force the browser to > re-request locally cached CSS. > > -Eric > > Moore, Kathleen E wrote: > > I’m so glad you asked! > > > > As someone who is, as we speak, trying to skin the new 3.1 release, I’m > horrified at the idea of requiring a build to deploy the css. I’ve had to > argue with developers here who want me to work in the build, but it’s almost > impossible to do visual work that way. Working in the deployed css files > gives me prompt feedback about css changes. > > > > And since you seem to know something about how this works—it seems that the > new release caches css in a way that older releases didn’t. The build > doesn’t display css changes until I stop and restart the server. An older > version of uPortal even let us turn off xsl caching—also useful for > development purposes. Is there a key to this hidden somewhere? > > > > Thanks! > > > > Kathleen Moore > > Web Manager > > Boston University School of Management > > [email protected] > > 617-353-2685 > > > > *From:* [email protected] > [mailto:[email protected]<[email protected]>] > *On Behalf Of *Jen Bourey > *Sent:* Tuesday, March 24, 2009 4:06 PM > *To:* [email protected] > *Subject:* [jasig-ue] Stylesheet imports in uPortal 3.1.x > > > > Hello all, > > I wanted to open up discussion about our options for decreasing the number > of HTTP requests for CSS stylesheets in the uPortal 3.1 branch. Currently > the portal's skins generally import some shared default resources from the > new ResourceServingWebapp and from the theme's common area. These resources > include the jQuery UI default theme, the Fluid Skinning System (FSS)'s > standard resources, and a base uPortal-specific layout.css file. The skin > then overrides and adds to these more general CSS styles, generally through > including several more stylesheets. > > While I think the above works well from a development standpoint, we > currently have 14 HTTP requests for CSS stylesheets just for the base > uPortal content (i.e., this count doesn't include any stylesheets for > portlets present on the page). I'd really like to get this number down as > much as we can, while making sure we have a skin organization that's > reasonable to work with. > > My current proposal is that we leave the existing structure as is, but make > use of the maven yui-compressor plugin to aggregate the required files at > build time. This would allow us to continue to have separate, appropriately > named files, but only require the user's browser to download one or two CSS > file per skin. For example, we might create aggregated files as follows: > > <aggregations> > <!-- Create the shared Fluid Skinning System stylesheet --> > <aggregation> > > <output>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css</output> > <includes> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css</include> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css</include> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css</include> > </includes> > </aggregation> > > <!-- Create the uPortal3 skin stylesheet --> > <aggregation> > > <output>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css</output> > <includes> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css</include> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css</include> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css</include> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css</include> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css</include> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css</include> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css</include> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css</include> > > <include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css</include> > </includes> > </aggregation> > > <!-- More skins here . . . --> > </aggregations> > > > One disadvantage of this approach is that it would likely be less > transparent to adopters how the CSS is being assembled. I'd imagine that > we'd at least want to have a README file in the skins/uportal3 directory > that commented on the approach. > > Thoughts? > > - Jen > > > -- > Jen Bourey > > -- > > > > > > > > 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/jasig-ue > > > > > > > > > > -- > > > > 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/jasig-ue > > > > > > > > > > > -- > > 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/jasig-ue > > > > > > -- Jen Bourey -- 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/jasig-ue -- 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/uportal-dev
