Templates

Main Layout

The Main Layout from Tiki 12 onwards is defined in
/templates/layouts/layoutname/layout_view.tpl
Formerly it was defined in /templates/tiki.tpl.

templates/layouts/classic/layout_view.tplortemplates/layouts/bootstrap/layout_view.tplortemplates/layouts/whatsoevercustomlayout/layout_view.tpl

For the floating column design (left (#col2) and right (#col3) module zones), we need still the file /styles/lite/lite.css.

When you look at http://bootstrapped.fabricius.me/HomePage you will see a right column. The right column is actually the standart #col3, which is defined in layout_view.tpl
The divs #col2 and #col3 are "existing" in all viewmodes, but lateron, using @media queries, we will define in /styles/lite/lite.css that those two divs will float leaft and right around the middle content when the website is viewn in a wide viewport with a wide screen or in desktop mode, whilst in mobile mode or in a narrow viewport, the same #col2 and #col3 will smoothly jump above or under the content to provide a single column mobile design.

To make #col2 and #col3 responsive, meaning giving them defined relative width, you have to change the following in layout_view.tpl by adding a responsive column class (from twitter bootstrap.css) to aswell the #col2 as the #col3:

line 108:<div id="col2"{if $prefs. ...to<div class="col-sm-2 " id="col2"{if $prefs. ...andline 116:<div class="clearfix" id="col3"{if $prefs. ...to<div class="col-sm-2 clearfix" id="col3"{if $prefs. ...

The class "col-sm-2" refers literally to a 2 out of of a 12 grid definition out of the bootstrap.css definitions. It defines the relative width. "sm" stands for "small" and you have classes for "large" ("lg") and more aswell. So pls check the bootstrap.css for the different column classes. The width of the main content (#col1) will be defined as 100% (nothing to change in layout_view.tpl The content columns are made with divs which have column classes which make a sum of 12 Mind, that the actual width of the columns will be defined lateron in the .css files.

example:{DIV(float=left class=col-sm-3)}{DIV}{DIV(float=left class=col-sm-3)}{DIV}{DIV(float=left class="col-sm-6 clearfix")}{DIV}or{DIV(float=left class=col-sm-2)}{DIV}{DIV(float=left class=col-sm-4)}{DIV}{DIV(float=left class=col-sm-2)}{DIV}{DIV(float=left class="col-sm-4 clearfix")}{DIV}

This is just a rough example ... we must recheck and
a) find out and define best practice of usage, respectively the best appropriate default classes
b) maybe we have to code a few wikiplugins for the elements and maybe for inline editing Mind: With three columns we could have more than 12 grid - 12 for the content and arbitrary for the left/right columns, dfined in layout_view.tpl

Specific Layout - Elements, Features, Sections

As said above, we will have to do a good bit of work, to figure out the Id numbers and classes of the Bootstrap css selectors and to replace the original Tiki selectors with the new bootstrap ones. For all existing selectors that will be replaced, we need a table or an array (maybe similar to our language.php), to be able to convert existing old style themes (and maybe making some of them more or less responsive).

Main issues in respect of templates by 2013-Oct-31:

• All sorts of tables
  which you find in the admin area, in trackers, etc.

• Icons
  
  a) we do not yet have a system implemented to simply create and optionally replace cmplete "icon sets"
  
  b) we want to integrate Font-Awesome, as our lovely old-style Tiki Icons do not match to the modern flat Bootstrap design at all.
• Tabs
  
  in many dialogues we have tabs and similar elements, which are simply dissappeared, when switching to bootstrap ... we need to review and build in appropriate classes and maybe we need some extra Tiki specific classes for certain admin elements in a way, that we can "descend" them from bootstrap styles.
• Forms, Dropdowns, Progress Bars
  
  are mainly designed with jQuery related styles and must be put into the visual system of Bootstrap. This is not directly a templates issue, but must be considered in the same way.
• WikiPlugins and Modules
  
  they must fit into the design scheme aswell and thus be reviewed one by one.
• ...

• Features
  Even wikipages are kind of a minor problem, as they appear similar to a canvas, if no Tiki specific style is applied, they must be reviewed, where tikispecific selectors have to be replaced with bootstrappy selectors and where it makes sense to keep the (then additional) tikispecific selectors.
  More obvious is the need for review with features like Articles and Blog, or Forum or the myTiki personal preferences dialogues - alll that is more or less based on tables and build with absolute measurements.
  Features like Spreadsheet might be an issue to discuss, cause they are not fully styled by Tikis style system, as they are built with common jQuery plugins, respectively are based on external jQuery tools.

To be continued ...

BS tpl