Combres - WebForm & MVC Client-side Resource Combine Library

Commented Issue: current protocol should be used to construct CacheKeys [7659]

dplaskon — Wed, 08 May 2013 00:33:19 GMT

In RequestProcessor, the cache key is constructed as such:

CacheKey = string.Join("/",
new[]
{
CachePrefix,
typeof (RequestProcessor).ToString(),
setName,
version,
Compressor.EncodingName
}.Concat(CacheVaryStates.Select(s => s.Key)).ToArray());

I believe that the current protocol (http vs https) should be considered when constructing this cache key.

I've run into problems with absolute paths and mixed content warnings when I assumed that:

http://blah.com/combres/set and https://blah.com/combres/set would return entirely different resources (they should really, as they could represent entirely different content)
Comments: Buu, I could be mistaken - but I think there is an issue with cache-vary providers in nested groups (at least there was the last time I played around with making one) - are you aware of such an issue?

Commented Issue: current protocol should be used to construct CacheKeys [7659]

buunguyen — Tue, 07 May 2013 18:08:07 GMT

In RequestProcessor, the cache key is constructed as such:

CacheKey = string.Join("/",
new[]
{
CachePrefix,
typeof (RequestProcessor).ToString(),
setName,
version,
Compressor.EncodingName
}.Concat(CacheVaryStates.Select(s => s.Key)).ToArray());

I believe that the current protocol (http vs https) should be considered when constructing this cache key.

I've run into problems with absolute paths and mixed content warnings when I assumed that:

http://blah.com/combres/set and https://blah.com/combres/set would return entirely different resources (they should really, as they could represent entirely different content)
Comments: Modifying cache key the way you suggested is certainly one way to make this works. The reason I suggested building a custom cache-vary provider is because this approach increases the mem footprint and 1st-time performance hits for users who don't have to need to differentiate between HTTP and HTTPS requests (i.e. they don't use filters which modify content differently based on secure-connection status).

Commented Issue: current protocol should be used to construct CacheKeys [7659]

dplaskon — Tue, 07 May 2013 17:33:22 GMT

In RequestProcessor, the cache key is constructed as such:

CacheKey = string.Join("/",
new[]
{
CachePrefix,
typeof (RequestProcessor).ToString(),
setName,
version,
Compressor.EncodingName
}.Concat(CacheVaryStates.Select(s => s.Key)).ToArray());

I believe that the current protocol (http vs https) should be considered when constructing this cache key.

I've run into problems with absolute paths and mixed content warnings when I assumed that:

http://blah.com/combres/set and https://blah.com/combres/set would return entirely different resources (they should really, as they could represent entirely different content)
Comments: Buu, I think a more idiomatic solution would be to make the proposed change to the way the cache key is constructed in RequestProcessor (see my comment from Nov 17, 2011 at 1:30 PM). Is there some reason you believe this wouldn't be a good solution to the underlying issue here?

Commented Issue: Add an extension point for url creation [7678]

dplaskon — Tue, 07 May 2013 17:24:22 GMT

There are many great extension points in combres and I'd like to suggest that url creation be an area where this is considered. I recently moved to a new cdn provider that required file extensions to be added to the combres-generated js and css files to ensure that content types were required, which is what prompted me to create this ticket.

This could potentially eliminate the need for having the host and sslHost settings as well, as you could easily append any host name needed with the context of such an extension point.

I'm sure there are quite a few other uses that aren't coming to mind immediately.

Keep up the great work Buu!
Comments: No, I mean something akin to a transformer extension point for urls. For example, you get as input: 1) The name of the set to be created 2) The type of set to be created (eg. js vs css) 3) The hash for the set to be created 4) Access to the httpcontext and/or other interesting contextual information. And, as output, you provide the final url that combres will use for a given resource set.

Created Unassigned: Compile CSS with @import statments [7680]

adardesign — Mon, 29 Apr 2013 03:49:12 GMT

While compiling CSS resources, also inline the @import resources and then compile/build

Commented Issue: Add an extension point for url creation [7678]

adardesign — Mon, 29 Apr 2013 03:48:28 GMT

There are many great extension points in combres and I'd like to suggest that url creation be an area where this is considered. I recently moved to a new cdn provider that required file extensions to be added to the combres-generated js and css files to ensure that content types were required, which is what prompted me to create this ticket.

This could potentially eliminate the need for having the host and sslHost settings as well, as you could easily append any host name needed with the context of such an extension point.

I'm sure there are quite a few other uses that aren't coming to mind immediately.

Keep up the great work Buu!
Comments: Do you mean something like this? path/to/combresResource?resources=resourceID1,resourceID2,resourceID3 which would generate (minify uglify etc.) all required resources?

Created Unassigned: Compile process to include require statments resource [7679]

adardesign — Mon, 29 Apr 2013 03:44:47 GMT

I am looking to combine require.js functionality with combres.
The idea is that while building the script it will follow the require statements.. and addition/instead of the combres xml rules, it should generate the resource via the require (CommonJS) statements.

Reviewed: Combres 2.2.2.6 (十二月 31, 2012)

ajummas — Mon, 31 Dec 2012 15:00:32 GMT

Rated 2 Stars (out of 5) - our Review must be between 10 and 400 characters or spaces. Please adjust your message or leave it off (it’s optional).

New Post: Combres is now hosted in GitHub

buunguyen — Mon, 10 Dec 2012 19:08:25 GMT

I've moved Combres to GitHub. The reasons are:

Most my FOSS projects are in GitHub, it's easier for me to manage if everything's there
GitHub is a better code collaboration platform

I will not commit code to the CodePlex repository anymore.

Combres has evolved to a stage where it is very stable and feature-rich. I will likely not add functionality to it and only maintain by making sure it works with new releases of ASP.NET, YUI, dotLess etc. That said, I do accept pull requests. I hope the move to GitHub makes it easier for people to contribute to Combres.

Updated Release: Combres 2.2.2.6 (Aug 31, 2012)

buunguyen — Mon, 10 Dec 2012 19:01:04 GMT

Note: Combres is now hosted in Github

This release is only available via NuGet
If you don't use NuGet, you can build from source (see associated change set)

Released: Combres 2.2.2.6 (Aug 31, 2012)

Mon, 10 Dec 2012 19:01:04 GMT

Note: Combres is now hosted in Github

This release is only available via NuGet
If you don't use NuGet, you can build from source (see associated change set)

Updated Wiki: Documentation

buunguyen — Mon, 10 Dec 2012 19:00:53 GMT

Note: Combres is now hosted in Github

Updated Wiki: Documentation

buunguyen — Mon, 10 Dec 2012 19:00:30 GMT

Combres is now hosted in Github

Updated Wiki: Documentation

buunguyen — Mon, 10 Dec 2012 19:00:18 GMT

Combres is now hosted in Github

Read this first

5-Minute Quick Start

Combres in depth

Change Notes

Updated Wiki: Home

buunguyen — Mon, 10 Dec 2012 18:49:53 GMT

Note: Combres is now hosted in Github

Source code checked in, #3d799e4f1038

Buu Nguyen — Sun, 09 Dec 2012 21:13:35 GMT

update build script

Source code checked in, #2396affd92b8

Buu — Fri, 07 Dec 2012 21:36:14 GMT

Release 2.2.2.15

New Post: log4net error in NuGet package for Combres 2.2.2.0

buunguyen — Fri, 07 Dec 2012 17:58:16 GMT

Note that Combres.Log4Net is now a separate dependency, so if you want logging, you will need to install it separately. Combres is now free from log4net, so that those who don't need logging won't be bothered again with unnecessary dependency.

New Post: log4net error in NuGet package for Combres 2.2.2.0

buunguyen — Fri, 07 Dec 2012 17:57:17 GMT

I've pushed version 2.2.2.7 which is built with log4net 1.2.11 (2.0) and dotless 1.3.1. Please download, give it a try and let me know if everything's ok. Thanks.

New Post: Border-radius value problem

darkking86 — Sat, 01 Dec 2012 06:51:22 GMT

Ok! I can fix this issue with replace Yahoo.Yui.Compressor reference with new version [ Yahoo.Yui.Compressor.Build.MsBuild ]. http://yuicompressor.codeplex.com/