Help:Class: Difference between revisions

Help:Class (view source)

Revision as of 23:38, 24 October 2024

39 bytes added , 24 October 2024

→‎This template can be included multiple times on the page: more sections

CargoAdmin, Bureaucrats, Moderators (CommentStreams), fileuploaders, Interface administrators, newuser, Push subscription managers, Suppressors, Administrators

14,662

edits

@@ Line 104: / Line 104: @@
 ==== This template can be included multiple times on the page ====
 This feature  leverages MediaWiki's templating system to iteratively display data stored via Cargo, enhancing the dynamic and flexible presentation of information stored in a structured manner within the wiki.
-* Data Repetition: Cargo allows for storing structured data in MediaWiki pages. When you create templates to display this data, you might want to use the same template structure to show different sets of data. For example, if you have a template for displaying book information, you might want to use that template multiple times on one page to list several books.
-* No Conflict in Data Display: Each instance of the template should be able to pull and display different data sets without the instances interfering with each other. This means:
-** Unique Identifiers: If the template generates or uses any HTML IDs or JavaScript variables, they need to be unique for each instance to avoid conflicts in the DOM or in scripts.
-** Data Parameters: The template should be designed to accept parameters or use Cargo queries that can specify which piece of data (or which set of data) it should display each time it's called.
-* Dynamic Content Handling: Since Cargo often involves querying data from wiki pages or databases:
-** Each template call might query different data. If the template uses #cargo_query, each instance can define different parameters for what data to fetch, allowing for different content in each template instance.
-** Scope of Variables: Variables used within the template for storing or manipulating data should not leak or overwrite each other between different template instances.
-* Efficiency: Even though templates can be included multiple times, there should be considerations for:
-** Page Load Time: Multiple queries or complex template processing might slow down page loading if not optimized.
-** Cargo Query Optimization: Efficient use of Cargo's ability to limit, join, or filter data to reduce unnecessary database hits or compute overhead with each inclusion.
-* Modular Design: Such templates are usually designed to be modular and reusable, meaning they:
-** Are built with the idea that their content will change with each use, based on the parameters passed or the data queried.
-** Maintain Consistency: While they can show different data, the format and style remain consistent, which is useful for maintaining a uniform look across different content on the same page.
-* In practice, this capability allows wiki editors to:
-** Create lists or galleries where each item follows the same format but displays different data (e.g., a list of events, publications, personnel bios, etc.).
-** Implement dynamic content sections where each section might focus on different aspects of similar data, like different product features or specifications, all on the same wiki page.
+In practice, this capability allows wiki editors to:
+* Create lists or galleries where each item follows the same format but displays different data (e.g., a list of events, publications, personnel bios, etc.).
+* Implement dynamic content sections where each section might focus on different aspects of similar data, like different product features or specifications, all on the same wiki page
+===== Data repetition =====
+Cargo allows for storing structured data in MediaWiki pages. When you create templates to display this data, you might want to use the same template structure to show different sets of data. For example, if you have a template for displaying book information, you might want to use that template multiple times on one page to list several books.
+===== No conflict in data display =====
+Each instance of the template should be able to pull and display different data sets without the instances interfering with each other. This means:
+* Unique Identifiers: If the template generates or uses any HTML IDs or JavaScript variables, they need to be unique for each instance to avoid conflicts in the DOM or in scripts.
+* Data Parameters: The template should be designed to accept parameters or use Cargo queries that can specify which piece of data (or which set of data) it should display each time it's called.
+===== Dynamic content handling =====
+Since Cargo often involves querying data from wiki pages or databases:
+* Each template call might query different data. If the template uses #cargo_query, each instance can define different parameters for what data to fetch, allowing for different content in each template instance.
+* Scope of Variables: Variables used within the template for storing or manipulating data should not leak or overwrite each other between different template instances.
+===== Efficiency =====
+Even though templates can be included multiple times, there should be considerations for:
+* Page Load Time: Multiple queries or complex template processing might slow down page loading if not optimized.
+* Cargo Query Optimization: Efficient use of Cargo's ability to limit, join, or filter data to reduce unnecessary database hits or compute overhead with each inclusion.
+===== Modular design =====
+Such templates are usually designed to be modular and reusable, meaning they:
+* Are built with the idea that their content will change with each use, based on the parameters passed or the data queried.
+* Maintain Consistency: While they can show different data, the format and style remain consistent, which is useful for maintaining a uniform look across different content on the same page..
 ==== Use full wikitext instead of #template_display ====
 You need to manually write out how you want template data to appear using MediaWiki's language, rather than relying on the automated or semi-automated display mechanisms provided by extensions like Cargo. This approach is chosen for greater control, customization, or when the display logic provided by extensions does not meet the specific needs or design requirements of the page.