Skip to content
This repository has been archived by the owner on Jan 24, 2021. It is now read-only.

Improve support for embedded resources and NuGet it up #1331

Closed
wants to merge 32 commits into from

Conversation

jrsconfitto
Copy link
Contributor

This PR seeks to put embedded content on the SDHP by fixing a remaining issue and closing out #732.

Questions i have

  1. Should i move everything related to embedded views out of core Nancy and into Nancy.Embedded?
  2. When wiring up embedded views for Nancy, i followed this post by Simon Cropp. It was pretty simple, but according to Create Nuget for working with embedded stuff #732 it sounds like @grumpydev had some ideas on how to improve wiring up embedded views. Is there a better way to wire up embedded views?

Done

  • Fix issue with embedded views in an outside assembly mentioned in this mailing list post. Thanks for the fix, Rex!
  • Add an extension that allows an AddDirectory for embedded static content, similar to the extension method on the default StaticContentConventions
  • Wire up embedded views via an ApplicationRegistration
  • Figure out the best way to handle issue with no RootNamespaces added and only one embedded view to serve.

@jrsconfitto
Copy link
Contributor Author

cc @khellang

@jrsconfitto
Copy link
Contributor Author

OK, i found some guidance from this mailing list post that talks about wiring this all up via an IApplicationRegistration.

@jrsconfitto
Copy link
Contributor Author

OK, i've added a basic registrations class to the Nancy.Embedded stuff to make wiring up embedded views a little more automatic.

While running a demo project, i ran into an issue described in the mailing list by @thecodejunkie where i only had one embedded view and hadn't added to the RootNamespaces property. This throws a TinyIoCResolution exception because of what @thecodejunkie describes in the aforementioned mailing list post:

Now in the special case where there is only one resource located, it's unable to derive a common namespace, and since it's impossible to read out the "default namespace" that is registered in a project, nancy cannot stip out the common namespace. You can think of the common namespace as the rootpath of your application when you use the filesystem base view locator

When i add another view, or add my namespace to the RootNamespaces dictionary, everything is 👌

i don't think this is very SDHP. Someone like me will test it out on one view and see if it worked and probably be 😠. It seems (to me) like a common base case for someone to try out Embedding content.

Should we try to fill in RootNamespaces automatically for someone? Or should we work on throwing a nicer error so that someone can catch this issue quickly? i think at least a 500 would be better. i think i'll try to go down that route unless i hear different.

@reidperyam
Copy link
Contributor

Juggling - not sure if this is applicable to your extensions or not; I am having a pig of a time getting my Nancy.Test.csproj to load my embedded resource views for testing. The views exist in a separate App.UI assembly (which is separate from my App.Nancy assembly) ; I forcibly load the App.UI assembly into the NUnit execution AppDomain at runtime.

Mostly weird because everything is peachy when I F5 the actual application (after implementing #1332 ) -- views are picked up and served as expected, just not within the testing context. My NancyModules can't bind the view even though its resource path is registered with its parent assembly via ResourceViewLocationProvider.RootNamespaces.Add(...) and the testing browser's bootstrapper has its
ViewLocationProvider = typeof(ResourceViewLocationProvider). Hard to debug wondering if any of this rings a bell.

@jrsconfitto
Copy link
Contributor Author

i haven't tried any tests on embedded stuff. i'll try to reproduce this and make sure it doesn't affect the work on this PR.

In the meantime, is Nancy.Test.csproj the name of your test project? i'm not sure if this is an issue, but my first guess would be to try changing the assembly name of your test project and make sure the name isn't causing Nancy to ignore your test assembly.

@reidperyam
Copy link
Contributor

Good suggestion; however my test assembly, containing Nancy tests, is actually *Application.Test -- so no references to Nancy. I'll keep digging; appreciate the response.

@jrsconfitto
Copy link
Contributor Author

i have working tests in my test project for this PR, so i'm not sure what could be wrong.

Here's a gist of my test class in case an example might help point out a direction to pursue in debugging your issue.

If you ping me in chat maybe i can help you out.

@khellang
Copy link
Member

Oh snap! 👊 The Mono build hates me 💔 😢

@khellang
Copy link
Member

  • Figure out the best way to handle issue with no RootNamespaces added and only one embedded view to serve 😉

@jrsconfitto
Copy link
Contributor Author

  • Figure out how to make the mono builds not fail on gem install rake :trollface:... boo on connection errors 😦

@jrsconfitto
Copy link
Contributor Author

OK, @thecodejunkie & @grumpydev, i think this is ready for some review. Mind throwing some 👀 over this one?

@jrsconfitto
Copy link
Contributor Author

Rebased against master, sorry if that blows anybody's work away 😭

@jrsconfitto
Copy link
Contributor Author

Apparently rebasing breaks travis?

@jrsconfitto
Copy link
Contributor Author

i added a home route and view to your example because some dumb guy was confused when he navigated to the host URL and saw a 404 monster. He also might have incorrectly assumed that @khellang screwed up 😝.

@jrsconfitto
Copy link
Contributor Author

AIGHT! We're good to go @thecodejunkie!

@khellang
Copy link
Member

khellang commented Dec 5, 2013

Is there a reason why the AccountModule.cs contains the HomeModule and the HomeModule.cs contains the AccountModule? 😝

/// <summary>
/// Initializes a new instance of the <see cref="EmbeddedViewLocationProvider"/> class.
/// </summary>
public EmbeddedViewLocationProvider()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we ditch this constructor and register the DefaultResourceReader in Registrations?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally!

@jrsconfitto
Copy link
Contributor Author

Is there a reason why the AccountModule.cs contains the HomeModule and the HomeModule.cs contains the AccountModule?

IF IT AIN'T BROKE DON'T FIX IT.

Good catch, i must not have kept track of which file i was editing when i copied the account module into the home module.

@reidperyam
Copy link
Contributor

Hey @jugglingnutcase - have an issue serving static files as embedded resources (from a separate assembly) using the StaticContentsConventions along with Microsoft.Owin.Host.SystemWeb . IIS doesn't seem to like Nancy from OWIN. (example: http://salesapp.us/_Nancy ) I made a repo for a repro: http://goo.gl/FtqLmH ; everything works fine when self hosted on a cloud service: (http://sel2.us/_Nancy) .

@jrsconfitto
Copy link
Contributor Author

@TheFastCat i see you were able to post this issue on the mailing list. Fortunately for this PR, it looks like it's not related.

@jrsconfitto
Copy link
Contributor Author

@thecodejunkie Any chance of this getting into 0.22?

@jrsconfitto
Copy link
Contributor Author

At this point, i'm warring with this PR. Let me vomit out my thoughts for you 👅

Here's what i'm using in my own project that i want this PR for:

  • We're embedding Nancy in a desktop application, so i'm not sure if i can use Cassette... i need to do more research
  • OWIN-hosted
  • DotLiquid views
  • A bunch of css/js static resources

Here's what i want:

  • i want to package all my views and resources into a dll because that eases deployment for my team's leader who runs the installation stuff
  • i want to be able to have both debug and release versions
  • i want to have minification and compression going on too

This PR meets my first want, but not the others, i think (unless i do some ugly hackery).

Some options i'm considering for moving forward:

  1. Get this pulled in because other people think it's useful as part of Nancy proper. Should i? cc @khellang, @thecodejunkie
  2. Maintain this separately from Nancy... i'll pull this out of Nancy, make my own repo, and distribute it via NuGet.
  3. Ditch this for something that better suits my needs, like an OWIN-compatible version of Cassette. This is the direction i'm planning to head in, if not now, soon(ish).

i feel obligated to point out that option 3 doesn't really exclude the other options. i'm willing to put this out as its own NuGet package and then move forward on my own.

Any thoughts?

@khellang
Copy link
Member

I still want this very much, the embedded story is lacking a bit today. I don't really care whether it's part of the Nancy repo or not, t'll still be a separate NuGet package 😄

@reidperyam
Copy link
Contributor

I want it as well but since it's been a few months on getting out the door I've started investigating Owin.StaticFiles to serve the same purpose. randompunter and pinpointtownes and tracher have been helpful with the transition. It looks like it will simplify my verbose Nancy StaticContentsConventions I currently have to define:

image

...but there is an issue that needs to be resolved first... https://katanaproject.codeplex.com/workitem/202

@khellang
Copy link
Member

Haha! Remember - there's nothing stopping you from creating your own extension method 😄

@xt0rted
Copy link
Contributor

xt0rted commented Jan 30, 2014

@jugglingnutcase I started an OWIN middleware project for Cassette in case you haven't seen it. It could use some unit test love (it currently has none) but otherwise it seems to work well for my needs.

@jrsconfitto
Copy link
Contributor Author

@xt0rted i had that project in mind when i wrote that 😉 i should've put in a link...

i'll be exploring that project soon 😄

@jrsconfitto
Copy link
Contributor Author

I don't really care whether it's part of the Nancy repo or not

@khellang i'm also OK with either. If i get a merge, then 🆒. If not, i'd like a thumbs down or a ping at some point (i'm not in a huge rush) so i can start moving this out to another repo.

@jrsconfitto
Copy link
Contributor Author

It looks like it will simplify my verbose Nancy StaticContentsConventions

@TheFastCat Maybe you've already thought through this, but why aren't you just putting all your javascripts in a common folder and then adding the parent scripts directory? Wouldn't that work without all that code ceremony? Am i missing something?

This reverts commit 6ccb39a.

Conflicts:
	src/Nancy.Embedded.Tests/Unit/EmbeddedViewLocationProviderFixture.cs
	src/Nancy.Embedded.Tests/Unit/ResourceViewLocationProviderFixture.cs
	src/Nancy.Tests/Unit/ViewEngines/ResourceViewLocationProviderFixture.cs
	src/Nancy/ViewEngines/ResourceViewLocationProvider.cs
@jrsconfitto
Copy link
Contributor Author

i'm planning on moving this stuff to my GitHub account and releasing it through NuGet. i'll let you know when it's up 😄

@jrsconfitto jrsconfitto closed this Mar 3, 2014
jrsconfitto added a commit to jrsconfitto/Nancy.EmbeddedContent that referenced this pull request Mar 4, 2014
This code is branching off the work done in NancyFx/Nancy and the work
in NancyFx/Nancy#1331.
@jrsconfitto
Copy link
Contributor Author

Okey-dokey, it's moved.

i'll publish it up on NuGet soon. Please let me know if there's any licensing stuff that i need to take care of.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants