Cyclone3 Skin

Add a new module to servicetype

From Cyclone3 Wiki

Here is a sample definition of a correctly specified module definition in a certain type. Of course, it doesn't definitely have to formatted like this, but it's pretty nice if it is, with the various parameter combos joined to visually see-able groups for fast orientation.

Also, it's wise to keep the order of them, because placing a -TMP at the end of the module specification might (after a few hours of looking at module templates and type files, easily a reality, believe me) cause a few minutes of precious time to be lost, because someone after you will spend them looking for why the module won't work, although he DID specify the -TMP at the beginning. Well, it get's overridden by the second one on the bottom, as they get loaded linearly...

...
<MODULE>
  <VAR id="-type" value="mdl" />
  <VAR id="-global" value="1" />
  <VAR id="-category" value="401" />
  <VAR id="-name" value="article_list" />
  <VAR id="-version" value="lite" />
    
    <VAR id="-TMP" value="ARTICLE-LIST" />
    
    <VAR id="-xsgn" value="section" />
    <VAR id="-xsgn_global" value="2" />	
    
    <VAR id="-xlng_load" value="1" />
    <VAR id="-xlng_global" value="2" />	
    
    <VAR id="sql_limit" value="2,10" />
    
    <VAR id="article_attrs.ID_category" value="24*" />
</MODULE>
...

And now for the specific rows:

...
<MODULE>
...
</MODULE>
...

This is a definite must :) Of course. Without this, your module won't even be fetched from the type file.

  <VAR id="-type" value="mdl" />

Obligatory. This specifies the module type. It can be either a supermodule (smdl), module (mdl), designmodule (dmdl), or, for cron-specific modules, also cron module (cron).

  <VAR id="-global" value="1" />

As you should already know, the Cyclone3 Framework works on a multi-level globalization architecture. Most of the functional modules are globalized, so that they don't have to be duplicated locally for every single service. This level is global marked as 1. If you are using a localized, or service-specific module, it should be put into local _mdl directory. For this, you'd use local - value of 0. This is the default value, so you may not specify it at all to make it work. The last one is called master - valued 2 (for historic reasons, don't ask why it's not between 0 and 1 :) ). These modules are localized in the master _mdl directory - f.e. if you have a service like www.myportal.com, and two subportals called users.myportal.com and admin.myportal.com, the directory structure would be - !myportal.com/, !myportal.com/!users/ and !myportal.com/!admin/. To avoid duplication once again, you can place a site-specific module to the master domain directory, and every subdomain may use it, without needing it to be local. But, if you have a specific authorization module for the administration site, you want to place it into !myportal.com/!admin/_mdl, because it will be used only on this service, thus won't be available for the master domain or other subdomains.

  <VAR id="-category" value="401" />

Obligatory. Addon definition. If you want to see the available/possible ones, have a look at http://www.cyclone3.org.

  <VAR id="-name" value="article_list" />

Obligatory. Module name. It's nice and wise to name the modules in a way, that anyone who wants to use it, understands what the module should do without looking at the code itself - as above - this module works with a401 addon (articles), articles data, and lists them. For displaying a single full article, you'd use article_view.

    <VAR id="-xsgn" value="section" />

Module template specification. If not specified default is used.

    <VAR id="-xsgn_global" value="2" />	

Same as -global parameter, however, this specifies the globality level for the module template.

    <VAR id="-xlng_load" value="1" />

Load internalization file. (xt_xlng is used in the older application modules instead)

    <VAR id="-xlng_global" value="2" />	

Same as -global parameter, this specifies the globality level for the internalization file.

    <VAR id="sql_limit" value="2,10" />

Standardized way of direct SQL values or attributes to be used/processed by the module.

    <VAR id="article_attrs.ID_category" value="24*" />

Any other, module-specific values. See specific module documentation for the available attributes and their possible values. Here is a example