Stylesheet imports in uPortal 3.1.x

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Stylesheet imports in uPortal 3.1.x

Jen Bourey
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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

Reply | Threaded
Open this post in threaded view
|

RE: Stylesheet imports in uPortal 3.1.x

Kathy Moore

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

[hidden email]

617-353-2685

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jen Bourey
Sent: Tuesday, March 24, 2009 4:06 PM
To: [hidden email]
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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    

-- 
You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet imports in uPortal 3.1.x

Eric Dalquist
In reply to this post by Jen Bourey
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

[hidden email]

617-353-2685

 

From: [hidden email] [[hidden email]] On Behalf Of Jen Bourey
Sent: Tuesday, March 24, 2009 4:06 PM
To: [hidden email]
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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    

-- 

You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Stylesheet imports in uPortal 3.1.x

Kathy Moore

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

[hidden email]

617-353-2685

 

From: Eric Dalquist [mailto:[hidden email]]
Sent: Tuesday, March 24, 2009 4:32 PM
To: [hidden email]
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

[hidden email]

617-353-2685

 

From: [hidden email] [[hidden email]] On Behalf Of Jen Bourey
Sent: Tuesday, March 24, 2009 4:06 PM
To: [hidden email]
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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    

 

-- 
 
You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    
  

-- 
You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet imports in uPortal 3.1.x

Jen Bourey-2
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 <[hidden email]> 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

[hidden email]

617-353-2685

 

From: Eric Dalquist [mailto:[hidden email]]
Sent: Tuesday, March 24, 2009 4:32 PM

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

[hidden email]

617-353-2685

 

From: [hidden email] [[hidden email]] On Behalf Of Jen Bourey
Sent: Tuesday, March 24, 2009 4:06 PM
To: [hidden email]
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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    

 

-- 
 
You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    
  

-- 
You are currently subscribed to [hidden email] as: [hidden email] 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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet imports in uPortal 3.1.x

Jen Bourey-2
In reply to this post by Kathy Moore
Hi Kathy,

I'm totally sympathetic to your concerns about skin development, and I want to make sure we balance the needs of developers and end-users.  I've been thinking about your concerns and I've come up with a few proposals, although I'd very much like your feedback.

One strategy might be to use the build process I identified, but keep a file called "uportal3.min.css" in the source directory.  This file could import all the stylesheets we're aggregating together at build time using the @import syntax.  The build would copy over this file, and the minified, aggregated version would be deployed.  However, if you were doing development, you could periodically copy over the uportal3.min.css file from source as you did development, as well as any files you'd modified.  Since this file has all the appropriate imports in it, you'd still get all the right stylesheets imported into your page, though in a different way.  One concern I have about this approach is that it might be confusing, or that the list of imports in the build and in uportal3.min.css might get out of sync.  I imagine we'd want to put a very large warning at the top of that file to point people in the right direction.

Do you have thoughts about that proposal?  Any other ideas?  I definitely do want to make sure you and other developers can continue to get work done, and I also want to make sure end users have the most responsive portal we can provide.

- Jen


On Tue, Mar 24, 2009 at 4:19 PM, Moore, Kathleen E <[hidden email]> 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

[hidden email]

617-353-2685

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jen Bourey
Sent: Tuesday, March 24, 2009 4:06 PM
To: [hidden email]
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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    

-- 
You are currently subscribed to [hidden email] as: [hidden email] 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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

Reply | Threaded
Open this post in threaded view
|

RE: Stylesheet imports in uPortal 3.1.x

Kathy Moore
In reply to this post by Jen Bourey-2

Jen,

 

Thanks so much!

 

Can you give me the (deployed) path to “webxml”?

 

I’ll try to give some thought to your other email.

 

Kathy

 

Kathleen Moore

Web Manager

Boston University School of Management

[hidden email]

617-353-2685

 

From: Jen Bourey [mailto:[hidden email]]
Sent: Wednesday, March 25, 2009 9:36 AM
To: [hidden email]
Subject: Re: [jasig-ue] Stylesheet imports in uPortal 3.1.x

 

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 <[hidden email]> 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

[hidden email]

617-353-2685

 

From: Eric Dalquist [mailto:[hidden email]]
Sent: Tuesday, March 24, 2009 4:32 PM

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

[hidden email]

617-353-2685

 

From: [hidden email] [[hidden email]] On Behalf Of Jen Bourey
Sent: Tuesday, March 24, 2009 4:06 PM
To: [hidden email]
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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    

 

-- 
 
You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    
  

 

-- 

You are currently subscribed to [hidden email] as: [hidden email] 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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    

-- 
You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

Reply | Threaded
Open this post in threaded view
|

Re: Stylesheet imports in uPortal 3.1.x

Jen Bourey
Sure!

web.xml should be deployed to TOMCAT_HOME/webapps/uPortal/WEB-INF/web.xml.  If you're looking for it in the source tree, it's at uportal-war/src/main/webapp/WEB-INF/web.xml.

- Jen


On Wed, Mar 25, 2009 at 11:42 AM, Moore, Kathleen E <[hidden email]> wrote:

Jen,

 

Thanks so much!

 

Can you give me the (deployed) path to “webxml”?

 

I’ll try to give some thought to your other email.

 

Kathy

 

Kathleen Moore

Web Manager

Boston University School of Management

[hidden email]

617-353-2685

 

From: Jen Bourey [mailto:[hidden email]]
Sent: Wednesday, March 25, 2009 9:36 AM


To: [hidden email]
Subject: Re: [jasig-ue] Stylesheet imports in uPortal 3.1.x

 

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 <[hidden email]> 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

[hidden email]

617-353-2685

 

From: Eric Dalquist [mailto:[hidden email]]
Sent: Tuesday, March 24, 2009 4:32 PM

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

[hidden email]

617-353-2685

 

From: [hidden email] [[hidden email]] On Behalf Of Jen Bourey
Sent: Tuesday, March 24, 2009 4:06 PM
To: [hidden email]
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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    

 

-- 
 
You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    
  

 

-- 

You are currently subscribed to [hidden email] as: [hidden email] 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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

 

 
    

-- 
You are currently subscribed to [hidden email] as: [hidden email] 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 [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue