Layered architecture for Ding2 [proposal]
-
Upload
jesper-woldiche -
Category
Technology
-
view
848 -
download
1
description
Transcript of Layered architecture for Ding2 [proposal]
Brand layer(subtheme)
København Aarhus Randers Kolding Vejle
Theme layer (basetheme)
Structure layer (panels layouts)
Content layer(panels settings)
ding.TING 2(custom modules, con�g)
Drupal(core + contrib)
ding.TING hovedspor
ding.TING Aarhus-fork
ding.TING Randers-fork
ding.TING Kolding-fork
Current situation Monilith architecture demands that any deviation in content or logic results in a fork of the complete ding.TING code repository.
As a result a libraries except Copenhagen has forked the ding.TING code requirering high maintenance and high(er) barrier to sharing patches and features.
Thick, complete basetheme never designer for subtheming requires every instance to override and maintain a complete theme, resulting in high maintenance costs.
Brand layer(subtheme)
København Aarhus Randers Kolding Vejle
Theme layer (basetheme)
Structure layer (panels layouts)
Content layer(panels settings)
ding.TING 2(custom modules, con�g)
Drupal(core + contrib)
Example: Drupal Drupal Core and Contrib modules. De�nes core concepts as entities, �elds, RDFa integrations, views, page manager, editorial tools and so forth.
Brand layer(subtheme)
København Aarhus Randers Kolding Vejle
Theme layer (basetheme)
Structure layer (panels layouts)
Content layer(panels settings)
ding.TING 2(custom modules, con�g)
Drupal(core + contrib)
Example: ding.TING2 De�nes speci�c con�gurations, settings and custom developed modules including all integration to search.
Brand layer(subtheme)
København Aarhus Randers Kolding Vejle
Theme layer (basetheme)
Structure layer (panels layouts)
Content layer(panels settings)
ding.TING 2(custom modules, con�g)
Drupal(core + contrib)
Example: Content The content layers contains ding.TING2’s panels settings, and de�nes logic and content. What content get printet, when and in what region, in what order to the other content.
Example: Should the site print a ‘Share to Facebook’ button, on what content and in what region.
Brand layer(subtheme)
København Aarhus Randers Kolding Vejle
Theme layer (basetheme)
Structure layer (panels layouts)
Content layer(panels settings)
ding.TING 2(custom modules, con�g)
Drupal(core + contrib)
Example: Structure The structure layer contains ding.TING2’s panels layout templates. They de�ne the structure and wrapping markup for the separate panels panes.
Example: Where is the panels pane containing the ‘Share to Facebook’ button printet in the markup.
Brand layer(subtheme)
København Aarhus Randers Kolding Vejle
Theme layer (basetheme)
Structure layer (panels layouts)
Content layer(panels settings)
ding.TING 2(custom modules, con�g)
Drupal(core + contrib)
Example: Theme Theme layer de�nes elements such as general typography, spacing/layout, general branding neutral styling and styling/ui/ixD for shared features such as search, news, ting objects and
collections and so forth.
Brand layer(subtheme)
København Aarhus Randers Kolding Vejle
Theme layer (basetheme)
Structure layer (panels layouts)
Content layer(panels settings)
ding.TING 2(custom modules, con�g)
Drupal(core + contrib)
Example: Branding Branding layer de�nes elements such as logos, branding colour schemes, local adaptions to menus and other idiosyncrasies.
Brand layer(subtheme)
København Aarhus Randers Kolding Vejle
Theme layer (basetheme)
Structure layer (panels layouts)
Content layer(panels settings)
ding.TING 2(custom modules, con�g)
Drupal(core + contrib)
The ideal Every layer except a thin branding layer containing local logos, colours and idiosyncra-sies are shared unforked among all partner libraries.
In reality this is hardly attainable though. Differences between multi-branch and single-branch partners will in probability result in fragmentation of codebase.
Brand layer(subtheme)
København Aarhus Randers Kolding Vejle
Theme layer (basetheme)
Structure layer (panels layouts)
Content layer(panels settings)
ding.TING 2(custom modules, con�g)
Drupal(core + contrib)
Realistic model Maintaining two separate content and structure layers - one for multibranch libraries and one for (mainly) single branch libraries - should protect against further, unplanned fragmentation and
make long term collaboration and code sharing possible.
Brand layer(subtheme)
København Aarhus Randers Kolding Vejle
Theme layer (basetheme)
Structure layer (panels layouts)
Content layer(panels settings)
ding.TING 2(custom modules, con�g)
Drupal(core + contrib)
Possible model A multilayer model still includes the freedom for individual partners to fork a speci�c layer and still use the rest of the stack unchanged.
In this example one partner has created it’s own base theme and another partner has created it’s own panels layouts, while still building on shared components in other layers.