Working with Pages, Templates, and Content
Pages, Templates, and Content represent the three primary options for creating user-facing interfaces in the Magentrix platform through the Integrated Development Environment. Each page type serves distinct purposes based on complexity requirements, controller support needs, and developer skill levels, enabling organizations to implement appropriate solutions ranging from dynamic, data-driven experiences to simple HTML layouts and visually-edited content pages.
Understanding the capabilities, limitations, and appropriate use cases for each page type ensures efficient development practices, maintainable code organization, and optimal user experiences across portal implementations while leveraging the strengths of each development approach.
Understanding Page Types
Active Pages
Active Pages represent the most powerful and flexible page development option, supporting full controller integration following the Model-View-Controller (MVC) architecture pattern. These pages combine HTML markup with C# controller logic, enabling dynamic content generation, data manipulation, user input processing, and complex business logic implementation.
Primary Use Cases: Active Pages are appropriate for interactive forms requiring data validation and processing, list views displaying entity records with filtering and sorting capabilities, detail pages showing record information with related data, dashboards presenting aggregated information and analytics, and any page requiring server-side logic execution before rendering content to users.
Controller Association: Active Pages can optionally include associated controllers that execute C# code server-side before page rendering. Controllers access entity data, perform calculations, validate inputs, execute business logic, and prepare data for display. Pages can function without controllers when only static HTML content is required, though most Active Pages leverage controller capabilities for dynamic functionality.
Technical Characteristics: Active Pages support the complete Magentrix SDK including entity queries, data manipulation operations, trigger execution, email sending, file operations, and integration with external systems through HTTP requests. HTML markup can include server-side expressions, data binding syntax, and control structures that interact with controller properties and methods.
Templates
Templates provide purely HTML-based page structures designed for reuse across multiple portal areas without controller logic support. These pages establish consistent visual frameworks, standardized layouts, navigation structures, and shared design elements that maintain brand consistency while reducing development time through component reuse.
Primary Use Cases: Templates are appropriate for page that do not require complex business logic and any HTML structure requiring reuse without dynamic data processing.
No Controller Support: Templates cannot have associated controllers or execute server-side logic. All content must be static HTML, CSS, and client-side JavaScript. Dynamic functionality requires implementation through JavaScript frameworks and AJAX calls to separate Active Page controllers or external APIs.
Reusability Focus: Templates are referenced from Active Pages and other Templates through include directives or template inheritance patterns, enabling centralized maintenance of shared interface elements. Updates to Templates automatically propagate to all pages that reference them, ensuring consistent appearance and behavior.
Technical Characteristics: Templates support standard HTML5 markup, CSS styling through inline styles or external stylesheet references, client-side JavaScript for interactive behaviors, and static asset references for images, fonts, and other resources. Server-side processing, data binding, and controller integration are not available.
Content Pages
Content Pages offer a what-you-see-is-what-you-get (WYSIWYG) editing experience designed for administrators who need to create HTML pages without writing code directly. The visual editor provides formatting tools, image insertion, link creation, and layout controls that generate valid HTML output suitable for portal deployment.
Primary Use Cases: Content Pages are appropriate for informational content including help documentation, policy descriptions, and instructional materials, marketing content such as product descriptions and promotional pages, static portal content like about pages and contact information, and any page requiring content creation by non-technical administrators.
No Controller Support: Like Templates, Content Pages cannot have associated controllers or execute server-side logic. All content is generated through the WYSIWYG editor and stored as HTML markup without dynamic data processing capabilities.
Visual Editing Environment: The WYSIWYG editor provides formatting controls for text styling (bold, italic, fonts, colors), paragraph formatting (headings, alignment, lists), media insertion (images, videos), link creation (internal and external), table creation and formatting, and HTML source view for direct markup editing when needed.
Technical Characteristics: Content Pages generate clean HTML markup from visual editor operations, support embedded images through base64 encoding or external references, enable CSS styling through editor controls or inline styles, and allow HTML source editing for advanced customization while maintaining visual editing capabilities for subsequent updates.
Creating Active Pages
Accessing Page Creation
Navigate to the File menu in the IDE and select New Page to open the page creation dialog. The dialog provides fields for page identification, URL path specification, and page type selection.
Required Field Configuration
Label Field: Enter a descriptive label that will display in the sidebar navigation tree under the Pages section. Labels should clearly indicate page purpose and functionality to enable easy identification during development and maintenance activities.
Path Field: Define the URL path portion that follows the /aspx/ base path. The complete page URL will be http://portaldomain/aspx/<Path> where <Path> is the value entered in this field. Path values must use valid URL characters without spaces or special characters that require encoding.
Type Selection: Ensure Active Page is selected in the Type dropdown. Active Page is the default selection when accessing page creation through the New Page menu option, making it the quickest path for creating pages with controller support.
Path Naming Considerations
URL Structure: The /aspx/ base path is mandatory and cannot be customized. All Active Pages, Templates, and Content Pages use this consistent base path as part of the Magentrix platform architecture.
Valid Characters: Path values should use alphanumeric characters, hyphens, and forward slashes for hierarchical organization. Avoid spaces, special characters, and encoded characters that reduce URL readability and create potential issues with bookmarks and external references.
Hierarchical Organization: Paths can include forward slashes to create logical URL hierarchies such as /aspx/admin/users, /aspx/reports/sales, or /aspx/partner/dashboard. Hierarchical paths improve URL readability and support organized site structure without requiring folder creation.
Descriptive Naming: Choose path names that clearly indicate page purpose and are meaningful to end users who may see URLs in their browser address bar. Descriptive paths support search engine optimization and enable users to understand page content from URL structure alone.
Page Creation Completion
Click Create to generate the new Active Page. The IDE creates the page file, adds it to the Pages section in the sidebar navigation tree, and automatically opens the page in a new tab in the editor workspace. The new page contains minimal default HTML structure ready for customization.
Adding Controllers to Active Pages
Controller Creation from Active Page
Open an existing Active Page in the editor to display the page content and editing interface. Locate the "+ Add Controller" button in the top-right corner of the page editor interface, positioned above the code editing area.
Click the "+ Add Controller" button to automatically create an associated controller class for the current Active Page. The IDE generates a new controller file with a name derived from the page name with "Controller" appended as a mandatory suffix.
Automatic Naming Convention: If the Active Page is named "LandingPage," the controller will be named "LandingPageController." This naming convention is mandatory and cannot be customized during controller creation. Renaming the page after controller creation does not automatically update the controller name.
Accessing Existing Controllers
Once a controller is created for an Active Page, the "+ Add Controller" button is replaced with a clickable link displaying the controller name. Clicking this controller name link opens the associated controller file in a new tab, enabling quick navigation between page markup and controller logic.
Controller Location: Created controllers also appear in the Controllers & Classes section of the sidebar navigation tree, providing an alternative access method through the standard sidebar navigation workflow. Controllers can be opened from either the page editor link or the sidebar tree structure.
Controller Purpose and Function
Controllers implement the C# business logic that executes server-side before the Active Page is rendered to users. Controller code can query entity data, process form submissions, validate user inputs, perform calculations, execute business rules, prepare display data, and determine page behavior based on conditions.
MVC Pattern Implementation: The controller serves as the intermediary between data models (Magentrix entities) and views (Active Page HTML markup). Controllers retrieve data from entities, transform it as needed for display purposes, and make it available to the page through properties and methods that the page markup can reference.
Execution Lifecycle: When a user requests an Active Page, the associated controller's initialization and action methods execute first, performing all necessary data operations and logic. After controller execution completes, the page HTML renders using data prepared by the controller, generating the final output sent to the user's browser.
Creating Templates
Accessing Template Creation
Navigate to the File menu in the IDE and select New Template to open the template creation dialog. Template creation uses a slightly different dialog than Active Page creation, reflecting the different purpose and characteristics of template files.
Required Field Configuration
Label Field: Enter a descriptive label that will display in the sidebar navigation tree under the Templates section. Template labels should clearly indicate the template's purpose and usage context, such as "Header Navigation," "Email Template - Welcome," or "Standard Form Layout."
Unique Name Field: Define a unique identifier for the template that will be used when referencing the template from code in Active Pages or other templates. Unique names should follow consistent naming conventions without spaces or special characters, using formats like "HeaderNavigation," "EmailWelcome," or "StandardFormLayout."
Type Selection: Ensure Template is selected in the Type dropdown. When accessing template creation through the New Template menu option, Template is automatically selected as the appropriate type.
Template Creation Completion
Click Create to generate the new Template. The IDE creates the template file, adds it to the Templates section in the sidebar navigation tree, and opens the template in a new tab in the editor workspace. Templates contain HTML markup without any controller-specific elements or server-side processing directives.
Template Usage and References
Templates are designed for inclusion in Active Pages through template reference syntax, enabling reuse of common HTML structures across multiple pages. When Active Pages reference templates, the template HTML is inserted into the page at the reference location during page rendering.
Centralized Maintenance: Updates to template HTML automatically affect all pages that reference the template, ensuring consistent appearance and behavior across the portal. This centralization reduces maintenance effort and ensures design consistency without requiring updates to individual pages.
No Controller Association: Templates cannot have controllers added and do not support server-side data binding or logic execution. All dynamic functionality within templates must be implemented through client-side JavaScript that executes in the user's browser after page rendering completes.
Creating Content Pages
Accessing Content Page Creation
Navigate to the File menu in the IDE and select New Content Page to open the content page creation dialog. Content Pages use the same basic field structure as Active Pages since both serve as standalone pages accessible through URLs.
Required Field Configuration
Label Field: Enter a descriptive label that will display in the sidebar navigation tree under the Contents section. Content Page labels should indicate the content purpose and subject matter, enabling content managers to locate and edit the appropriate pages.
Path Field: Define the URL path portion following the /aspx/ base path, using the same path naming conventions and considerations as Active Pages. Content Page URLs follow the identical structure: http://portaldomain/aspx/<Path>.
Type Selection: Ensure Active Content Page is selected in the Type dropdown. When accessing content page creation through the New Content Page menu option, Active Content Page is automatically selected.
Content Page Creation Completion
Click Create to generate the new Content Page. The IDE creates the content page file, adds it to the Contents section in the sidebar navigation tree, and opens the page in the WYSIWYG editor workspace. The visual editor provides formatting tools and controls for content creation without requiring HTML coding knowledge.
WYSIWYG Editor Capabilities
Visual Formatting: The editor provides toolbar controls for text formatting including font selection, size adjustment, bold, italic, underline, color selection, and alignment options. These visual controls generate corresponding HTML markup without requiring manual tag entry.
Content Structure: Heading level selection, paragraph formatting, bulleted and numbered lists, blockquotes, and horizontal rules can be inserted through toolbar controls, enabling proper document structure and semantic HTML generation.
Media Insertion: Images can be uploaded directly through the editor interface or referenced from external URLs. The editor handles image placement, sizing, alignment, and alternative text specification through visual controls.
Link Creation: Internal portal links and external URLs can be created by selecting text and using the link insertion tool. Link properties including target window behavior and title attributes are configurable through dialog interfaces.
HTML Source Access: An HTML source view mode enables direct markup editing for advanced customization, corrections, or insertion of specific HTML elements not available through visual controls. Switching back to visual mode maintains compatibility with subsequent visual editing operations.
Content Page Limitations
Content Pages cannot have associated controllers or execute server-side logic. All content is static HTML generated through the WYSIWYG editor. Dynamic functionality requires implementation through client-side JavaScript or embedding Active Page components that provide necessary dynamic capabilities.
Opening and Editing Pages
Opening from Sidebar Navigation
Navigate to the Pages, Templates, or Contents section in the sidebar navigation tree depending on the type of page to be edited. Expand the section if necessary to display all available pages organized in the tree structure.
Double-Click Opening: Double-click on any page name in the sidebar tree to open that page in a new tab in the editor workspace. This method provides the fastest access to pages for editing operations.
Right-Click Context Menu: Right-click on any page name to display a context menu with available actions. Select Open from the context menu to open the page in a new tab. This method provides consistency with other IDE element opening workflows.
Multiple Simultaneous Editing
The IDE supports opening multiple pages, templates, and content pages simultaneously in separate tabs. Each open tab maintains an independent editing session with its own undo history, unsaved changes tracking, and cursor position.
Tab Management: Switch between open pages by clicking tab headers at the top of the editor workspace. Tab labels display page names with visual indicators showing unsaved change status, enabling quick identification of files requiring save operations.
Cross-Referencing: Multiple open tabs enable efficient cross-referencing between related pages, templates, and controllers. Developers can view page markup while editing controller code, reference template HTML while building pages, or compare implementation patterns across multiple pages.
Editor Interface
Active Pages and Templates: Open in a code editor with syntax highlighting for HTML, CSS, and JavaScript. The editor provides line numbering, code folding for HTML elements, and find/replace functionality for efficient code editing.
Content Pages: Open in the WYSIWYG visual editor by default, with option to switch to HTML source view for direct markup editing. The editor toolbar provides formatting controls and insertion tools appropriate for visual content creation.
Controller Access: When editing Active Pages with associated controllers, the controller name link in the top-right corner enables quick navigation to the controller file without searching through the sidebar navigation tree.
Saving Changes
Manual Save Requirement
The IDE does not include automatic save functionality. All changes to pages, templates, and content must be saved explicitly through save buttons or keyboard shortcuts. Unsaved changes are indicated visually on tab labels with markers or text styling.
Save Button: Each editor tab includes a save button in the toolbar or interface controls. Clicking this button saves the current file and triggers code validation for files containing code elements.
Keyboard Shortcuts: Standard save keyboard shortcuts (Ctrl+S on Windows/Linux, Command+S on macOS) save the active file currently displayed in the editor. Using keyboard shortcuts provides faster save access during active development.
Code Validation on Save
When saving Active Pages with controllers or controller files themselves, the IDE performs automatic code compilation and validation. Validation results appear at the bottom of the editor displaying any syntax errors, compilation issues, or type mismatches.
Error Display: Validation errors show specific line numbers and error descriptions, enabling quick identification and correction of issues. Errors must be resolved before the page or controller can be successfully deployed and executed.
Successful Validation: When validation completes without errors, a success indicator appears confirming that the code compiles correctly and is ready for execution. Successful validation does not guarantee correct logic or expected behavior, only that the code syntax and types are valid.
Unsaved Changes Handling
Attempting to close a tab with unsaved changes triggers a confirmation prompt asking whether to save changes before closing. This protection prevents accidental loss of development work when switching between files or closing the IDE.
Save Options: The prompt provides options to save changes and close, discard changes and close, or cancel the close operation to continue editing. Selecting save triggers validation for code files before completing the close operation.
Multiple Unsaved Files: When closing all tabs through the Window menu or exiting the IDE with multiple unsaved files open, the IDE prompts for save confirmation on each file sequentially, ensuring no unsaved work is lost.
Deleting Pages, Templates, and Content
Deletion Process
Right-click on the page name in the sidebar under the Pages, Templates, or Contents sections to display the context menu. Select Delete from the context menu options to initiate the deletion process.
A confirmation dialog appears requesting verification of the deletion operation. Confirm the deletion to permanently remove the page from the sidebar navigation and mark it for deletion in the system.
Recovery from Recycle Bin
Deleted Active Pages, Templates, and Content Pages can be recovered from the Recycle Bin if deletion was accidental or the page is needed again. The Recycle Bin provides a safety mechanism for recovering deleted pages before permanent removal.
Recycle Bin Access: Access the Recycle Bin through the Setup menu in the administrative interface. Navigate to the appropriate section (Pages, Templates, or Contents) within the Recycle Bin to locate deleted items.
Recovery Process: Select the deleted page in the Recycle Bin and use the restore function to return it to the active pages list. Restored pages reappear in the sidebar navigation tree and can be opened and edited normally.
Permanent Deletion: Pages remain in the Recycle Bin until permanently deleted through Recycle Bin management operations or automatic cleanup processes. Understanding Recycle Bin retention policies ensures appropriate recovery windows for accidentally deleted pages.
Deletion Impact Considerations
Active Page Usage: Before deleting Active Pages, verify that the page is not linked from navigation menus, referenced in other pages, or bookmarked by users. Deleting pages that are actively in use creates broken links and error conditions for users attempting to access deleted content.
Template References: Before deleting Templates, identify all Active Pages and other Templates that reference the template. Deleting referenced templates causes errors in pages that attempt to include the template, requiring updates to remove or replace template references.
Controller Dependencies: Deleting Active Pages with associated controllers leaves orphaned controller files in the Controllers & Classes section. Consider deleting associated controllers when deleting pages to maintain clean code organization, though controllers can remain if they contain reusable logic needed by other code.
Content Page Links: Before deleting Content Pages, review portal navigation and verify that no links point to the content page URL. Update or remove links before deletion to prevent broken navigation and error messages for users.
Path and URL Management
Understanding URL Structure
All Active Pages and Content Pages are accessible through URLs following the format http://portaldomain/aspx/<Path> where portaldomain represents the organization's portal domain and <Path> is the value specified in the Path field during page creation.
Base Path Requirement: The /aspx/ base path is mandatory for all pages and cannot be customized or changed. This consistent base path is part of the Magentrix platform architecture and enables proper routing of page requests to the IDE-created pages.
Custom Path Portion: The <Path> portion following /aspx/ is fully customizable and should reflect logical URL structures appropriate for site organization, user understanding, and search engine optimization.
Path Modification Limitations
Once a page is created, the path cannot be changed through the IDE interface. Path modifications require deleting the existing page and creating a new page with the desired path, then copying content from the old page to the new page.
Reference Updates: If a page with an existing path is deleted and recreated with a new path, all links, bookmarks, and references using the old path become broken. Systematic updates to navigation menus, internal links, and external references are necessary when changing page paths.
URL Planning: Plan page URL structures carefully during initial creation to minimize the need for path changes later. Consider logical hierarchies, consistent naming patterns, and long-term site structure requirements when defining paths.
Path Best Practices
Descriptive Naming: Use path names that clearly describe page content and purpose. Descriptive paths improve user understanding from URLs alone and support search engine indexing and ranking.
Hierarchical Organization: Implement logical hierarchies using forward slashes to group related pages such as /aspx/admin/users, /aspx/admin/settings, /aspx/reports/sales, /aspx/reports/revenue. Hierarchical paths improve site organization and enable intuitive navigation patterns.
Consistent Patterns: Establish and follow consistent path naming conventions across all portal pages. Consistency improves maintainability, reduces errors, and creates predictable URL structures that users can understand and remember.
Avoid Frequent Changes: Minimize path changes after pages are deployed and in use by portal users. Path changes break bookmarks, external links, and search engine indexing while requiring systematic updates to all internal references.
Page Type Selection Guidelines
When to Use Active Pages
Select Active Pages when implementing functionality that requires server-side data processing, database queries, business logic execution, user input validation, session management, or dynamic content generation based on user context or entity data.
Data-Driven Interfaces: Active Pages excel at displaying entity records in lists or detail views, implementing search and filtering functionality, showing dashboard analytics, and presenting any content that requires querying Magentrix entities or external data sources.
Interactive Forms: Form submission processing, input validation, data persistence to entities, multi-step workflows, and conditional form behavior all require controller logic best implemented through Active Pages.
User Context: Displaying personalized content based on logged-in user properties, role-based interface customization, user-specific data filtering, and session-dependent behavior require controller access to user context available only in Active Pages.
When to Use Templates
Select Templates when creating reusable HTML structures that will be included in multiple pages, establishing consistent visual frameworks, defining standard layouts, or building component libraries that maintain design consistency without requiring dynamic data processing.
Shared Interface Elements: Navigation menus, page headers and footers, sidebar layouts, common form structures, and consistent formatting patterns are ideal template use cases enabling centralized maintenance and consistent appearance.
Email Templates: Transactional and notification email HTML structures benefit from template implementation, allowing email content to be maintained separately from email sending logic in controllers while ensuring consistent formatting.
Static Layouts: Layout frameworks that provide structure for content but don't require server-side data processing work well as templates, separating presentation structure from data and logic concerns.
When to Use Content Pages
Select Content Pages when creating content that requires regular updates by non-technical administrators, implementing simple informational pages without dynamic functionality, or building static portal content where WYSIWYG editing capabilities support efficient content management.
Informational Content: Help documentation, policy descriptions, about pages, contact information, and other largely static content benefit from visual editing capabilities that enable content updates without HTML coding knowledge.
Marketing Materials: Product descriptions, service offerings, promotional content, and landing pages with primarily static content are appropriate for Content Pages, enabling marketing teams to update content directly without developer involvement.
Documentation: User guides, FAQs, troubleshooting instructions, and reference materials work well as Content Pages, allowing documentation teams to maintain current information using familiar word processor-like editing interfaces.
Best Practices and Recommendations
Code Organization
Controller Logic Separation: Keep presentation markup in Active Pages separate from business logic in controllers. Avoid embedding complex C# expressions directly in page HTML; instead, implement logic in controller methods and reference results through simple property access in pages.
Template Reusability: Design templates with parameterization and flexibility to support multiple use cases. Generic, configurable templates provide greater reuse value than highly specific templates designed for single-page implementations.
Consistent Naming: Follow consistent naming conventions for pages, templates, and content files. Include purpose indicators, feature identifiers, and version numbers when appropriate to enable efficient location and identification during development and maintenance.
Performance Optimization
Minimal Controller Logic: Keep controller execution time minimal by implementing only necessary data operations and calculations. Excessive controller processing delays page rendering and impacts user experience through increased response times.
Efficient Template Inclusion: Limit the number of template includes per page to reduce processing overhead. Each template reference adds processing time during page rendering, so balance reusability benefits against performance considerations.
Client-Side Processing: Implement interactive behaviors and user interface enhancements through client-side JavaScript rather than server-side controller logic when possible. Client-side processing reduces server load and enables responsive user interfaces without page refreshes.
Maintainability Considerations
Documentation and Comments: Include comments in Active Page markup and controller code explaining complex logic, describing page purpose and functionality, and providing guidance for future developers. Documentation reduces maintenance time and prevents misunderstandings.
Version Control: Maintain external version control or backup copies of critical pages, templates, and controllers. While the Recycle Bin provides recovery for deleted pages, version control enables restoration of previous working versions when modifications introduce issues.
Testing Procedures: Test all pages thoroughly in non-production environments before deploying to user-facing portals. Verify correct functionality, error handling, edge case behavior, and integration with other portal components to ensure quality and reliability.
Content Review: Review and update Content Pages regularly to ensure information remains current, accurate, and aligned with organizational policies and offerings. Stale content reduces user trust and provides outdated information that may mislead users.
Jump to IDE Checklist
<< IDE Checklist | Working with Controllers and Classes >>