Site:Frontend:Modules
MetrixJustin (Talk | contribs) (→Common) |
MetrixJustin (Talk | contribs) (→Listing Content) |
||
(6 intermediate revisions by one user not shown) | |||
Line 1: | Line 1: | ||
− | + | = Introduction = | |
Modules contain stand-alone code, files, pages, and page includes required to perform the tasks of the module. | Modules contain stand-alone code, files, pages, and page includes required to perform the tasks of the module. | ||
− | + | = Module Integration = | |
− | + | == Adding a Module to a Page == | |
After a module is created or imported, it will be listed under Module Integration while editing a site page. | After a module is created or imported, it will be listed under Module Integration while editing a site page. | ||
Line 19: | Line 19: | ||
</html> | </html> | ||
− | + | == Accessing Module Pages == | |
Since modules are injected into a parent page, pages within a module need to be called with the '''mpage''' URL parameter. | Since modules are injected into a parent page, pages within a module need to be called with the '''mpage''' URL parameter. | ||
Line 27: | Line 27: | ||
http://example.com/?page=auth&mpage=login | http://example.com/?page=auth&mpage=login | ||
− | + | == Module Only == | |
Some modules contain pages that serve up JSON or XML content and should ignore the included header and footer. This can be done by adding the URL parameter "output=moduleonly" | Some modules contain pages that serve up JSON or XML content and should ignore the included header and footer. This can be done by adding the URL parameter "output=moduleonly" | ||
Line 34: | Line 34: | ||
http://example.com/?page=auth&mpage=users.json&output=moduleonly | http://example.com/?page=auth&mpage=users.json&output=moduleonly | ||
− | + | = Creating a Module = | |
− | = Common = | + | == Common == |
− | + | === Default Page === | |
This is the default page that loads when no mpage is set. | This is the default page that loads when no mpage is set. | ||
− | + | === Autoload === | |
Autoloaded modules will be included on every page of the site. This is helpful for caching and including JS and CSS files throughout the site. | Autoloaded modules will be included on every page of the site. This is helpful for caching and including JS and CSS files throughout the site. | ||
− | + | === Key / Value Pairs === | |
Key / Value pairs are module-wide variables that can easily be changed. These are often used as settings for the module. | Key / Value pairs are module-wide variables that can easily be changed. These are often used as settings for the module. | ||
Line 56: | Line 56: | ||
<?cs /if ?> | <?cs /if ?> | ||
− | + | === Initialization === | |
Initialization is the first part of the module that is loaded. If there are any required modules to be loaded before this module you will need to include them here. | Initialization is the first part of the module that is loaded. If there are any required modules to be loaded before this module you will need to include them here. | ||
If you're using the stack module, all CSS/JS stack includes would be called here | If you're using the stack module, all CSS/JS stack includes would be called here | ||
+ | |||
+ | == Javascript Controller == | ||
+ | |||
+ | Each module that requires javascript should have its own controller. The controller is made up of classes that control different parts of the module. This allows us to only enable functions and listeners that are required on the page, instead of having them always active. This also ensures that when concatenating the javascript file that function and listeners wont overlap. | ||
+ | |||
+ | == Listing Content == | ||
+ | |||
+ | Listing content relies on the context of module page, not the parent page. For example if the parent page has a context of "My Videos" but the module page doesn't have a context nothing will be listed on the page. | ||
+ | |||
+ | The HDF keys/values will still remain the same, so they can be accessed the same way as a regular page. | ||
+ | |||
+ | Example: Listing the titles of the context Content: All | ||
+ | |||
+ | <?cs each:item = MS.content.items ?> | ||
+ | <?cs var:item.title ?><nowiki><br /></nowiki> | ||
+ | <?cs /each ?> |
Latest revision as of 10:42, 18 June 2012
Contents |
[edit] Introduction
Modules contain stand-alone code, files, pages, and page includes required to perform the tasks of the module.
[edit] Module Integration
[edit] Adding a Module to a Page
After a module is created or imported, it will be listed under Module Integration while editing a site page.
Selecting the module will populate MS.module.data with the contents of the module. Calling MS.module.data on the page will inject the contents onto the page.
<html> <head> <title>Module Test</title> </head> <body> <?cs var:MS.module.data ?> </body> </html>
[edit] Accessing Module Pages
Since modules are injected into a parent page, pages within a module need to be called with the mpage URL parameter.
For example, if your parent page is "auth" and your module page is "login":
http://example.com/?page=auth&mpage=login
[edit] Module Only
Some modules contain pages that serve up JSON or XML content and should ignore the included header and footer. This can be done by adding the URL parameter "output=moduleonly"
Example:
http://example.com/?page=auth&mpage=users.json&output=moduleonly
[edit] Creating a Module
[edit] Common
[edit] Default Page
This is the default page that loads when no mpage is set.
[edit] Autoload
Autoloaded modules will be included on every page of the site. This is helpful for caching and including JS and CSS files throughout the site.
[edit] Key / Value Pairs
Key / Value pairs are module-wide variables that can easily be changed. These are often used as settings for the module.
For example, if we have a setting called "show_stats" and want to see if its set to "yes"
<?cs if:'<!show_stats!>' == 'yes' ?> Showing Stats <?cs /if ?>
[edit] Initialization
Initialization is the first part of the module that is loaded. If there are any required modules to be loaded before this module you will need to include them here.
If you're using the stack module, all CSS/JS stack includes would be called here
[edit] Javascript Controller
Each module that requires javascript should have its own controller. The controller is made up of classes that control different parts of the module. This allows us to only enable functions and listeners that are required on the page, instead of having them always active. This also ensures that when concatenating the javascript file that function and listeners wont overlap.
[edit] Listing Content
Listing content relies on the context of module page, not the parent page. For example if the parent page has a context of "My Videos" but the module page doesn't have a context nothing will be listed on the page.
The HDF keys/values will still remain the same, so they can be accessed the same way as a regular page.
Example: Listing the titles of the context Content: All
<?cs each:item = MS.content.items ?> <?cs var:item.title ?><br /> <?cs /each ?>