I am starting to try out Bootstrap. I have already downloaded the dotless extension but I am confused as to what to do next. Looking at the bootstrap files I see a lot of .less files. Can someone explain where I should put these within the MVC folder structure and how can I set up the application so that when I make a change to a color variable then my .css files get updated.
Update
As suggested I placed all the .less files in the same directory as my css.
However what should I do next? I tried to view the URL
http://127.255.0.0:82/Content/Stylesheets/bootstrap.less
in my browser but got the following message:
(
Expected '}' but found '~' on line 522 in file 'mixins.less':
[521]: .spanX (#index) when (#index > 0) {
[522]: (~".span#{index}") { .span(#index); }
------^
[523]: .spanX(#index - 1);
I currently compile the less files on build with nodejs.
You need to install node.js.
Once installed, in command prompt type: "npm install less -g" this installs the latest less globally (-g on the end for global).
In visual studio, go to Build Events in the websites properties page and put in a "pre-build event command line" like the following:
lessc $(SolutionDir)path-to-main-less-file.less > $(SolutionDir)path-to-where-css-is-output.css -x
EDIT: Bootstrap now uses Recess and npm command has changed as seen here.
Go easy on me, It's my first post! :)
This is a known issue in Dotless:
https://github.com/dotless/dotless/issues/155
Basically the Bootstrap source code is using LESS features that are not yet supported in the version of Dotless that you use. Apparently support has been added in the latest source though, so you should be able to resolve this by compiling Dotless from the latest source.
It is not enough to download and reference dotless.Core.dll, because the binary files aren't up-to-date enough, i.e. they do not contain the latest features that you need for Bootstrap. Only the source files contain the latest changes, so you have to produce the dotless.Core.dll by compiling the latest source with Visual Studio. Of course these features will be included in the .dll download when they next decide to update it.
Dotless produces the result file bootstrap.css "on the fly". You never see that file on the disk, as it is produced by compiling the .less files when they are requested via HTTP. The CSS that is produced is only cached in memory. However you could always request the .less file in your browser and save what you see to a .css file. That would work but there isn't much point in doing it if your Dotless installation is working properly.
However, if all you want is a bootstrap.css file with your customized values, you can also use this online tool on the Bootstrap website. It will let you change the variable values and download the resulting CSS.
Have you tried Mindscap Web Workbench?
They have an article on how to set it up for use with Twitter Bootstrap.
You can use Combres to with my dotless plugin here. All you need to do is reference bootstrap.less and all the imports will work out of the box with clean Bootstrap less files. Combres will build and cache the bootstrap file and even compress it with other non-Bootstrap css files. This is the ideal setup.
http://pknopf.com/blog/using-less-correctly-with-combres
Related
I have installed Visual Studio 2013 with Update 2 and installed Web Essentials.
I had thought this was going to make adding LESS to my views a piece of cake, but am missing something.
The editor is great, and I imagine that it is compiling to css on save...
But I don't know where the generated css is, and I don't have any clue as to how to get it reference in my view.
I've tried a lot of searching, but can't get through the web of links about installing this and the features of that.
Any help at all will be greatly appreciated.
Thanks!
When you add a .less file and save, the Web Essentials will compile and generate the .css and .min.css files. You will see an arrow in your solution explorer, or you can also confirm in your file system that the files are in the same folder.
Haven't used less with vs2013 but I have used sass and my guess would be the same. By default the generated css gets generated in the same directory as the source (as it seemed to me) but you can check via tools>options>web essentials and there should be a set of options for less compile on save, build and directory to name but a few.
If you right click on the solution there should be an option to create a web essentials settings file for the solution - these create and adds a json file of web essentials settings to the solution which means your settings are local to the solution which could be important if you are changing the output directory.
I'm not used with "publishing" a project via visual studio. I'm trying to do so since yesterday and I've found out these things:
All the images contained in my application in a specific folder (example: MyProject/Images/Image1.jpeg) are only copied the same way they are in my project;
None of my controllers/utility class appears in the published project;
However the views are presents and the javascript files as well, but as they are, so a MyApp.js will be copied as a MyApp.js.
So my question is: is it supposed to be that way? What about my logic, ain't it not supposed to be copied as well? And shouldn't it be compressed, compiled, or protected in a dll, else everyone will be able to see my code in public, which I do not want?
Feel free to teach me what's a publish is supposed to do and what went wrong. thanks!
Publish is supposed to do almost what you mentioned only..
Images in content folder
any stylesheets in the content folder
Scripts in script folder
All View files Anything with Build Action = Content
The compiled files form the dll of your binary & dependencies
Infact all the images, css, javascripts will also have buildaction set to content only.
If you have a file selected in the project and it is not found in the folder, if its build action is "content", the build will succeed but the publish may fail. So in this case you may have to exclude the file if it is not necessary or add the file in the folder
Most of the automatic build systems like cruise control also do the same though with quite an advanced interface.
Your logic in c# or vb.net is already compiled into the binaries. But any script or styles or scripts inside html won't be protected. But bundling the scripts and styles using the BundleConfig may protect it to some extent.
All Your logic is converted into dll's so just create an instance on IIS and host your application there. You can follow the steps shown here.
I'm working on a little web application using Express.js, Backbone.js, Bootstrap and some others. I've decided to give Bower a try to manage the front end components for this one, but after installing the packages, I noticed that all of them installed tons of stuff that I don't need at all, like LESS files (Bootstrap) or QUnit tests for the framework (Backbone), README.md files, documentation source code, and so on:
As you can see, it's absolute madness in here.
I've searched the package index a bit and I've found a leaner version of Bootstrap called bootstrap.css, but after installing I noticed it is still version 2.3.2, so pretty much outdated.
Isn't there a way to install up to date dist versions of all those libraries?
The idea of having a package manager is nice but it seems a bit off putting to have my application source bloated with all this stuff. I most definitely do not need the Backbone documentation installed on my web server.
This is a matter of package authors not configuring their bower.json to ignore those extraneous files and folders. Additionally, not all package authors configure their bower.json to list the main file(s) for their package.
You can see how without having those two pieces of information-- what files aren't needed, and which ones are the "main" files-- Bower, or any other tool, can't reliably guess what is necessary and what is junk.
As far as it bloating your server; ideally, you shouldn't be committing Bower components. You would have a build process that takes your source files, wherever they may be on disk, and morphs them into one minified file.
You can try bowercopy.
What does it do?
Download all the bower components listed in bower.json
Copy files you need to specified folder
(Optional) Remove the bower_components folder.
Every time you run the bowercopy task, it will do the process above.
A grunt config example
bowercopy: {
options: {
destPrefix:'app/jslib', // Here is the dest folder
clean:true // It's optinal
},
dist: {
// List all the files you need here
src:'backbone/backbone.js' // "src" can be an array
}
}
Yeah, You have to specify all the files you need one by one. But it does achieve your goal.
(and why do you think the jQuery team are unable or unwilling to write decent documentation?;)
For example, go to http://jqueryui.com/download/all/ and download either
jQuery UI 1.10.3 (source, demos, themes, tests)
jQuery UI 1.10.3 Themes
#1
There is a MANIFEST file.
There is a README.md file but no explanation of the the layout of the archive.
There are several files with a JSON extension e.g. ui.accordion.jquery.json. They contain some information about the particular UI widget. I don't know what these are used for, do you know?
A file named package.json. It seems just to be some library info in JSON format. Do you know what this is for? I suspect it's linked to the other .json files, but who knows?
There is an directory named external that holds javascripts. Do you know what this is for?
There is the jquery-1.9.1.js file. No minified version.
A licence in MIT-LICENSE.txt.
An AUTHORS.txt file, which contains the names of the contributors, that are repeated several times throughout the archive. Not one of them managed to list what's in the archive thoroughly though ;)
A demos directory with what appears to be all the demos from the website.
A Gruntfile.js that the README says is used to build jQuery. Whatever "building" jQuery means.
A tests directory.
There is a directory named ui that seems to hold all the jQuery UI effects javascripts, also minified in a subdirectory, and an i18n subdirectory for those widgets that need internationalization.
There is a directory named themes. In it there is a subdir called base that holds the base theme stylesheet. This subdir also contains an images dir for the base theme. It also holds stylesheets for several of the effects e.g. jquery.ui.accordion.css. Do these only work for the base theme or can they be applied to any theme? If not, why does only base have them? (see below) There is also a minified subdir which has minified versions of all the stylesheets.
#2
The archive contains a MANIFEST file
but no README.
An AUTHORS file.
A package.json file with a small amount of information about the project.
It has several themes but no base.
There are no effects/widget files in either the root directory or each of the themes' directories.
Each theme directory contains an images subdirectory with image files associated with that theme, a jquery-ui.css stylesheet, a minified version of this, and a jquery.ui.theme.css. The jquery-ui.css in each theme directory is different to each directory. Do you know what each of these files is for? Why aren't all the specific changes in the jquery.ui.theme.css file?
Why do I need to know this?
This may come up in the comments so I'll answer it here. I've written a couple of libraries to help with deploying the correct version / theme in Ruby Rack projects, Rack JQueryUI and Rack JQueryUI Themes. Every time there's a version change of jQuery UI I have to deal with these undocumented archives, that also seem to change in layout / contents between versions. I've not had good feedback when speaking with the jQuery team - I find they are lamentable at documentation and it's obviously not a priority for them, they'd rather be renaming functions or something - so I'd rather just have someone helpful answer me here, and this will make a good place to keep it (out of their reach, so to speak).
I'm most interested in the questions around the theme directories as that will directly help me right now, but I've extended the scope of the question because I believe it will help others and I am curious.
Let's start with an explanation of what jQuery UI downloads are: They're a full bundle of development and production files. Keep in mind that jQuery UI is downloaded over 11,000 times per day (and that's just the download builder usage). The ways in which these downloads are used can vary greatly among users. The contents of these downloads are intended to serve the largest number of users. It's important to note that the development bundle is almost an exact copy of the source repository.
source, demos, themes, tests
MANIFEST: This is a file containing a list of every other file in the zip, along with checksums. Very few users will care about the manifest, but for those who do care, it provides critical information.
README.md: (note that you listed README.txt): This is the README for the jquery-ui git repository. It's an exact copy of what you will see if you view the project on GitHub.
*.json: These are plugin manifest files for the jQuery Plugin Registry. These files are never stored in the master branch (or any other branch), but are always included in tags. Because they provide useful information, they're included in the downloads. You can read more about the manifest file structure.
package.json: package.json is a standard file for use with npm/node. All jQuery projects rely on node to do linting, testing, builds, releases, etc. This is completely separate from the other JSON files which are for the jQuery Plugin Registry. They have very similar structures, because the plugin manifest files were designed based on npm.
external: This directory contains third party scripts which are used in demos and tests.
jquery-1.9.1.js: This is the latest stable version of jQuery that jQuery UI was tested against. We never include minified jQuery versions in the jQuery UI repository since they're horrible for debugging.
MIT-LICENSE.txt: The license which defines the terms under which you can use the files in the download.
AUTHORS.txt: A list of contributors to the jquery-ui repository. This does not include contributors to other parts of the jQuery UI project, such as work on any of our various sites or documentation.
demos: A directory of demos for the selected components (in this case all components). The demos actually originate in the jquery-ui repo and are copied to jqueryui.com during releases.
Gruntfile.js: We use Grunt for linting, testing, and building. Grunt is a JavaScript task runner for node. Building jQuery UI means minification and concatenation.
tests: A directory of tests for the selected components (in this case all components).
ui: A copy of the source files, with #VERSION replaced with the release's version number. The jquery-ui.js file is generated during the build by concatenating all of the source files together. The minified directory is generated during the build by minifying the individual files. And of coure jquery-ui.min.js is generated by both concatenating and minifying the source files.
themes: A copy of the source files, with #VERSION replaced with the release's version number. This undergoes the same process as the ui directory regarding concatenation and minification. The individual component files are theme-independent. So jquery.ui.accordion.css will work with any theme. These are the required CSS files for use with the JS files. You can build any theme you want, but if you don't use the functional CSS for the component, then nothing is guaranteed to work. Full themes (what pretty much all users actually use), contain all of the functional CSS plus the theme CSS in a single file.
themes
Themes are generated by ThemeRoller. They do not live in any repository and as such do not contain artifacts of any repository. This is why there is no README.
MANIFEST: Same as above, the manifest contains checksums for the files in the download.
AUTHORS.txt: A copy of AUTHORS.txt from jquery-ui. This should exactly match the source download. While this isn't a list of people who have contributed to themes, we view this as part of the code and include the same list of authors.
package.json: A copy of package.json from jquery-ui. This file does seem a bit strange, since it's not coming from a repository. We should probably remove this.
themes: A directory of generated themes. These do not contain the source variables/tokens. The base theme is not a generated theme and therefore is not included. You'll notice that generated themes also have a different directory structure. Each theme contains three files: jquery.ui.theme.css is just the theme CSS; this is what can be used with the functional CSS provided in the base theme. jquery-ui.css is a full theme; it includes the theme CSS plus the functional CSS. jquery-ui.min.css is a minified copy of jquery-ui.css.
jQuery UI has decided to simplify its package (extremely) in order to help avoid confusions such as the above. From 1.11 and on, we distribute
https://github.com/jquery/download.jqueryui.com/pull/214. On any new questions just let us know.
When you add a script bundle and have something like:
bundles.Add(new ScriptBundle("~/bundles/base.scripts").Include(
"~/Scripts/jquery-1*"));
It loads up the raw Jquery version and the minified version. Those files are both in the Scripts folder so I assume the asterisk is doing exactly what you tell it.
Is there a way to have only the minified version render when in debug=false mode and the raw version in debug=true?
Or is it down to actually specifying the exactly files you want instead of using the asterisk?
Regards,
Jacques
This should be happening automatically via the BundleCollection's FileExtensionReplacementList which should be selecting the .min version of the file when debug=false. The default templates when you create a new project should be using this functionality as well.
Although this question is now over a year old, in case someone stumbles across it in need of help on the same problem, Bundling introduces the {version} wildcard which uses a regular expression to look for a typical version number pattern (such as 1.9.1) so that when you update a package manually or via NuGet you don't have to go and change your Bundles configuration.
It will also be smart enough to select from files named .min.js and .js - using the former in release configurations and the latter in debug, exactly what the OP is after.
For ASP.NET MVC 4, this means with a debug configuration, the file
jquery-1.7.1.js will be added to the bundle. In a release
configuration, jquery-1.7.1.min.js will be added. 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.
See Bundling and Minification and {version} wildcard in MVC4 Bundle
Word of warning though, if you have both jQuery-1.9.1.js and jQuery-1.10.2.js in the directory (for example) then both will be matched and added to the bundle - something that obviously is not desirable.
Note also that the minified version of the file must be named file.min.js, not file-min.js or min.file.js for this to work. The YepNope library for example is named yepnope.1.5.4-min.js when you get it via NuGet which means both this and the unminified version are added to the bundle.