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.).
Related
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.
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.
Thymeleaf puts a large emphasis on "natural templating", which means that all templates are already valid XHTML files. I always thought that is a great step forward that I can generate fragments in my templates e.g. in JSP I'd write
<tagfile:layout title="MyPageTitle">
<jsp:body>
Main content goes here
</jsp:body>
</tagfile:layout>
My "Layout"-Tagfile contains all the header-tags (title, link to stylesheets,...), the menu and justs inserts title text and body at the right point. I don't need to know anything about stylesheets menus or the like when designing my html fragement.
This is in contrast to the idea of Thymeleaf which encourages me to create full html pages (including a sample menu and all the headers). While the manual of Thymeleaf continues to emphasise how great this is, it never deals with duplication of code concerns:
I have one template that generates a menu and all my other templates (could be many) include a copy&pasted dummy menu just so that I can view the template in a browser without the server side generation mechanism. If I have 100 templates that means that prossibly the exact same dummy menu exists 100x (in each and every template). If I change the look of the menu it's not done with creating a new dummy menu, but I need to copy&paste the new dummy menu into 100 templates.
Even if I decide to do something as simple as renaming my CSS file I need to touch all my templates as well.
There is always the danger that my template looks just fine in my browser, but the generated output is broken because... well... I broke it (could be as simple as a misspelled variable name). Thus I will need to test the output with the actual generation anyway.
Did I misunderstand something there? Or is this indeed a trade-off? How do you minimize the impact of code duplication?
Natural Templates are just an option in Thymeleaf. As you can read here http://www.thymeleaf.org/layouts.html there are many options, including a hierarchical layout approach like the one you seem to prefer (I recommend you to have a look at the Layout Dialect).
However, Natural Templates are the preferred and most explained layout option because Thymeleaf was thought from the ground up to allow you to do static prototyping (in contrast to most other template engines). But it doesn't force you to.
So.. how are Natural Templates applied in the real world to avoid code duplication becoming an issue? That depends on the scenario, but one pattern we see repeated a lot is people creating full document, natural templates for 3-4 or maybe even a dozen of their application's templates, only those that are more likely to take a part in the design process --exchanged with designers, with customers...--, and simply not apply that header and footer duplication in the rest of the application's templates, making their creation and maintenance much simpler.
That way you can have the best of both worlds: a means to exchange fully displayable pages between programmers, designers and customers for the pages that this is really relevant; and also a reduced amount of duplicated code.
What's more, thanks to libraries like Thymol (referenced in the article linked above) you can even avoid code duplication completely, allowing your fragments to be dynamically inserted via JavaScript when you open your templates directly in your browser without running the application.
Hope this helps.
Disclaimer, per StackOverflow rules: I'm thymeleaf's author.
I have to convert a static site for a client and it has to retain the exisiting layout.
Fortunately, most of the pages don't have to be editable, so for those I was going to use more or less the existing html.
The challenge I am having is that for many of the pages that do need to be editable, the content is laid out in columns (2, 3 and sometimes mixed)
This ( http://globalstrategies.org/index.php/give/hope-partners ) is an example of a page like that, and you can see others on the site where the layout is relatively complex.
I had thought of creating a jce stylesheet that would at least layout the page in the editor in a reasonable way (a bit like a responsive site, by having the columns stacked one after the other) , but I am concerned that my client may accidentally delete the surrounding classes/divs that create the more detailed structure.
I'm pretty familiar with Joomla and have built quite a few sites, but I've not used an cck tools and was hoping not to have to do that in this case, though maybe now is the time to learn.
Any advice / recommendations would be welcome !
Richard
Maybe ContentBuilder could do in your case, it's fairly easy and creates super-simple code, I've accomplished similar tasks with it. You provide the user with 3 fields (one per column) and create a layout for its display.
Another alternative is possibly even easier: you could override the use of the page functions in a template override of com_content/article, instruct the user to insert at most 2 page breaks, and use the page breaks to build the layout as you require.
If your sites is upgraded to the Joomla 3 you can use the build-in Bootsrap to do the layout.
You can find some more information how you can achieve this in the following page:
http://twitter.github.io/bootstrap/scaffolding.html#gridSystem
I'm in the process of selecting an HTML5 template for my web projects. I've been using HTML5 Initiliazr which uses Boilerplate for the last few months but decide to reevaluate the two templates, since I don't like the issues with HTML5 Boilerplate's CSS not being valid against W3 CSS validator (CSS3).
Now my question is, given the fact that both CSS resets also take into account vendor quirknesses, will those resets ever be completely valid or is it impossible to assume such a thing?
I did noticed that HTML5 Reset actually has a few issues less than Boilerplate but that might change in the future. However, I did read Boilerplate's explanation on why each and every style was introduced and what problems it solves, so it kinda makes sense.
So what do you think?
Boilerplate's css uses few hacks like * (*font-size:small;) and some browser specific css rules - if you are really concerned about validation just move the hacky rules out of the main style.css and load them for the browser that needs them only.
You can be either hacky and crossbrowser or valid and degraded. And don't forget that boilerplate also states:
Think there's too much? The HTML5
Boilerplate is delete-key friendly. :)
But if you ask me - its waste of time trying to pass the css validation and still be crossbrowser compatible - if your client demands it and has extra money to pay for the css valid badge (which probably won't generate them any extra income) than go for it, if you personaly are obsessed by having to pass it go for it - otherwise it's nonsense and waste of your time. If you wrote all of the valid css3 rules correctly and used a few vendor specific rules it won't really kill anyone.
Overall Boilerplate is a solid template and perfectly ok to use for every day projects and the problems you are exposing are more of a perfectionist's view on the thing. This would be my 2 cents on this.