While we are using Assetic with Twig templating, we want to delay the actual processing until the last moment for various reasons. So instead of using the javascripts, css tags of assetic we created something like this
{{ add_asset (['public/js/prototype-handler.js', 'public/js/shipping-method.js'], 'js') }}
Anyhow, the idea is that at the end of the response event we will process and inject all assets to the content. However, right now I'm stuck at how to add these assets to assetic so they can be processed and returned with the result file(s).
I have checked some other bundles and what they are doing right now is to render the assets via twig like this:
AssetManagementBundle
However, it doesn't seem to be an optimal approach to this. I wonder if there is a better way or not?
For people who may encounter this same need, you want to use createAsset of the AssetFactory.
Then you can loop through the created assets and do what you want with them.
For more information and working code, please check our bundle here
I'm not sure to completely understand your needs but you could be interested by the AsseticInjectorBundle, it allows you to tag your resources files in a configuration file and add it by adding the tag where you want in your assetic markup, in your layout.
I don't think dealing with resources in php is a great idea and it's better to do this directly in your layout coupled with some configuration file.
Related
I have a website which uses 1 css file, it is called body.css and it consists of 841 lines. Should it be sorted in different files (header.css, footer.css page1.css, etc...), is it better in just 1 file or does it not matter?
The only thing I know for sure is sorting it in more files is a lot more readable.
Also if someone answers this I'd be most grateful for a little explanation.
My opinion would be one of two things.
1) If you know that your CSS will NEVER change once you've built it, I'd build multiple CSS files in the development stage (for readability), and then manually combine them before going live (to reduce http requests)
2) If you know that you're going to change your CSS once in a while, and need to keep it readable, I would build separate files and use code (providing you're using some sort of programming language) to combine them at runtime build time (runtime minification/combination is a resource pig).
With either option I would highly recommend caching on the client side in order to further reduce http requests.
So, there are good reasons in both cases...
A solution that would allow you to get the best of both ideas would be :
To develop using several small CSS files
i.e. easier to develop
To have a build process for your application, that "combines" those files into one
That build process could also minify that big file, btw
It obviously means that your application must have some
configuration stuff that allows it to swith from "multi-files mode" to "mono-file mode".
And to use, in production, only the big file i.e. Single CSS
Result : faster loading pages
maybe this will help you..
For optimal performance it is better to have only one css file.
But for readability it would be better to have different files for different parts.
Take a look at tools like SASS, which help do that without sacrifice performance. Additionally it has features to make your files even more readable by introducing variables, function and much more.
Using more files means more requests. It will take more time to load and make unnecessary requests to the server. I'd stay with one file.
The only good reason to have other css files would be if you have third-party components, to keep them separated and be able to update them easily.
The order matters: Rules loaded later will override rules with the same name loaded before (this is valid even for rules in the same file).
What do you mean that your website uses one CSS file? Normally you'd write your style definitions in multiple files, and they are concatenated (or not) into one file. My point is, what you are working on in your development environment should stay modular, readable, it shouldn't be influenced by what you have in production.
As for the order of the CSS files, yes, it matters, as you can overwrite your previous definitions.
For optimal caching I'd recommend you to build all the vendor CSS in one file, and your CSS in another file, versioned, so that if you change something in your code, only that file has to be updated by the browser.
But these things depend on the infrastructure. As the browsers are able now to send multiple requests simultaneously, having multiple files can lead to faster page load than only one. But I'm not sure about this.
you might want to take a look at gulp to automatically optimize, and minify your CSS code.
All css in one file is OK.
But it's free : you can make as many css file as you want.
However usually this is how it is:
1 global css file for the entire page. You put the common css in here that is useful for every page on your site. You can call it app.css or style.css or mywebsite.css or any name you want.
1 specific css file for a specific page when you want to specially separate this css from the global css file. Because it will contains css only useful for a few pages. For example you have a special component made by your own or a special functionnality. Example : you have made a spcial javascript code working with some html for uploading some file and you want to have your code js/css separate.
Usually, you can also have one css page for each page, but always one global css file for the entire site.
Note : Same question is also valid for javascript
Note 2 : You can also think about using a framework to minify your javascript and css into one single css / js file at the end. At work our technical boss use wro4j which works for java but it should exists many more other frameworks as you can search on google.
My default ASP.NET MVC 4 project has bundles created for JQuery and JQuery UI that is referenced in the pages.
I want to change this to use an absolute link from a CDN instead of relative on my web server.
I thought it could be as simple as just changing the url's in the bundles to point to the CDN urls. I understand why this won't work because bundles essentially bundle everything up into one file. These cases, I only have one file though.
I'm wondering. What is the best practice here. Basically, I want the code to exist in my layout or even individual pages that directs the view to load the script tags for these scrips. Then I can manage which script tags are included. The same way we do it with bundling, but I want it to work by doing the bundling and also do any other alternative script tags instead of the bundle. This way I can swap in and out depending on how I feel I want to manage my scrips at any one time. Let's say I want to add another js file to the bundle some day, or I want to include another script that will have it's script tag rendered on every page. I want a central place to do this.
Thoughts?
I'm using rails with compass.
When using rails without compass, rails has a css per each controller, which contains things that are only relevant to the views in that controller.
I couldn't get the same behavior with compass, which resulted in having a big monolithic file instead of separate files per controller.
What is the recommended approach to solving that problem?
Rails (since 3.1) does create a css file per controller but it's only for practical code separation, all code assets get compiled into one master file per format (.css, .js..), and this is the best practice 90% of the time.
If you want to use this approach with SCSS or SASS code, just change the file extension to .css.scss or .css.sass (ie: mycontroller.css.scss)
If you want to separate the compiled files per controller (you probably don't need it, so i'd advise that you understand the asset pipeline before doing it), you'll have to implement the custom behavior yourself. take a look here http://guides.rubyonrails.org/asset_pipeline.html
Regarding ASP.NET 4.5's new System.Web.Optimization / Microsoft.AspNet.Web.Optimization:
Can anyone explain the difference in the use of bundling resources using the BundleConfig.cs class file as opposed to the bundle.config xml file?
I've seen some articles showing bundling both js and css in BundleConfig.cs, while others showing bundling js in BundleConfig.cs and css in bundle.config.
I guess I don't understand #1) why you wouldn't just do them both one particular way for simplicity - and #2) why anyone would prefer to hard-code resources like that in a class file? It seems like a much more dynamic approach to just put them in an xml file that can be changed on-the-fly if necessary.
It seems like more articles actually lean toward using BundleConfig.cs than anything else. Is there some particular pro or con that encourages this?
Also, if there is any real documentation on System.Web.Optimization, I would love to know the location (because I sure can't find it).
Thanks-
As far as I can tell, the accepted answer doesn't actually answer the question at all. It discusses the benefits of the bundling framework, but not how using the BundleConfig.cs is different than using the bundle.config file.
A lot of it comes down to whether you prefer working in code or in markup, but each does have some pros that are specific to that method.
For the bundle.config, there's really only a single benefit, but it is a big one. By using it, you can manage bundles without having to touch code at all. This means that you can make changes without recompiling, making quick deployments easier. Also, it means that your front-end developer, who is going to be most familiar with the files that should be bundled, can define the bundles without having to work with any back-end code.
However, there are quite a few limitations on what you can specify in the Bundle.config. For instance, you can't specify any custom transformations to be applied to individual items or bundles. The only bundle properties that you're able to set are the Path, CdnPath, and CdnFallbackExpression. You can't set the Orderer or EnableFileExtensionReplacements properties. You don't have a way to include a directory including all subdirectories (like you can with the IncludeDirectory method). Basically, there's a LOT of functionality that is only available through the back-end code. Granted, a lot of this you could set by using back-end code to retrieve a bundle that was defined in the bundle.config, and then manipulating. But if you're going to do that, you might as well create the bundle in the back-end, also.
My personal philosophy is to use bundle.config unless I need to do something with the bundle that's not possible that way. However, I do agree that having them all in one place is ideal. If I decide I need to use the class, then I'll use that for all of my bundles of that type (I do sometimes put my JS bundles in the class and my CSS bundles in the .config file, though). I'm sure some completely reasonable people would disagree with that process, though.
this documentation explains it all better than I ever could
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
One of the nicest things is this:
The bundling framework follows several common conventions such as:
Selecting “.min” file for release when “FileX.min.js” and “FileX.js”
exist.
Selecting the non “.min” version for debug. Ignoring “-vsdoc”
files (such as jquery-1.7.1-vsdoc.js), which are used only by
IntelliSense.
Can anyone explain the difference in the use of bundling resources
using the BundleConfig.cs class file as opposed to the bundle.config
xml file?
The difference is that you would have to read, parse and load the content of the bundle.config at runtime. Hence, using BundleConfig.cs class file could be simpler.
1) why you wouldn't just do them both one particular way for simplicity
Totally agree.
2) why anyone would prefer to hard-code resources like that in a class file?
Simply put: easy to understand.
It seems like a much more dynamic approach to just put them in an xml
file that can be changed on-the-fly if necessary.
Yes, but you have to write more code to detect when changes happen and then add/remove/replace existing setup. If done poorly, it could lead to UI issues at runtime.
Also, if there is any real documentation on System.Web.Optimization, I
would love to know the location (because I sure can't find it).
Already answered above, but I would repeat: http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
I am starting a new project using Symfony2. I am adding some basic twig templates like my CSS template (with assetic to trigger sass -- nifty) and my header/footer template. My question is, should this sort of thing go into app/Resources or into Acme/MainBundle/Resources?
I am sure I can do either if I really wanted to, but I'd like to know what the correct way to do it is.
app
Resources
<A. here?>
src
Acme
MainBundle
Resources
<or B. here?>
It's really a matter of preference. I tend to keep global views in app/Resources. Does your MainBundle contain anything else besides views? If not, I think that's more reason to use app/Resources and avoid unnecessary bundle pollution.