Step #1 : Runner engine: Organize by Sections

  Why? Visualization of Concerns

Separation of Concerns (SoC) is a powerful concept achieved through modularity and encapsulation, in this case we'll try to minimize dependencies between template pieces of code (concerns).

I think one of the better characteristic of MindTouch is their visual integration, this is, how we can do things visually, but without lost the power of integration with both low level and external capabilities. Then we need to do templates more visually integrated ;)

My intention is to separate Model, View and Controller parts of any Template, to gain:

• Simplicity: more easy to understand
• Mantainability:  more easy to modify and reuse

  How? By example

I've decided to use Carles Coll's InteractiveComments() template, because this is a very complete and useful one. I think that "by example" technique is the more easy to show and explain our implementation steps. I would like to thank Carles for sharing it with us ;)

  Sectioning : Organize

 Organize code in sections 

The problem: When we review the code of a template that we have not in our mind, we don't know where are located the different known parts of any template implementation, like parameters, variables, scripts, events, html, css, etc., and then we lost a lot of time identifying them.

The solution: I've separated template into sections by concerns and utility purposes, as following:

• Parameters
  • Includes
  • Constants & Variables
    • Content : Dynamic Html
    • Content : Static Html
    • Events : Message Manager
    • Events : Global Bindings

I need to comment that i've tried to put this sections in the same level of hierarchy but dekiscript isn't capable to catch variables defined in the same or upper level of the tree (a problem with variable scope between sections).

  Sectioning : Separate & Visualize

 Separate presentation code & Visualize into user interface 

The problem: When we design presentation of any template, we can use wiki's user interface to do it, but many times we need to build it dynamically because of different causes such as:

• Parametrization: when we use expressions or variables to assign values
• Customization: when we need customization of source code (Html, Css)
• Conditionality: when we use different conditions to build it

The first two causes are usually easy to solve, then we can isolate this visualization code from the dekiscript code, and we can understand and maintain (view & edit) it more easy using wiki's user interface.

The solution: We need to isolate the presentation code (like style sheets) to extract it from the dekiscript code and put it into a new section (separation of presentation and content). Then we need to add a dekiscript code to read this presentation code and apply some operations, to update templating variables with their variable instantiations and to make some other transformations.

We organize this presentation code sections in a new section called "View", located in the bottom of the template (after events), and this way we can see and identify all the presentation parts together. In our example we have defined the following sections:

• Views
  • View : Comment
  • View : Button Bars
  • View : Sending Message Form
  • View : Reply & Edit Message Form
  • Style : CSS Definition

The first time (when we are copy/pasting the code), we need to put this Html and Css presentation codes using the source code editor, but the next times we can also edit it in normal mode (using the wiki's user interface).

  Sectioning : Logging

 Add logging capabilities 

The problem: When we run and debug any template, we have some problems separating real template output from our debugging log messages, then we need to do something to distinguish them.

The solution: We can define a special code to be processed by controller template, and then displayed in the bottom of the page, all the logging messages together in a new section called "Logging", separated from all the other presentation output.

In the controller template, is possible to parametrize the logging modes with the following options:

• Log template parameters:  0 (off) / 1 (on)
• Template logging: 0 (off) / 1 (on)
• Controller logging: 0 (off) / 1 (on)

Resources

Releases

Engine : Runner

{ 
    "#1": "CoDoer-Runner-1", 
    "#2": "CoDoer-Runner-2", 
    "#3": "CoDoer-Runner-3", 
    "#3b": "CoDoer-Runner-3b", 
    "#4": "CoDoer-Runner-4:437"
}

Engine : Tester

{ 
    "#1": "CoDoer-Tester-1", 
    "#2": "CoDoer-Tester-1", 
    "#3": "CoDoer-Tester-1", 
    "#3b": "CoDoer-Tester-1", 
    "#4": "CoDoer-Tester-1"
}

Widgets

{ 
    "Calculator-CoDoer-4": ":20", 
    "GigyaSocialize-CoDoer-4": ":98", 
    "InteractiveComments-CoDoer-4": ":0", 
    "LinkedHitz-Local-Pref-4": ":32", 
    "LinkedHitz-Local-Prop-4": ":196", 
    "SceneFlow-CoDoer-4": ":92", 
    "TodoList-CoDoer-4": ":13"
}

Resources

Releases

Engine : Runner

{ 
    "#1": "CoDoer-Runner-1", 
    "#2": "CoDoer-Runner-2", 
    "#3": "CoDoer-Runner-3", 
    "#3b": "CoDoer-Runner-3b", 
    "#4": "CoDoer-Runner-4:437"
}

Engine : Tester

{ 
    "#1": "CoDoer-Tester-1", 
    "#2": "CoDoer-Tester-1", 
    "#3": "CoDoer-Tester-1", 
    "#3b": "CoDoer-Tester-1", 
    "#4": "CoDoer-Tester-1"
}

Widgets

{ 
    "Calculator-CoDoer-4": ":20", 
    "GigyaSocialize-CoDoer-4": ":98", 
    "InteractiveComments-CoDoer-4": ":0", 
    "LinkedHitz-Local-Pref-4": ":32", 
    "LinkedHitz-Local-Prop-4": ":196", 
    "SceneFlow-CoDoer-4": ":92", 
    "TodoList-CoDoer-4": ":13"
}