Ding2tal - structural choices

Submitted by ewan on 26 September, 2012 - 10:18

Even when following Coding Guidelines, a lot of questions remain when coding for Ding2. This document is intended to capture the choices made during the development of ding2 code, and to highlight areas that need to reach a consensus.

Coding and theming issues

The notes below are organized according to structures in drupal in order to facilitate easy lookup during development.

Configuration

  • date formats. All custom date formats for ding are placed in ding_frontend (code manually added to the Feature). (link to example).
  • image styles. Configured and put in code with Features. All custom image styles for ding are put in ding_frontend (link to example).

Features

Fields

  • No fields are shared between ding modules. Reason: This will reduce the potential size of field tables, in turn reducing the need to apply additional indexes on database tables.
  • Fields are put in logical groups to facilitate better edit forms.

Panels

  • Markup: HTML5 semantic elements (section, article etc.) is used in Panel layouts. See also HTML & CSS > HTML Markup, below.

Structure

  • View modes on node types: What view modes do we have? And how template files (.tpl files) will be relating to them?

Theming

  • date formats: see configuration, above.
  • templates.php
  • .tpl files

Views

  • date formats: see configuration, above.
  • markup: Modified in the view itself wherever possible. Complicated markup with conditions is placed in template files (link to example). If business logic is needed to produce the markup, code placed in the template.php file which defines variables to use in template files (link to example). See also HTML & CSS > HTML Markup, below.

HTML & CSS

The tdcss tool is used to test markup and styling. It is meant to be the authoritative reference. New markup is placed in tdcss and tested here. View the most current state of tdcss at http://ding2tal.ting.dk/latto

HTML Markup

  • HTML5 semantic elements (section, article etc.) is used in Panel layouts. They are NOT used at any lower level  such as in node templates (node.tpl.php). Here, normal DIV tags with classes are used instead.

CSS rules

  • HTML elements are not referenced i CSS rules. Reason: the element can appear correct even when the HTML-tag is swapped out for another. Example: a list item is created with a LI element in some places and with a DIV in others - both have a class of "list-item".
  • There is no optimizing for IE7 when testing the CSS cross-browser. If the site is at least functional in IE7, it is good enough.
Grupper:

Kommentarer

martinb146 years ago

template.php

Complicated markup with conditions is placed in template files (link to example). If business logic is needed to produce the markup, code placed in the template.php file which defines variables to use in template files (link to example). See also HTML & CSS > HTML Markup, below.

I suppose views introduced by modules should keep business login in module_preprocess functions, not in template.php.

ewan6 years ago

Indeed modules should keep

Indeed modules should keep their own business logic in their module_preprocess - as long as it is business logic that produces output that should stay the same across any and all themes. If the business logic in question only has meaning inside the theme, it might still be valid to place it in the template.php of the theme.