I'm working on an MVC4 site, and I would like to use some resource management software to consolidate & minify JS & CSS (+ less & coffeescript),
SquishIt has all the plugins I want, they're already configured. All the examples show a very simple idea behind SquishIt, which never includes any asset management. It looks like (and the JavaScript model is almost identical):
<html>
<head>
#Html.BundleCss()
.Add("~/Content/first_file.css")
.Add("~/Content/second_file.css")
.Add("~/Content/third_file.css")
.Render()
</head>
What I'm wanting to do is more like this:
_Layout.cshtml:
<html>
<head>
#Html.BundleCss().Render()
</head>
....
App_Start():
Bundle.Css().Add("~/Content/bootstrap.css").Add("~/Content/jquery-ui.css");
_PartialView.cshtml:
#Html.BundleCss().AddString("a:active { color: red }")
The idea behind this is that I would build up the CSS/JS I need as the views recursively render and then the minifier builds, minifies, and caches at the end. AssMan (http://assman.codeplex.com/) does this, but seems less supported and requires more work to get the required minifiers and language support I want.
Ideas, suggestions?
If I'm following your question correctly, I think this issue is about as close as you're going to get (started from this SO thread). I don't really follow though, what bundle should the .AddString call in your example be added to? It looks to me like you are going to end up with a single combined file per view, which is about as bad as you can get from an optimization perspective.
If you read the discussion on that issue and check out the linked commits maybe it will give you some ideas about how to get the functionality you're after (it might actually be the AutoBundler stuff we've implemented, that is available in prerelease now, and will be getting a soft release in the very near future).
Cassette seems to do this natively. It's not as clean of a syntax as I'd like (I'd prefer being able to reference arbitrary scripts and CSS from pages without having to bundle them) but it does work.
Related
I'm in the process of upgrading an old codebase containing jquery v1.2.7 to the v1.2.9. The corresponding UI upgrade is from v.1.6b to v1.9.2 (1.10 doesn't work with IE6). There are a bunch of ui plugins that are atleast 6 yrs old, and most of their authors no longer actively support them.
I took a layered approach of performing this. I first upgraded all the core files (jquery, jqueryUI), then upgraded inhouse js code (attr, $.browser) and such. Then I monkey-patched some of the plugins that had attr and browser. I've managed to work through all the bugs and errors so far. I now have a "clean" build, with a lot of the ajax functionality working as well.
BUT, I'm facing a pretty sticky issue with the facebox.js (yup THAT relic) plugin. I don't see any errors (js, network, or others) in the debuggers (IE8,FB,Chrome), but the facebox dialog displays incorrectly. It still displays the content inside it, but it is transparent and the background and edges do no show. I checked all my css as well as validated using w3c validator. Due to an NDA, I can't post the markup here. I realize that without the markup, even the considerable expertise here might not be able to give a complete solution. Could someone atleast give me some pointers on what I could be overlooking, or things to look for? TIA
eastwood
As you said, without markup it's difficult to figure out what's going on there, and my answer might be really stupid - but since you don't get any errors in the debug consoles and the box is transparent - is it possible that the images are missing/incorrectly referenced in the CSS?
Not sure how this old facebook.js plugin works, but I've seen one some time ago that used images for backwards compatibility with IE6 (for alpha transparency/rounded borders) - but not always. I think for modern browsers it drew that stuff itself. (pretty much like Facebook did it itself on its site)
So perhaps the error is related to JavaScript expecting images/etc. to be handled by CSS, but the CSS uses an only-IE6-hack?
I just spend the last few hours debugging a huge problem, the problem being,
My external css style sheet were not loading when I used Firefox.
Using Firefoxes debugging tools I was able to conclude that the file was not been found, it had nothing to do with the MIME type or encoding as I checked.
I was using relative URL's to reference my style sheets to I decided to use absolute and it worked! after hours of nearly losing my mind.
However using absolute URL's on every page is just a pain and not practical if I am debugging on localhost all the time.
Could anyone tell me why I need to proved the absolute URL's? The CSS file is there and Firefox states the relative URL and when I go to it manually, it works, however Firefox will just not find it. Every other browser including Chrome and Safari Works with the relative URL's.
I could use php and define all these relative URL's and then reference these within my HTML making it easier to switch domains for debugging but still its a pain and I don't know why I have to do this.
My site here
Thanks in advance,
Jack.
Note : For testing reasons I am giving the link to my site which I am having problems with, nothing to do with advertising.
For your stylesheet problem: change the backslash to a forward slash in your <link> element.
<link rel="stylesheet" href="css/main.css">
There are a couple of images with a similar problem.
You have a number of other errors: <script> tags between <head> and <body>, and some loose </article> tags as well
If you're using Firefox, take a look at the page source and fix anything you see highlighted in red. Then try again.
Is there any good way to build Dart app with Web-UI and dynamically loading over network new HTML templates (client side templating)?
It looks like Web UI templates are always load together with generated *.js files:
<head>
<!-- this will be transformed by WebUI compiler to *_generated.js code -->
<link rel="components" href="common_templates.html">
</head>
Currently it's not possible to dynamically load and process templates with WebUI. WebUI needs to process the templates ahead of time. I think #ChrisBuckett suggestion from the other answer/comments would be a great way to go: use deferred loading when it becomes available.
Another crazy idea would be to ship the web-ui compiler with your app and process the templates in the browser. Note, this is not even possible today because web-ui currently cannot be compiled with dart2js (it has some dependencies on dart:io). Hypothetically, if it were possible, it's likely going to be a lot bigger than shipping the extra templates. So, if your goal was to reduce the initial download, then this idea is a no-go.
I am working toward a single page application that dynamically loads new content into the content section of the page based on the menu selected on the left. The content section gets populated from a WebUi component, but it does happen dynamically, and it does happen client side. On the menu, I have something like;
<li> Active </li>
<li> Completed </li>
where i have the application respond to the hash changing when a menu item is clicked. They do something similar in the WebUi implementation of the ToDo app.
The content has a conditional template that loads a WebUi component based on the menu selected.
This may not be what you had in mind. Please provide more details if I am off track here.
It is now possible to performed delayed loading of Dart code. If your client side templates are implemented as Dart source, you can use the DeferredLibrary class.
A more detailed article will likely show up soon in the articles section of Dart website.
When debugging my MVC3 app in Visual Studio using IE9 I see lots of small "script block" entries for my page. My page relies heavily on AJAX, and some actions result in replacing sections of the DOM with partial views coming back from the server.
What I'm seeing is a growing list of these "script block" entries - should I be worried about this? Will this ultimately be a performance problem when the app is live?
Note: the script blocks are quite small bits of code - I've moved most of my significant javascript into their own .js files.
Mm, I thinks it's more of a personal style thing with modern browsers, but if nothing else, trying to contain all the script for a view in one block at the bottom of the page will make for easier debugging and your future self will thank you for it!
As a general rule of thumb I will only have script blocks in pages that need to use the document.ready or variables from my viewmodel. Otherwise, I would move all the functions into their own js file. It helps keep the views cleaner and the browser will load the page faster since it won't block loading the page when it hits as many script tags. Plus, it will make debugging easier since you can go straight to the js file instead of having to find the function within the HTML.
So I know there are various ways of doing, however I'd like to know the "proper" way of including a specific CSS dynamically based on the page I am on. I could include all of them within the site master, however I'm wondering if I could simply include them ONLY when I need it, by either evaluating URL or passing a value through the controller for display flag, or just include it within the content page (outside of the head tags)... I'd like to keep it clean and link them all through my site master, but I'd like to be able to evaluate the page I'm on before I include that CSS..... thoughts??
No matter what its going to be something like this:
<% if( someCriteria ) { %>
<stylesheet type="text/css" href="mypath" />
<%} %>
You could wrap it in a helper or whatever but I don't think there can be a best practice or "cleaner" way of doing something this simple.
" I could include all of them within the site master, however I'm wondering if I could simply include them ONLY when I need it"
Another way to look at this is CSS files are cached by the browser so you may as well include it once and be done with. Your visitors may have a slightly longer initial load time but if you keep your CSS files small it will be barely noticeable. There is very little performance benefit by making it dynamic.
If you're using the Spark view engine, you can use the once attribute on your css include. I personally just put everything on the site master and let the browser handle caching.
http://sparkviewengine.com/documentation/expressions#Conditionalattributeonce
Good, bad, or indifferent, the thing I have been doing for years with master pages is include a ContentPlaceHolder in the <head> section of the master page. I can then inject page-specific CSS through that, instead of cluttering my master page with alot of processing logic. I am doing the same thing with my ASP.NET MVC solutions.
What I typically do is add a to the master in the to allow for pages to include things there. More often than not it is scripts rather than stylesheets, but it works for both.
I'd also vote for getting a Html helper in place to handle this so your developers don't need to care about exactly where the stylesheet is loaded from . . .