Is support planned for embedded resources with ASP .NET 4.5 css and js bundling features? - asp.net-4.5

I read Scott Gu's article about built-in support for bundling and minification in ASP .NET 4.5.
However there's no mention of embedded resources, which is a pity.
In the past I've been using a Codeplex project called Client Dependency Framework which supported embedded resources.
Seems like a pretty major omission to me. Is support planned?

I'm pretty sure you could write your own transformer to handle this.
Create a class that implements System.Web.Optimization.IBundleTransform.
Then in the Process method get the contents of the embedded resource. This shouldn't be too difficult. This blog post might be helpful.
Then add the transform to the bundle.
e.g.
var bundle = new Bundle("~/Test").Include("~/Content/Site.css");
bundle.Transforms.Add(new EmbeddedResourceTransformer());
Note that I am using the nuget package from System.Web.Optimization, not Microsoft.Web.Optimization (I have no idea why there are two different namespace implementations, and whether the syntax would be the same in both).
I also can't vouch for the performance of doing it this way as opposed to the file system.
Hope that helps!

Just a few comments on above answers since I don't have enough rep. to comment directly...
The answer from Hainesy suggests using a BundleTransform. I believe this is too late in the process to include an embedded resource. The BundleTransform is helpful for converting things inside the css or javascript after the contents are pulled from the original file and before they are put into the bundled file. For example, if you need to modify image URL's in CSS to point to local relative url for dev and to a CDN url for production.
The link from user960567 explains how to use embedded resources, but there's a catch. That process will only work for something like a common control used from another project.
e.g. If you create a textbox that needs CSS and JS then it allows you to create a HTML helper in the common project that will add the textbox and the script tags that pull in the embedded resource into the page. It does not allow you to pull the embedded resource from the common project into a bundle in another project. This will basically create a separate script or style tag for each embedded resource which may not be what you want (at least it's not what I was looking for.)

I've written a detailed article about how you can use the bundle and minification technology to wrap up your external resources here.

Related

What is the most up-to-date recommended seed/setup for latest riot version (3.11)?

What is the most elegant way to get a riot based UI today?
i'd love the following points to be addressed:
A proper code-mapping for easy debugging
A good way to bundle the application (so far i used Webpack and JSPM)
It would be lovely if it would work elegantly with Typescript.
Is it best to use Tag files, or straight JS? If the later, would it be better to use a class that inherit from riot's tag class? If so, can i place the template code in a different file?
Future compatibility: i saw that there's going to be a change (that "export default" thing) - how would you recommend to write the code for the smoothest migration path?
If you have more items for consideration - please add them....
Thanks for asking these questions. I have tried to answer to all your questions hoping they could be useful also to other Riot.js users
A proper code-mapping for easy debugging
the riot compiler generates simply javascript code without modifying too much the structure of your original source code. Any modern browser should be able to provide with debugger breakpoints and console calls all the debugging tools you need. Check for example the stack trace of this error you don't need much more to figure out where it's coming from.
A good way to bundle the application (so far i used Webpack and JSPM)
In this repo we provide 3 different javascript bundle examples: rollup, webpack, riot-compiler. I personally prefer rollup but you can (and should) use whatever works best for you and your team.
It would be lovely if it would work elegantly with Typescript.
The riot public methods are already available as Typescript interfaces:
- https://www.npmjs.com/package/#types/riot
- https://www.npmjs.com/package/#types/riot-route
I am not a typescript user and that's why I will not invest time in making examples in a technology I don't use but PR are welcome
Is it best to use Tag files, or straight JS? If the later, would it be better to use a class that inherit from riot's tag class? If so, can i place the template code in a different file?
I recommend you to just use Tag files because riot was designed as component library and it embraces completely the philosophy of components composition vs class inheritance. If you have code you share across several components you can either use mixins or import it with your bundler directly in your tags see for example
Future compatibility: i saw that there's going to be a change (that "export default" thing) - how would you recommend to write the code for the smoothest migration path?
Riot 3 will be not compatible with Riot 4. (that will be a full rewrite) I can't recommend any best practice to make your code portable to Riot 4. Remember that Riot 3 will be still supported and your code will run even on IE9 for the next 10 years. Once riot 4 will be released and the API will be stable I can provide more hints about a migration path.

best practice - upgrade dojo/dijit to dojo2 application

We have a legacy PHP/Zend application built with dojo/dijit and dojox/mobile. We want to start to remodel the application using DOJO2. Much of the existing UI is already in the form of dijit AJAX pulls against server code.
We've been through the dojo2 tutorials, as well as become fond of webstorm.
As folks do such migrations, is it most often done as a new, dojo2 application that makes pulls against legacy (existing) server code, or is it more common to point webstorm's 'dist' directory to the existing application's javascript folder and create 'stub' server pages that just include the new DOJO2 code.
Or does it not really matter?
We're just looking to see what is the most common path forward with DOJO2 while minimizing the mucking that goes on with Zend's module routers, and don't want to start down a path that has some unknown 'gotchas'.
Dojo 2 follows a reactive architecture and has a different build path to legacy Dojo. You may find it easier to re-write each php page's TS/JS code at a time to use Dojo 2. I'm afraid I am not familiar with Zend so cannot provide specific advice for this.

Bigcommerce Stencil - What is Required and Help Setting Up

I just got access to the new Stencil beta and I have no idea what to do. I have reviewed all of the documentation on the BC developer website, but I don't know how to proceed. I am also not sure if I will even be able to create designs in Stencil since I don't know Handlbars or json - are those programming skills required or can we still rely on CSS and HTML for most design customization? BC told me there is no support for getting set up and to ask in this forum instead.
Normally I would look under the hood of an existing theme to see how it's built and try "learning on the job" but since I can't even get access to the files, I am at a loss. I created an account on GitHub but I have never used it so I don't know where to look for the files (I did a search but there are thousands of files there and I again couldn't figure out where to start). Can anyone point me in the right direction so I can determine if using Stencil is even feasible for my projects?
Handlebars compiles serverside as HTML. You do still have stylesheets, but we are using some SASS custom functions (documented in Stencil docs).
I'd recommend taking a look here: http://blog.teamtreehouse.com/getting-started-with-handlebars-js

Determining mininium files required for dojo widget

First off, I'm brand new to Dojo.
I'm integrating it into our existing web app.
We initially only need the Calendar widget functionality.
I'm looking to keep the number and size of files as small as possible.
I don't believe downloading just the base code file will be sufficent?
http://dojotoolkit.org/download/
Additionally, the Dojo toolkit download is a huge zip (Even if I was to only use compressed files)
Am I left with downloading the toolkit and manually removing everything I don't need?
Is there no custom download builder like jquery ui?
Well, the dojo library is much larger than jquery ui and I don't know of an equivalent to the download builder. If you are just interested in using dojo for a single widget, you might consider exploring a different library.
To use dojox/Calendar, you are still going to need the many dependencies it has on other dojo modules. You can do this manually, but it will be tedious.
One thing you can do is run dojo's build system to package dojox/Calendar and all of its dependencies into a single file. This isn't a trivial task and requires a good understanding of dojo's AMD loader and package system.
If you want to go down this route, I would clone the dojo-boilerplate project on github. It contains everything you need to do this out of the box. Then follow the build system tutorial to understand how you set this up. From there you can have your app depend on dojox/Calendar to produce the file you include on your page to consume it.
I suggest that you put the whole thing (yes, it's a lot of tiny files) to your server.
Dojo 1.9 is written so that when users visit, their computers will only download the individual pieces on an as-needed basis. This is possible because every piece (AMD modules) is explicit about what it needs.
Once you have something that works, you can choose speed-up loading times by using the build system. Basically, this involves going: "If the user wants this thing, they'll probably want all this other stuff, so create a big minified lump and give it to them whenever they start asking." Best of all, it doesn't have to be perfect: If you miss including something, the users browser will still request it a la carte.
At work we're using the Dojo Boilerplate starting application which helps give some initial organization to the build process.

Manage templates in large SPA with Ember.js and ASP.NET MVC

I am converting a good old ASP.Net website to a single page application using Ember.js in a ASP.NET Web API project.
All the devs of my team and myself are pretty new to javascript. We spent the last 2 weeks learning the basis and comparing SPA frameworks. I apologize in advance if my question sounds stupid :)
All the Ember tutorials I have found so far included all Handlebars templates into one single file. I assumed it would be pretty obvious to split them into separates files (*.hbs) when the time would come, but it's not. I might be totally missing something here, but I found about 4 ways to get my templates back when I need them. I'd like to know which method you would recommend:
Concatenate and then inject all the template files when the app loads. I could write some C# code on the server-side that concatenates all the templates files into a single one when the app loads (i.e. each time a visitor enter the app). It seems odd to me, in terms of processing, but also because the generated HTML file will be pretty heavy.
Load each template dynamically via Ajax when I need it. Pretty much what is done here. I kinda like this solution even though I haven't tried it yet. It makes sense to me to get asynchronously a template when I need it instead of loading the entire app on the first load.
Use the Bundling mechanism of Asp.Net MVC. I found stuff like csharp-ember-handlebars to precompile the templates on the server-side and return them as a single javascript file. It works-ish but I feel like the precompiled file will become pretty heavy as I add new templates.
Use Grunt with the plugin grunt-ember-handlebars to precompile the templates. I'm not familiar with Grunt but if I understand well all the devs working on the project will have to install Node.js + Grunt + learn how to use a command prompt + remember to run the command before each commit (if they modified a template). This is not obvious for the web designers. And adding grunt to the build actions will require the entire dev team (working on other projects) to have grunt on their machine (not acceptable).
I need to find a simple and elegant solution to address this issue. My project is in a solution with 35 other projects and I cannot add too much complexity to the build, neither depend on unstable libraries. Maybe I have been too optimistic when I thought I could use Ember for my project. Any suggestion would be welcome!
Your #3 is the most ideal (and common) way that I've seen applications handle templates. With a compiled and minified template file you really don't have to worry to much about performance problems in regards to adding new templates, especially if you take advantage of caching.
One benefit to having the templates compiled and available off-the-bat is that users only need to Download Your Resources Onceā„¢, as apposed to downloading resources for each subsequent page load. This leads to a fantastic user experience.