ThemeStructureIdea2

more thoughts on future theme structure

Created by: xing, Last modification: 29 Apr 2006 (09:09 UTC)
this page is based on some of the ideas put forward in ThemeStructureIdea some time ago and trying to apply the ideas in userPageLaetzer.

basic folder setup

<theme>/templates/
<theme>/<style>/


the style folder could contain the following

<theme>/<style>/css/layout.css
<theme>/<style>/css/style.css
<theme>/<style>/images/


a structure like this would enable us to have themes such as (from laetzers page)
  • portal (3 columns)
  • classic (2 columns)
  • blog (1 main-column, vertical, compliant, accessible, post/comment-centric)
  • wiki (center+menu, edit-centric, loose hierarchy)
  • directory (center+menu, lot's of links, teaser/header-centric, deep hierarchy)
  • minimal/text (3 or 4 "horizontal columns", basic)
  • ad (horizontal, flashy, small, pictures, drop down menus, flat hierarchy,)

within a theme you can have as many styles as you like, making it possible to categorise your styles and allowing the user to figure out what they want.

should layout.css be "part of the theme"?
by this i mean, should layout.css be placed in the theme folder for every style to be included? is that just going to produce a ton of differently coloured clones?

please add any thoughts and ideas. this is just a draft...

Comments

layout vs blocks vs appearance

by , 03 Mar 2005 (18:17 UTC)
I may be confused, being new to this project, but it seems like page structure, layout, and appearance are being commingled. As I understand it, a CMS page has blocks laid out a certain way, each of which is a "window" on a module. For example, with the portal as described above, there are 3 columns, which typically have multiple blocks in the left and right ones and the "main" block in the center. Once a layout is chosen, the blocks for each area are chosen, which are linked to modules in some manner. This is all virtual in some sense, although there are certain layout requirements for each jmodule as well, and has nothing to do with the apperance

So, essentially you have layout (portal, classic, blog) > blocks ("windows" within the main areas) > appearance (what lists, text, links, etc. look like). IMO, these choices should be made separately and separate stylesheets/templates used at each level. (Only stylesheets for appearance.)

Thoughts? Opinions on how we remain backwards compatible if something of this sort is implemented/enforced?

Re: layout vs blocks vs appearance

by xing, 23 Mar 2005 (19:38 UTC)
you put my ideas quite nicely:

layout > blocks > style

the above is an attempt at trying to set up a structure in which this can be achieved.

since the layout and style are closely related (the blocks are chosen by the admin) i think it would be good to categorise them by placing them in a particular folder, which represents the layout the styles belong to.

i suppose the terminology above could be changed to
<layout>/templates
<layout>/<style>

bitweaver has it's own set of templates that come with every package. if a <layout> requires modified templates, it's possible to place these in the <layout>/templates folder, which will override the original templates (this system is particularly useful when it comes to upgrades and the like.

the <layout> specifies a set of templates that are generally usable by styles of this layout. it should then also be possible to override these in case a style needs further modifications, which could go in <layout>/<style>/templates.

backwards compatability will probably be lost or we'll have to think of something since the folder structure is different.

xing</style></layout></layout>

copy LaTeX

by laetzer, 30 May 2006 (12:44 UTC)
The "themes" idea reminds of LaTeX, its commands "documentstyle" / "pagestyle" etc.
  Page 1 of 1  1