I am using SASS on my Symfony2 and I read few articles about recommended architecture of sass.
base/ – contains global styles, such as resets, typography, colors,
etc.
components/ – contains each self-contained component in its own .scss
partial
layout/ – contains styling for larger layout components; e.g. nav,
header, footer, etc.
pages/ – contains page-specific styling, if necessary
themes/ – contains styling for different themes
utils/ – contains global mixins, functions, helper selectors, etc.
vendors/ – contains 3rd-party styles, mixins, etc.
main.scss – output file that brings together all of the above parts
In examples they are loading all of files at the same time, but I am concerned that I should separate different page styles and their loading.
I wanted to ask if loading all of .scss files at once doesn't slow the page? Why separation is not mentioned? Inheritance of variables? Why?
Separation of files makes for easier development - not having to search through hundreds or even thousands of lines of SCSS whenever you want to make a minor change is much better - but don't worry; it won't slow down your pages.
When SASS compiles it merges the SCSS files into one CSS file and often minifies it at the same time.
Related
Can somebody give me an eagle eye perspective on Magento blocks, layout and templates and how they relate to each other?
I understood that blocks are the basic building-blocks that a page is made of and that they are kind of mini-controllers.
I also understood that layout brings these blocks somehow together.
But there is still some uncertainty about templates and how they relate to blocks and layouts and vice versa.
What are blocks?
There are basically 4 things you need to know:
There are two types of blocks: those that automatically render their
children and those that don't. Knowing which type you're using will
help you in debugging.
Magento blocks are essentially models that contain logic for your view templates. Mind you - this is not business logic, but it is logic
related to the display of the information you're presenting. This is
by definition presentational logic. If you're familiar with Zend
Framework's Zend_Layout you could draw a comparison between custom
view objects and layout helpers.
The template file assigned to a block object can execute code as if it is local to that object. That is, $this corresponds directly to
the block class.
Layout actions are a thing that people use.
Two types of blocks
There are two types of blocks at the end of the day - those that
render automatically and those that don't. Take notes because this is
on the Magento Certification exam!!
Auto-rendered blocks
When defined in a layout, any block of type core/text_list will
automatically render all its children. While core/text will
automatically render itself it really only should contain text and
therefore is not useful for layout purposes (though some clever things
can be achieved with them).
Other blocks
Any other block type will need to be rendered manually. Provide the
block an alias which can then be passed to getChildHtml, returning the
content which you then echo.
Layouts And Templates
As the name suggests, layout files are useful in rendering front pages
of Magento. Layout files are XML files that reside in in app > design
frontend > your interface > your theme > layout. Here, you can see that there are many layout files for any given module. Each Magento
module has its own layout files much like the customer module has the
customer.xml layout file, catalog module have catalog.xml layout file
etc. These layout files contain structural blocks and content blocks.
read the following blogs. it will clear your concepts for magneto.
http://alanstorm.com/category/magento
http://devdocs.magento.com/guides/m1x/magefordev/mage-for-dev-4.html
http://blog.philwinkle.com/the-most-misunderstood-concept-in-magento/
http://code.tutsplus.com/tutorials/custom-layouts-and-templates-with-magento--cms-21419
Blocks are the building modules of a page. They can be treated as "bricks". Now every block comes inside a layout. Layout is used to define the "shape" of the page. Now templates are used to define the behaviour of a particular block. That means each block or "brick" will have different charateristic depend upon the template it is used.
That is, to construct a magento page, you need to define a layout first that will give you an idea of shape of that page. Now you fill the layout with blocks. Each blocks now concentrate on a particular section of the entire layout. That means depending upon the "nature" of block, each small section will behave differently. To define the unique nature of a particular section, blocks uses templates (templates actually holds the webpage building codes, ie html + js + php)
I hope that will give you a short idea.
Try to google this. I am sure there are lot of lot of tutorials, blogs available about this.
I'm building my first ajax-heavy application and am not sure of the proper approach for such things.
If, for example I ajax in a html partial (a form), with:
$('#content').load('form.html');
how should I include the javascript and css?
I can, of course include them in the original document, but that seems wasteful if the form is never loaded. I can inline them (in form.html) with <script> and <style> elements, but that seems like the wrong approach.
You can use a separate JS file and load it using $.getScript() in the .load callback.
Inline CSS should work fine, but since you run the risk of it messing up your main page, you should load it as part of the main page and not with AJAX.
If it were me, though, I wouldn't be afraid to leave a few extra lines of well-targeted JS and CSS code in your main page -- it's more efficient to load it with the other JS and CSS at the beginning, in the same file(s), than to fire off another network connection and wait for it to download.
The $.getScript() would make an additional http request to load the js file that is to be used in form.html.
So, say for example, if you load 20 forms via ajax, you have to make 20+20 http request( 20 for loading js file and 20 for loading the html for forms)
A possible optimized approach is:
loading the all the css ( minified) at the beginning.
IF a single js file is real large even after minifying,
Arrange the js functionality based on the PROABABILITY of use in different files ( (the fewer number of files , the better).
Minify those files and load the file with highest probability at the beginning .
And then use $.getScript() to load the file after checking if the file has already been loaded.
I'm creating a template override for k2 (although I guess in some ways this question could apply to any Joomla extension).
Now I've created my override in template/html/com_k2 absolutely fine. Then I went to go and update the stylesheet. Now as far as I'm aware I can do one of two things:
Change the K2 CSS style sheet. BUT this means that every time I update k2 the style sheet gets overridden - far from ideal!
Add a new K2 specific style sheet in my template. BUT this means I'm effectively loading the K2 style sheet twice - once for the component and then once again for the templates k2 style sheet. Now normally this wouldn't be a major issue - but as the K2 style sheet is over 1000 lines long - this is going to start to have a performance impact - especially as k2 isn't the only style sheet I'm going to need to override!
Are there any alternative ways of overriding the style sheets? Because both of these ideas are far from perfect as I've stated!
It really doesn't matter where you put your custom css rules. You might be better off putting them in the Joomla! template's custom.css file.
But if your concern is about one extra css file, look at your page: you might have more than 10, depending on template and extensions: so dealing with the extra one won't make a difference; but the "right way" would require:
a) compacting all css into one (taking care of different relative paths)
b) minifying the result
This of course means editing all components and modules views that add css rules and links, a massive work.
I'm a bit new to Rails, so far so good. The assets pipeline/sprockets is pretty neat but I'm a bit confused. When generating scaffolding for my various controllers, individual css/SCSS files were put into app/assets/stylesheets. But for my project I'm using LESS not SCSS, so I replaced them with .css.less files.
The problem I'm running into is that if I add CSS to a controller (let's call it "home.css.less" for example), it gets included in every view, not just views belonging to the "home" controller. If I remove "*= require_tree ." from the application.css file, then the file's not included in any views.
How can I specify CSS code for a particular controller/view using the Rails assets pipeline?
application.css:
/*
*= require twitter/bootstrap
*= require_self
*= require "application_custom"
*/
home.css.less:
body {
background: asset-url("circles.png") no-repeat;
}
The above results in no background being applied, even to the home controller's views.
This is a fairly common request; many sites have home page specific CSS that they don't want applied over the whole site.
I will make a couple of comments about this before providing the solution, if I may.
The purpose of the pipeline to present one CSS (and one JS) file to clients. The digest is added to allow the addition of server headers that force remote clients to keep a copy of them in their local cache.
The single request and aggressive caching strategy are the default for Rails for performance reasons; each request slows down the page.
Unless the home page CSS is really extensive, I would recommend using the default behavior. If the desire to split this out comes from clashes in CSS selectors between home and other pages, I suggest changing the CSS structure to over come this.
There are at least two common solutions:
The first would be used if you want to manually a different file for each controller.
<%= stylesheet_link_tag "application", controller_name %>
For this to work in production you have to tell rails to precompile all the individual CSS files (in application.rb):
config.assets.precompile << '*.css'
The second is to add a helper to render CSS only when it is required from a view.
I recommend the top solution on this question. You will have to modify the helper names for CSS. That will render a tag for the required CSS only when it set in the view.
I have been working on a MVC3 new project where I wanted to introduce the concepts of dynamic themes.
Instead of creating a bunch of .css files and dynamically linking to the
right one, I wanted to use a <style> section in master <head> section
that specifies the values to use for the selectors and their properties.
The values would be pulled from a database and written to header section in style,
look like this:
<head>
<style type="text/css">
.testClass { color:Purple;background-color:LightGreen; }
</style>
</head>
Not an answer on how to achieve this end, per se, as much as a suggestion that you reconsider. I have seen this approach taken firsthand several times over the years, and it invariably ends up first with writing a proprietary tool to edit the database themes and subsequently with an expensive rewrite to extract all the themes out of the database and into proper css files.
One typical reason to go down the path of putting styles in the database tends to be a desire to allow a given style to be "overridden" on a case-by-case basis - for instance, in an application service provider model, where one customer wants to change only one or two of the default styles. However, the "cascading" in "cascading style sheets" allows this exact behavior, without abandoning all the goodness of proper css and the associated tools - as long as you sequence the stylesheets in the correct order in the page head (e.g. "maintheme.css" first, then "customerX.css"), you only need to redefine the styles of interest in the customer's stylesheet and they will automatically override those in the main theme's stylesheet (assuming the css selectors otherwise have the same precedence).
A related, but slightly different reason given for going with database-driven stylesheets is to allow end users or business owners to edit the styles themselves. With a few exceptions, that sort of feature turns out to be less used and more difficult to maintain in practice than it seems when drawing it up. In this case, the number of styles being customized is theoretically quite small - presumably entirely constrained - and you'd be writing a proprietary tool to allow them to be edited, regardless, so again I would suggest simply writing out the customized styles to a css file on a filesystem, rather than a database (or as a blob to a CDN, etc.).