Cyclone3 Skin

Supermodule

From Cyclone3 Wiki

(Redirected from File types:Supermodule)
  • Extension: *.smdl (see Naming conventions)
  • Location: _mdl directory
  • Mandatory: no
  • Caching: not cached

Supermodules are just the same as modules, with two main differences - a supermodule does not have any direct output (apart from logging, for example) and they can load other modules. However, they can't load other supermodules for logical reasons.

A typical example would be a supermodule, displaying an article, its related articles list, an article list from the same category, related files list and a related discussion. As of its nature, the modules itself are displaying only what they were written to. An article view module displays a specific article, an article list displays a list of articles, and so on.

But how does the related articles list module know, which articles are related to the currently displayed article? Or how does the same-category article list know, which category it should list? Here's where the supermodule feature comes handy.

#!/usr/bin/perl
# USE UTF-8 !!!
package Tomahawk::module;
use open ':utf8', ':std';
use encoding 'utf8';
use utf8;
use strict;

use App::401::_init;
...

sub execute
{
  my %env=@_;
  ...
  #check if we received an article ID and finish if we did not
  if (!$env{'ID_article'})
  {
    return 1;
  }
  ...
  #load the article view module
  Tomahawk::module(
    '-type' => "mdl",
    '-category' => "401",
    '-name' => "article_view",
    '-version' => "lite",
    '-global' => 1,
    '-TMP' =>	$env{'view_TMP'},
      'article.ID' => $env{'ID_article'}
   );
  ...
  #get the article's category ID and store it in $article{'ID_category'}
  ...
  if($article{'ID_category'})
  {
    Tomahawk::module(
    '-type' => "mdl",
    '-category' => "401",
    '-name' => "article_list",
    '-version' => "lite",
    '-global' => 1,
    '-TMP' => $env{'same_category_TMP'},
      'article.ID_category' => $article{'ID_category'},
    );
  }
  ...
  #get a list of related articles and store their ID's list in $relations
  ...
  if($relations)
  {
    Tomahawk::module(
    '-type' => "mdl",
    '-category' => "401",
    '-name' => "article_list",
    '-version' => "lite",
    '-global' => 1,
    '-TMP' => $env{'related_article_TMP'},
      'article.ID_entity' => $relations,
    );
  }
  ...
  #get a list of related files and store their ID's list in $relations_files
  ...
  if($relations_files)
  {
    Tomahawk::module(
    '-type' => "mdl",
    '-category' => "541",
    '-name' => "file_list",
    '-version' => "lite",
    '-global' => 1,
    '-TMP' => $env{'related_files_TMP'},
      'article.ID_entity' => $relations_files,
    );
  }
  ...
  #get related discussion ID and store it in $discussion{'ID'}
  ...
  if($discussion{'ID'})
  {
    Tomahawk::module(
      '-type' => "mdl",
      '-category' => "821",
      '-name' => "discussion_message_list",
      '-version' => "lite",
      '-global' => 1,
      '-TMP' => $env{'discussion_TMP'},
        'discussion.ID' => $discussion{'ID'},
    );
  }
  return 1;
}

As you can see, you can execute code and conditionally load or ignore modules according to available data, or develop your own logic of displaying/setting up modules according to your needs or calculations or ... the possibilities are almost endless. Of course, you can configure the loaded modules using the same parameters as you would use in type files.