MvcContrib.IncludeHandling
7 views
Skip to first unread message
petemounce
Sep 25, 2009, 8:59:08 AM9/25/09
to mvccontrib-discuss
Hi there
I've forked MvcContrib to http://github.com/petemounce/mvccontrib so I
could merge my IncludeCombiner project into it - I've successfully
done this (which also, by the way, entailed updating nunit to v2.5; I
wanted Assert.Throws in preference to ExpectedException) and have
mentioned it to Jeremy for you guys to pull.
All tests pass and MvcContrib.IncludeHandling is pretty well covered.
MvcContrib.IncludeHandling is a set of classes for dealing with
JavaScript and/or CSS includes; one registers includes in the view/
master/layout, and it, at runtime, combines them together, minifies
them (using YuiCompressor.NET), compresses them gzip/deflate (if
supported by the browser making the request), and squirts them back
with appropriate cache-policy set up. There's a demo site; Samples/
MvcContrib.Samples.IncludeHandling illustrating the use.
There's also a new Filter; DebugFilter. It's for turning on or off
debug-mode via querystring, and maintained between request by a
cookie, _IF_ web.config/system.web/compilation@debug=true
(HttpContext.Current.IsDebuggingEnabled). MvcContrib.IncludeHandling
reacts to this - when in debug mode it will write out the script
includes raw, untouched, one by one, instead of minifying etc.
There's configuration-section support too - see unit-tests/app.config
for examples.
Please let me know if it passes review, or if not, what I need to do
further? It's not perfect; you can see open issues in
http://github.com/petemounce/includecombiner/issues
Best regards (& thanks for moving to github!)
Pete
I've forked MvcContrib to http://github.com/petemounce/mvccontrib so I
could merge my IncludeCombiner project into it - I've successfully
done this (which also, by the way, entailed updating nunit to v2.5; I
wanted Assert.Throws in preference to ExpectedException) and have
mentioned it to Jeremy for you guys to pull.
All tests pass and MvcContrib.IncludeHandling is pretty well covered.
MvcContrib.IncludeHandling is a set of classes for dealing with
JavaScript and/or CSS includes; one registers includes in the view/
master/layout, and it, at runtime, combines them together, minifies
them (using YuiCompressor.NET), compresses them gzip/deflate (if
supported by the browser making the request), and squirts them back
with appropriate cache-policy set up. There's a demo site; Samples/
MvcContrib.Samples.IncludeHandling illustrating the use.
There's also a new Filter; DebugFilter. It's for turning on or off
debug-mode via querystring, and maintained between request by a
cookie, _IF_ web.config/system.web/compilation@debug=true
(HttpContext.Current.IsDebuggingEnabled). MvcContrib.IncludeHandling
reacts to this - when in debug mode it will write out the script
includes raw, untouched, one by one, instead of minifying etc.
There's configuration-section support too - see unit-tests/app.config
for examples.
Please let me know if it passes review, or if not, what I need to do
further? It's not perfect; you can see open issues in
http://github.com/petemounce/includecombiner/issues
Best regards (& thanks for moving to github!)
Pete
Eric Hexter
Sep 25, 2009, 9:08:03 AM9/25/09
to mvccontri...@googlegroups.com
Thanks for the detailed email.. Do you have an Idea of how much code coverage you do have? If you do not have a code coverage tool let me know and I can run it. I just cannot promise I will get to it in the next day or two.
I like the idea of what you have done. I look forward to looking through it.
Ben Scheirman
Sep 25, 2009, 9:17:03 AM9/25/09
to mvccontri...@googlegroups.com
Looking at some of the changes....
I know you mentioned it in your commit, but the xunit tests would have to get converted over to nunit so that they'll run as part of our CI build.
Regarding the tests, I'm not sure I like putting the various configuration scenarios all in the same config file. Since you own this configuration instance, wouldn't you be able to set the exact same thing up in code? For example, create the ConfigSectionHandler and pass it your own XML within the unit test.
As far as CommonServiceLocator, do we not already depend on this? If not, I think it's a perfectly reasonable thing to do, to allow other components to be container-agnostic, yet still pull dependencies.
I know you mentioned it in your commit, but the xunit tests would have to get converted over to nunit so that they'll run as part of our CI build.
Regarding the tests, I'm not sure I like putting the various configuration scenarios all in the same config file. Since you own this configuration instance, wouldn't you be able to set the exact same thing up in code? For example, create the ConfigSectionHandler and pass it your own XML within the unit test.
As far as CommonServiceLocator, do we not already depend on this? If not, I think it's a perfectly reasonable thing to do, to allow other components to be container-agnostic, yet still pull dependencies.
Eric Hexter
Sep 25, 2009, 9:21:39 AM9/25/09
to mvccontri...@googlegroups.com
We do not have the CommonServiceLocator in the trunk, right now. We had agreed (on the list) that we should get the CSL in and I think Jeremy was going to put it into the MVC2 branch.
I agree with your take on the test configs.. Isolation is king in testing.
Eric Hexter
Principal Consultant | Headspring Systems | www.HeadspringSystems.com
email | ehe...@HeadspringSystems.com
blog | http://Hex.LosTechies.com
info | http://www.linkedin.com/in/erichexter
Jeremy Skinner
Sep 25, 2009, 9:21:56 AM9/25/09
to mvccontri...@googlegroups.com
I was planning on getting this integrated into the master branch when I have some time tomorrow.
--
Jeremy Skinner
http://www.jeremyskinner.co.uk
http://twitter.com/JeremySkinner
2009/9/25 Ben Scheirman <subdi...@gmail.com>
--
Jeremy Skinner
http://www.jeremyskinner.co.uk
http://twitter.com/JeremySkinner
Jeremy Skinner
Sep 25, 2009, 9:25:05 AM9/25/09
to mvccontri...@googlegroups.com
> We had
agreed (on the list) that we should get the CSL in and I think Jeremy
was going to put it into the MVC2 branch.
I had forgotten about this :) 2009/9/25 Eric Hexter <eric....@gmail.com>
Eric Hexter
Sep 25, 2009, 9:28:14 AM9/25/09
to mvccontri...@googlegroups.com
no worries.. lets just decide what we want to do.
I guess it would be a good time to clean up the issue list on codeplex and put a priority of how people with time could help out by picking up an issue they are interested in contributing.
petemounce
Sep 25, 2009, 10:01:48 AM9/25/09
to mvccontrib-discuss
Answering all at once:
* Coverage, when I last checked (I have an NCover v3 license), was in
the 90% region throughout. I admit I haven't run it across MvcContrib
since I started the work, though.
* Tests have been converted to nunit (2.5) in latest commits,
yesterday (http://github.com/petemounce/MvcContrib/commit/
0e73720c6d71469460fe441bad67c372070c95d5).
* No dependency on CSL anymore - I updated to use your
IDependencyResolver and changed my tests. I was going to see whether
I could rip out IDR in favour of CSL, since IDR predates CSL, but
abandoned that when I noticed IDR supports releasing components and
CSL does not.
* Configuration. It didn't occur to me that I could new up the
ConfigurationSectionHandler from XML - will do shortly (as in, after I
finish writing this).
Regards
Pete
On Sep 25, 2:28 pm, Eric Hexter <eric.hex...@gmail.com> wrote:
> no worries.. lets just decide what we want to do.
> I guess it would be a good time to clean up the issue list on codeplex and
> put a priority of how people with time could help out by picking up an issue
> they are interested in contributing.
>
> On Fri, Sep 25, 2009 at 8:25 AM, Jeremy Skinner
> <jer...@jeremyskinner.co.uk>wrote:
>
> > > We had agreed (on the list) that we should get the CSL in and I think
> > Jeremy was going to put it into the MVC2 branch.
>
> > I had forgotten about this :)
>
> > 2009/9/25 Eric Hexter <eric.hex...@gmail.com>
> >> email | ehex...@HeadspringSystems.com
> >> blog |http://Hex.LosTechies.com<http://hex.lostechies.com/>
> >> info |http://www.linkedin.com/in/erichexter
* Coverage, when I last checked (I have an NCover v3 license), was in
the 90% region throughout. I admit I haven't run it across MvcContrib
since I started the work, though.
* Tests have been converted to nunit (2.5) in latest commits,
yesterday (http://github.com/petemounce/MvcContrib/commit/
0e73720c6d71469460fe441bad67c372070c95d5).
* No dependency on CSL anymore - I updated to use your
IDependencyResolver and changed my tests. I was going to see whether
I could rip out IDR in favour of CSL, since IDR predates CSL, but
abandoned that when I noticed IDR supports releasing components and
CSL does not.
* Configuration. It didn't occur to me that I could new up the
ConfigurationSectionHandler from XML - will do shortly (as in, after I
finish writing this).
Regards
Pete
On Sep 25, 2:28 pm, Eric Hexter <eric.hex...@gmail.com> wrote:
> no worries.. lets just decide what we want to do.
> I guess it would be a good time to clean up the issue list on codeplex and
> put a priority of how people with time could help out by picking up an issue
> they are interested in contributing.
>
> On Fri, Sep 25, 2009 at 8:25 AM, Jeremy Skinner
> <jer...@jeremyskinner.co.uk>wrote:
>
> > > We had agreed (on the list) that we should get the CSL in and I think
> > Jeremy was going to put it into the MVC2 branch.
>
> > I had forgotten about this :)
>
>
> > We do not have the CommonServiceLocator in the trunk, right now. We had
> >> agreed (on the list) that we should get the CSL in and I think Jeremy was
> >> going to put it into the MVC2 branch.
>
> >> I agree with your take on the test configs.. Isolation is king in testing.
>
> >> Eric Hexter
>
> >> Principal Consultant | Headspring Systems |www.HeadspringSystems.com<http://www.headspringsystems.com/>
> > We do not have the CommonServiceLocator in the trunk, right now. We had
> >> agreed (on the list) that we should get the CSL in and I think Jeremy was
> >> going to put it into the MVC2 branch.
>
> >> I agree with your take on the test configs.. Isolation is king in testing.
>
> >> Eric Hexter
>
> >> email | ehex...@HeadspringSystems.com
> >> blog |http://Hex.LosTechies.com<http://hex.lostechies.com/>
> >> info |http://www.linkedin.com/in/erichexter
>
> >> On Fri, Sep 25, 2009 at 8:17 AM, Ben Scheirman <subdigi...@gmail.com>wrote:
>
> >>> Looking at some of the changes....
>
> >>> I know you mentioned it in your commit, but the xunit tests would have to
> >>> get converted over to nunit so that they'll run as part of our CI build.
>
> >>> Regarding the tests, I'm not sure I like putting the various
> >>> configuration scenarios all in the same config file. Since you own this
> >>> configuration instance, wouldn't you be able to set the exact same thing up
> >>> in code? For example, create the ConfigSectionHandler and pass it your own
> >>> XML within the unit test.
>
> >>> As far as CommonServiceLocator, do we not already depend on this? If
> >>> not, I think it's a perfectly reasonable thing to do, to allow other
> >>> components to be container-agnostic, yet still pull dependencies.
>
> >> On Fri, Sep 25, 2009 at 8:17 AM, Ben Scheirman <subdigi...@gmail.com>wrote:
>
> >>> Looking at some of the changes....
>
> >>> I know you mentioned it in your commit, but the xunit tests would have to
> >>> get converted over to nunit so that they'll run as part of our CI build.
>
> >>> Regarding the tests, I'm not sure I like putting the various
> >>> configuration scenarios all in the same config file. Since you own this
> >>> configuration instance, wouldn't you be able to set the exact same thing up
> >>> in code? For example, create the ConfigSectionHandler and pass it your own
> >>> XML within the unit test.
>
> >>> As far as CommonServiceLocator, do we not already depend on this? If
> >>> not, I think it's a perfectly reasonable thing to do, to allow other
> >>> components to be container-agnostic, yet still pull dependencies.
>
> >>> On Fri, Sep 25, 2009 at 8:08 AM, Eric Hexter <eric.hex...@gmail.com>wrote:
>
> >>>> Thanks for the detailed email.. Do you have an Idea of how much code
> >>>> coverage you do have? If you do not have a code coverage tool let me know
> >>>> and I can run it. I just cannot promise I will get to it in the next day or
> >>>> two.
>
> >>>> I like the idea of what you have done. I look forward to looking
> >>>> through it.
>
>
> >>>> Thanks for the detailed email.. Do you have an Idea of how much code
> >>>> coverage you do have? If you do not have a code coverage tool let me know
> >>>> and I can run it. I just cannot promise I will get to it in the next day or
> >>>> two.
>
> >>>> I like the idea of what you have done. I look forward to looking
> >>>> through it.
>
> >>>> On Fri, Sep 25, 2009 at 7:59 AM, petemounce <peter.mou...@gmail.com>wrote:
>
> >>>>> Hi there
>
> >>>>> I've forked MvcContrib tohttp://github.com/petemounce/mvccontribso I
>
> >>>>> Hi there
>
Jeremy Skinner
Sep 25, 2009, 10:08:38 AM9/25/09
to mvccontri...@googlegroups.com
IIRC there's an issue with using TeamCity with nUnit 2.5 if you're using the ExpectedException attribute (which a lot of the mvccontrib tests do) - it seems to ignore the attribute and always fail the tests. Not sure if newer teamcity versions have fixed this. If not, I'll update the rest of the tests to use asser.throws.
2009/9/25 petemounce <peter....@gmail.com>
petemounce
Sep 25, 2009, 10:38:35 AM9/25/09
to mvccontrib-discuss
I've done and pushed the config-tests change.
I should have said; tests all pass in the ReSharper runner. The
command-line build does not :-/
Regards
Pete
On Sep 25, 3:08 pm, Jeremy Skinner <jer...@jeremyskinner.co.uk> wrote:
> IIRC there's an issue with using TeamCity with nUnit 2.5 if you're using the
> ExpectedException attribute (which a lot of the mvccontrib tests do) - it
> seems to ignore the attribute and always fail the tests. Not sure if newer
> teamcity versions have fixed this. If not, I'll update the rest of the tests
> to use asser.throws.
>
> 2009/9/25 petemounce <peter.mou...@gmail.com>
> > ).
I should have said; tests all pass in the ReSharper runner. The
command-line build does not :-/
Regards
Pete
On Sep 25, 3:08 pm, Jeremy Skinner <jer...@jeremyskinner.co.uk> wrote:
> IIRC there's an issue with using TeamCity with nUnit 2.5 if you're using the
> ExpectedException attribute (which a lot of the mvccontrib tests do) - it
> seems to ignore the attribute and always fail the tests. Not sure if newer
> teamcity versions have fixed this. If not, I'll update the rest of the tests
> to use asser.throws.
>
>
>
>
>
>
> > Answering all at once:
>
> > * Coverage, when I last checked (I have an NCover v3 license), was in
> > the 90% region throughout. I admit I haven't run it across MvcContrib
> > since I started the work, though.
> > * Tests have been converted to nunit (2.5) in latest commits,
> > yesterday (http://github.com/petemounce/MvcContrib/commit/
> > 0e73720c6d71469460fe441bad67c372070c95d5<http://github.com/petemounce/MvcContrib/commit/%0A0e73720c6d71469460f...>
>
>
>
>
> > Answering all at once:
>
> > * Coverage, when I last checked (I have an NCover v3 license), was in
> > the 90% region throughout. I admit I haven't run it across MvcContrib
> > since I started the work, though.
> > * Tests have been converted to nunit (2.5) in latest commits,
> > yesterday (http://github.com/petemounce/MvcContrib/commit/
> > ).
Eric Hexter
Sep 25, 2009, 11:10:00 AM9/25/09
to mvccontri...@googlegroups.com
The test probably fail because we are using the Nant nunit task which is using the older nunit. We may be able to tweak the nant.exe.config redirect the assembly. or we can just run the commandline nunit runner.
Ben Scheirman
Sep 25, 2009, 12:01:43 PM9/25/09
to mvccontri...@googlegroups.com
The more projects I do with NAnt, the more I lean towards just using the console runner. Let's headaches with versioning.
TC should pick up the results just the same.
TC should pick up the results just the same.
Eric Hexter
Sep 25, 2009, 12:05:55 PM9/25/09
to mvccontri...@googlegroups.com
I agree. going to the command line for the exact tool that we are using can prevent pain and make migration to a different build tool easier as well.
petemounce
Sep 25, 2009, 6:30:54 PM9/25/09
to mvccontrib-discuss
Would you like me to wire in rake-dotnet? ;-)
On Sep 25, 5:05 pm, Eric Hexter <eric.hex...@gmail.com> wrote:
> I agree. going to the command line for the exact tool that we are using can
> prevent pain and make migration to a different build tool easier as well.
>
> Eric Hexter
>
> Principal Consultant | Headspring Systems |www.HeadspringSystems.com
> email | ehex...@HeadspringSystems.com
On Sep 25, 5:05 pm, Eric Hexter <eric.hex...@gmail.com> wrote:
> I agree. going to the command line for the exact tool that we are using can
> prevent pain and make migration to a different build tool easier as well.
>
> Eric Hexter
>
> Principal Consultant | Headspring Systems |www.HeadspringSystems.com
> On Fri, Sep 25, 2009 at 11:01 AM, Ben Scheirman <subdigi...@gmail.com>wrote:
>
>
>
> > The more projects I do with NAnt, the more I lean towards just using the
> > console runner. Let's headaches with versioning.
>
> > TC should pick up the results just the same.
>
>
>
>
> > The more projects I do with NAnt, the more I lean towards just using the
> > console runner. Let's headaches with versioning.
>
> > TC should pick up the results just the same.
>
> > On Fri, Sep 25, 2009 at 10:10 AM, Eric Hexter <eric.hex...@gmail.com>wrote:
>
> >> The test probably fail because we are using the Nant nunit task which is
> >> using the older nunit. We may be able to tweak the nant.exe.config redirect
> >> the assembly. or we can just run the commandline nunit runner.
>
>
> >> The test probably fail because we are using the Nant nunit task which is
> >> using the older nunit. We may be able to tweak the nant.exe.config redirect
> >> the assembly. or we can just run the commandline nunit runner.
>
Jeremy Skinner
Sep 26, 2009, 8:10:12 AM9/26/09
to mvccontri...@googlegroups.com
The reason why some of the tests are failing in the console runner versus the resharper runner is that the resharper runner does not execute tests marked with the 'Theory' attribute, while the console runner (and TD.NET) do.
These tests were actually failing, but the r# runner just wasn't running them. I have fixed them and also changed them to be regular [Test] methods rather than Theories so it is possible to execute them using the R# runner. It might be worth just double-checking these tests to make sure I haven't missed anything when converting them.
I had to modify the build script to copy the .xml files that the IncludeHandling tests require into the test directory.
I've also changed the build script to use the nunit console runner rather than the nant task. This may need some further tweaks to work with TeamCity (ie the use of the Nunit TeamCity Addin).
Jeremy
These tests were actually failing, but the r# runner just wasn't running them. I have fixed them and also changed them to be regular [Test] methods rather than Theories so it is possible to execute them using the R# runner. It might be worth just double-checking these tests to make sure I haven't missed anything when converting them.
I had to modify the build script to copy the .xml files that the IncludeHandling tests require into the test directory.
I've also changed the build script to use the nunit console runner rather than the nant task. This may need some further tweaks to work with TeamCity (ie the use of the Nunit TeamCity Addin).
Jeremy
Eric Hexter
Sep 26, 2009, 11:02:26 AM9/26/09
to mvccontri...@googlegroups.com
the team city add in should auto pick up the unit test results.. we will see after the check in.
Thanks so much for looking at this patch.
email | ehe...@HeadspringSystems.com
Reply all
Reply to author
Forward
0 new messages