I'm going to use the angular generator for this example. All files that have indentation are generated with a 2 spaces indentation by default but I want to use tabs instead.
Is there a way to let yo know that I want to use tabs before generating the app?
edit: it seems this is underway but not available as of now.
See https://github.com/yeoman/generator/issues/460
As of version 0.18, generators can use gulp plugins to process file writes. This allows generators to ask a user their preferred indentation and apply it to the output.
You can see more about this technical detail on the release announcement: http://yeoman.io/blog/release-0.18.html
It is important to note that every generator is free to implement that feature. It is not something yo will (or can) enforce on his own. So feel free to open tickets on the generators you'd like to see implementing that feature.
Related
I need to take a database text field and parse it for
duplication and garbage
malice
whitelisted selectors
compress and output as a css file
Since there might be a rails way I'm unaware or something ready made I'm asking before I waste time trying to reinvent a wheel. My searching revealed nothing, mostly in rails seems aimed at view level, and css seems to be an unattended niche in this area (plenty of html though).
I'm aware of the sanitize gem (doesn't do css immediately, yet another thing I'd need to map out and code) and the built in rails stuff (not a lot of tutorial, aimed mostly at the view level). I need a gem, lib, module or something similar that I can work with in a controller or queue.
EDIT:
Without getting too deep into the specifics of the project: administrative users can add css for their portions of the site. As part of the flow I'm going to save the raw css and then process and save the processed css. The db stuff is archival mostly, the css file is output immediately. Because there is few places to add modified css and only admins have access to the css, it sort of works but I'm looking to make it more robust in the future where admins who may not be as conversant with the security needs or not as css aware can operate.
The most basic example is that it just a text field on an admin page. The admin cuts and pastes css there, submits, and the application turns it into a css file that gets included with the designated pages, which works because the current admins know the application, the css of the application, and what they can and cannot change. The goal is to make this more robust for future admins who might not be as savvy.
To simply sanitize CSS, you can use the SanitizeHelper built into Rails: http://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize_css
Have you looked at Sass? It has all of the parsing logic built in, for a superset of CSS. You could add a feature (Sass support) and save yourself the need to parse/validate the CSS all in one go.
You can generate output CSS from Sass (or just plain CSS, since Sass [with the SCSS syntax] is a fully-backward-compatible superset of CSS) like this:
output_css = Sass::Engine.new(sass_content, :syntax => :scss).render
There are a bunch of options that you'll probably want to look into at http://sass-lang.com/
Another option is Less. The new Twitter Bootstrap framework uses Less, and Rails 3.1 uses Sass. The biggest difference is that the official Less parser/compiler is built in JavaScript, so you could actually validate and compile in the user's browser while they work and show them any errors before they save. Of course then you need to run a JavaScript engine (e.g. V8) in your Rails application if you want to use Less to validate the incoming CSS still.
Note: This question refers to a Rails project with Sass & Compass.
Using the Rails Asset Pipeline? Then have a look at this question.
We are developing a big application with many use cases and many individually styled pages, partly for multiple contexts. Which simply means a lot of style information.
With the newest section of our application, we have broken Internet Explorer's limit of 4095 selectors per stylesheet. (Want a proof of this limitation? http://marc.baffl.co.uk/browser_bugs/css-selector-limit/)
Okay. So, why do we not simply split the application style sheet into multiple ones by design?
Well, mixins and selector inheritance will not work across multiple Sass files (not partials), right?
I'd say the quality of the stylesheets is rather good, we cannot optimize away the exceeding amount of selectors. (There is rather more to come.)
I also believe that minimizing the amount of selectors should not be our primary optimization goal. The Sass core team advises to use selector inheritance instead of mixins where applicable in order to save CSS file size. By doing so, the number of selectors tends to grow though.
So what should I do?
I am thinking about writing a script that generates additional css files, partitioning my big application.css file. These would only be loaded in IE then (so that I don't have multiple requests in modern browsers).
I would need a simple css parser for that in order to cut the application.css file after max. 4095 selectors at a valid position.
And I would need an compass compile - after hook so that developers don't need to generate the IE files by hand in order to test it.
Please, tell me, that you got a better idea!
Best,
Christian
Mixins are usable across multiple files. However, it is logically not possible that #extend may work with multiple files. It is the purpose of this directive to result in a single rule
(which should not be duplicated across multiple files). Therefore, I cannot split up files.
Thus, I implemented a splitter: https://gist.github.com/1131536
After these two commits have found their way into Sass and Compass, you can use the following hook in your Rails config/compass.rb in order to automatically create the additional stylesheets for IE:
on_stylesheet_saved do |filename|
if File.exists?(filename)
CssSplitter.split(filename)
end
end
Update:
The CssSplitter mentionend above has been release as a gem: https://github.com/zweilove/css_splitter
If you can't reduce the number of selectors, there is no choice other than to split the CSS file.
Your proposed solution for doing so already sounds optimal, if a little complicated to implement.
An easy way to do it is http://blesscss.com/.
Simply :
install node.js
Execute npm install bless -g
blessc source.css output.css
Does anyone know where I might be able to find free scaffold templates (i.e. .css files)? I'm doing a quick and dirty project, and I'm just looking for something generic, but a bit more visually appealing than the extremely generic default. Actually I'd be especially interested in something that look similar to the Django Admin section, but I'm not that picky, really.
Try this out: https://github.com/pilu/web-app-theme -- it's a basecamp/lighthouse type admin template (including css).
It'll work in both rails 2.3 and rails 3 -- the github readme has details.
I've used the Blueprint CSS Framework (http://www.blueprintcss.org/) for stuff like this in the past.
After several Google searches, it appears that the way to create PDFs in Rails from HTML and CSS (versus a new markup language) is to use Prince.
With licensing at $3800 for my non-big-commercial app, I'm wondering if this is, in fact, consensus or people have an alternative they can share the whats and hows.
You may check out prawn too. Tutorial can be found on railscasts.com.
This may fit the bill: http://code.google.com/p/wkhtmltopdf/
We tried tow solutions:
using latex generate pdf, there is ruby gem code rtex
using java library iText, use it you may need rjb which allow you using java lib directly in ruby code, just like jruby, but you don't need build all you application on jruby.
I create tons of different PDF files on the fly from various data sources using Rails, including finest layout. I create need to create them for presenting products to customers.
After having tried all the tools mentioned above, Prince is the best tool for this task.
Prince's rendering quality & CSS support (better than some browsers) is its main selling point. If you're only generating documents with simple layouts, stick with Prawn.
I've got some experience using haml (+sass) on rails projects. I recently started using them with blueprintcss - the only thing I did was transform blueprint.css into a sass file, and started coding from there. I even have a rails generator that includes all this by default.
It seems that Compass does what I do, and other things. I'm trying to understand what those other things are - but the documentation/tutorials weren't very clear.
These are my conclusions:
Compass comes with built-in sass mixins that implement common CSS idioms, such as links with icons or horizontal lists. My solution doesn't provide anything like that. (1 point for Compass).
Compass has several command-line options: you can create a rails project, but you can also "install" it on an existing rails project. A rails generator could be personalized to do the same thing, I guess. (Tie).
Compass has two modes of working with blueprint: "basic" and "semantic" usage. I'm not clear about the differences between those. With my rails generator I only have one mode, but it seems enough. (Tie)
Apparently, Compass is prepared to use other frameworks, besides blueprint (e.g. YUI). I could not find much documentation about this, and I'm not interested on it anyway - blueprint is ok for me (Tie).
Compass' learning curve seems a bit stiff and the documentation seems sparse. Learning could be a bit difficult. On the other hand, I know the ins and outs of my own system and can use it right away. (1 point for my system).
With this analysis, I'm hesitant to give Compass a try.
Is my analysis correct? Are Am I missing any key points, or have I evaluated any of these points wrongly?
The ideal goal is separation of style and content: it's not always possible 100%, but it can be done reasonably well by using semantic markup. Blueprint and other CSS frameworks utterly fail at this.
The original idea behind Compass was to avoid polluting HTML with the visual markup that Blueprint generates: if you're writing class="column-4" in your markup, then you might as well put style="width:160px" in there instead. Semantically it's the same meaning, and the same amount of repetition to maintain.
Compass turns a Blueprint class like .column-4 into a mixin which you can apply to a meaningful selector:
#sidebar
+column(4)
This way, you only need to maintain it in the stylesheet, not across a number of templates and HTML files.
Compass is project-aware. It will handle compiling your whole tree of stylesheets, even automatically on save when you run compass watch.
There are some very helpful functions provided by compass, for example:
image_url is a configurable function that can handle relative or absolute paths or even set up rotating asset hosts if you need to.
The CSS3 module takes care of all the browser-specific style rules for rounded corners, shadows, etc.
General utilities provide helpers for the stuff you do all the time, but with less repetition (especially for the cross-browser issues). These are some basic ones I use a lot:
+clearfix and +pie-clearfix (cross-browser clearing methods)
+float ensures you don't forget display:inline in front of it for IE... (if the time comes to drop the old IEs, it's one single change.)
+replace-text hides text and positions an image replacement background.
+hover-link adds the :hover underline rule to a base link style
You can check these out on the new docs site for Compass.
Then, Compass provides the facilities for a number of other style frameworks in addition to the built-in Blueprint. Do check out Susy for example, which is a Sass-native layout framework, not just a CSS port. It specializes in flexible and fluid grids.
'Semantic mode' refers to the possibility to use more semantic class names than the ones css frameworks ship with: .article vs .grid_1. which i personally think is a big +.
I'm not sure if these resources have only shown up recently, but have you seen the Compass CSS3 helpers and the General utilities - (both well documented in my opinion) - they've really sped up my interface builds a great deal.
Another great resource is the Compass plugins page.
Personally I like to copy these utility Sass files out the rubygem and manually include them in my project's Sass files as it feels pretty weird referencing Sass which is stored out of the project.
Compass looked like a great solution for me as well, but after trying it on a project I didn't really see the great advantage of using it for me. Like you, I'm just fine with blueprint, and I didn't see the need to add yet another layer on top of haml/sass.
I eventually stripped the compass from that project and just go with a sass version of the blueprint CSS files, and go from there. I store any custom/additional styles in a separate sass file and that's it. No need for compass or anything like that if you just want to keep it simple.