Patterns Server and Client

IMPORTANT: the code and documentation related to these modules are still experimental and should not be used in production enviroment.

The new version of Patterns provides the changes to offer compatibility with the new Patterns Server and Patterns Client modules (to be released soon), whose aim is to act as a hub for sharing Patterns files among Drupal users.The key attributes we aimed for are simplicity and security.

Syntactic and semantic analysis

The problems of naming collision and resolving dependencies between different entities have been addressed by several techniques employed by compilers while transforming the source code written in a programming language into a binary form. In the case of Patterns it was necessary to address a similar problem due to its inner nature of transforming a file storing a set of configuration into a set of values interpretable by the CMS.
This is especially important while re-using patterns exported automatically as the ones described in the previous section, since the state of a website might not fullfill the requirements to make use of the configuration of a pattern exported by another website.

The new version of Patterns allows the components to implement two separated layers of syntactic and semantic validation, providing a very valuable feedback to the user that is going to run a pattern in case it is necessary to solve any possible conflicts.

Improvement of the export functions and components extension

The new version of Patterns provides a set of enhancements to export automatically the configuration of a site. All the main components possess now automatic export capabilities, and depending on the type of component new options to export it are offered.

Two different use cases are distinguised:

  1. Export the configuration as a pattern consisting of a set of CREATE actions which allows users the creation of patterns for “fresh installation” of certain feature,
  2. Export the configuration as a pattern consisting of a set of MODIFY actions which allows users the creation of patterns to override the current settings (e.g., to update the features developed in a testing site to a production site). The patterns generated ensure idempotency in the operations.

An analysis was performed in order to classify the required export configuration processes according to the semantic of the tag itself. For most of the components exporting the configuration as a set of CREATE or MODIFY actions makes sense semantically for both cases, but there are some exceptions, e.g., for the colour component only the MODIFY case makes sense, since it is always present in the system.

The table belows provides information about the supported export configuration processes for each tag.

Patterns 7.x-2.x vs Patterns 7.x-1.x

The architecture of Patterns has been extended in a new major release (7.x-2.x) and due to these big changes backwards compatibility with Patterns created with versions 7.x-1.x is not supported (some Patterns might be marked as non syntactically valid). Further details for the changes in the syntax and the status of the automatic extraction can be found in the Tour of the components section.

Syntactic and semantic validation

The new version of Patterns allows the components to implement two separated layers of syntactic and semantic validation, providing a very valuable feedback to the user that is going to run a pattern in case it is necessary to solve any possible conflicts.

Improvement of the export functions and components extension

Patterns 7.x-2.x includes a set of enhancements to export automatically the configuration of a site. All the main components possess now automatic export capabilities, and depending on the type of component new options to export it are offered.

Custom functions as action handlers

Exporting configuration

Important: This page is a tour of the code for the submodule patterns_export and the components. If you are looking for information on how to write a an export function for a component please read this section before.

Exporting patterns: Flow of Execution

In this section we will analyze the flow of execution provided by the submodule patterns_export, that allows us to extract Patterns files automatically. For this example we will be using the color component.

  • A new entry in the menu is set by hook_menu_alter(). The function called when accessing to the url is patterns_export(), which will check if there are any parsers available and call the function patterns_export_page1() after loading all the components.
  • The function patterns_export_page1() will take care of:
    • Invoke all the modules implementing patterns, and filter those which provide any export function.
    • Prepare the form with the granularity options to export for each of these components (i.e.: the taxonomy component allows to export terms and/or vocabularies).

Other functionalities: refresh, check, trash, remove, publish...

In this section we will describe the operations involved in some other functionalities not related to the execution.

Refresh all

  • The operation to refresh the patterns list is performed using AJAX. The js/patterns.js file contains a function that will ask the server for the service to be consumed at admin/patterns/refresh. In this case the function will be patterns_io_get_patterns_service() (in the file includes/io/io.inc):
    • It retrieves again the list of patterns calling patterns_io_get_patterns().
    • It will call the theme function with patterns_list() as a hook, so the theme_patterns_list() function will be called with the new values.

Check a pattern

  • When a pattern is checked, the function patterns_modules_page() is called using the PID as an argument.
  • This function (in the file theme/modules.inc) checks the current list of modules installed in the system and inform of the ones that should be enabled in order to run the pattern properly:

    Pages

    Subscribe with RSS Subscribe to RSS - patterns