Skip to content

Using the Design Panel

Design panel provides you with visual tools to style your page content. You can design for different screen sizes, which creates the required styles and media q

Use Demo Projects HQ to see why login pages use a different layout from the main app shell.

Login-style pages usually need a tighter frame than the main app. Demo Projects HQ shows that split clearly with a dedicated auth layout and a separate routed login page.

The main app shell serves authenticated screens.
The auth shell keeps login and similar pages focused.
The routed login page reuses the auth shell instead of rebuilding it inline.

This topic only makes sense if you separate the shell from the routed page itself. Pages Manager gives you both views in one place: layouts in their folder, then the actual login page at the Pages root.

Layouts define the wrapper.
Root pages define the actual destination.
Auth flows usually need both pieces.

Start in layouts so you can inspect the dedicated auth shell before jumping into the login page that uses it. This makes the relationship between wrapper and destination explicit.

auth.ejs is the reusable shell for access-related pages. Its job is to provide just enough framing for login and similar screens without carrying the whole signed-in application experience.

Use a focused shell for login and onboarding gates.
Keep full application navigation out of pre-login screens.
Reuse the shell across related auth pages when needed.

After inspecting the shell, go back to the real Pages root so the login destination page becomes visible. That shift is the core mental model: shell first, destination second.

login.ejs is the actual routed page users visit. It owns the login form and action wiring, while the auth layout supplies the wrapper around it.

The page owns the form and submit behavior.
The layout owns the surrounding shell.
Keeping those concerns separate makes auth flows easier to maintain.

Opening login.ejs is the right handoff into the login walkthrough. From there, the form wiring, submit action, and shared security provider all become visible in context.

The maintainable auth pattern is a dedicated shell plus a dedicated login destination page. That keeps access flows focused while still making the login form and security wiring easy to inspect in the editor.

Keep the auth wrapper reusable.
Keep the login page responsible for the form flow.
Continue into the login walkthrough for the concrete implementation details.

Task-focused Pages recipes: choose the right page surface, move into editing, and hand off cleanly into layout building.

Use these recipes when the job is to organize the page, move into editing, and choose the right next family once the page exists.

Start with the correct page surface.
Move cleanly from management into editing.
Use the next family based on what the page needs next.

Start with Pages Manager when the task is about finding, creating, or organizing the page itself. That keeps navigation and file choice clear before editing begins.

Use it to browse and create pages.
Use it when folder context matters.
Treat it as the page control surface, not the final editor.

Once the page is chosen, move into the HTML Editor for actual building work. This is the main handoff that makes the Pages family understandable for beginners.

Open the page, then switch mental mode to editing.
Use the HTML Editor for layout, structure, and page composition.
Keep the manager and editor roles separate.

After the page is open, use the next family that matches the work: Bootstrap for layout, HTML Editor deep dives for editor behavior, or App Connect for dynamic page behavior.

Use Bootstrap for structure and components.
Use HTML Editor tours for editor-specific skills.
Use App Connect when the page becomes data-driven.

Return to the Pages tours menu to continue with quick orientation, workflow guidance, or reference.

Use Quick Overview for the short mental model.
Use General Usage for the repeatable Pages workflow.
Go deeper through HTML Editor, Bootstrap, or App Connect when ready.

Use Demo Projects HQ to understand layout pages, shared shells, and the content slot that routed pages fill.

In Demo Projects HQ, layout pages are the reusable shell above individual screens. They carry the persistent frame, then leave a content slot for the routed page that belongs inside it.

Layouts hold shared chrome like navigation and page framing.
Content pages provide the screen-specific body for a route.
Pages Manager lets you compare those roles with the real files side by side.

Pages Manager separates structure from editing. The tree on the left decides which folder you are reading, so it is the fastest way to understand whether you are looking at shared layouts or regular routed pages.

Tree selection changes the file list on the right.
Folders tell you the role of a page before you open it.
Layouts are easier to teach when you contrast them with normal pages.

Start from the real Pages (views) root so the story begins at the top of the project page structure. From there, the layouts folder reads as a special-purpose branch instead of just another random directory.

The layouts folder is where Demo Projects HQ keeps the reusable shells. Selecting it filters the template list so you can compare the shared frame files directly.

main.ejs is the broad application frame. It is the layout that carries navigation and the shared structure for the main signed-in experience, then leaves the page body to the routed content file.

Use this shell when pages should feel like part of the full app.
Keep shared navigation and structure here.
Let content pages handle the screen-specific data and controls.

auth.ejs exists because not every route should inherit the full application frame. Login-style screens usually need a smaller, quieter wrapper so the user can complete a focused access task first.

A separate auth shell keeps access flows simple.
It avoids pulling full app navigation into pre-login screens.
It still stays reusable because multiple auth-related pages can share it.

Opening the real main.ejs layout is the practical handoff from page organization into editing. That next view lets you inspect the shared shell and the dmx-view content slot that routed pages fill.

Layouts make more sense when you treat them as reusable shells, not destination pages. From here, opening the real layout in the HTML Editor is the right next step because that is where the shared structure and content slot become visible.

Use Pages Manager to identify the correct shell.
Keep shared frame decisions in the layout.
Inspect the actual layout file next in the HTML Editor.

Get a quick overview of Pages: where page management ends, where editing begins, and how the family fits together.

Pages is where a project starts turning into visible screens. The key mental model is simple: manage pages in Pages Manager, then build inside the HTML Editor.

Pages Manager helps you organize and open pages.
The HTML Editor is where the page is actually built.
Layout and component work continues from there into Bootstrap and App Connect.

The Pages family becomes easier to grasp when you separate two jobs: management and editing. One surface helps you find pages; the other helps you shape them.

Use Pages Manager to find, create, and open pages.
Use the HTML Editor to build layout and content.
Do not expect the manager to be the deepest design surface.

This family is also a handoff path. After pages are open, the next useful questions are about editing, layout, styling, and dynamic data.

Go to Pages Manager for the browsing workflow.
Go to HTML Editor for the editing surface.
Go to Bootstrap or App Connect when the page needs structure or dynamic behavior.

The beginner takeaway is simple: Pages is the bridge from project setup into real screen-building. Learn the handoff from Pages Manager to HTML Editor first, and the rest gets easier.

Organize in Pages Manager.
Build in the HTML Editor.
Continue with layout and dynamic-data tours after that.

Reference tour for Pages: Pages Manager UI, the HTML Editor entry points, and how page-building flows connect to layout and design tools.

Treat this reference tour as a quick orientation to the Pages area rather than a list of labels to memorize. It shows where page-related actions live, how the area fits into everyday editing, and what to revisit later when you need to add, organize, or inspect project pages.

Pages is the umbrella family for page selection and handoff.
Pages Manager and HTML Editor serve different jobs.
Bootstrap and App Connect are common follow-up families once a page is open.

Pages Manager is the real reference point for page selection, page creation, and page organization. In Demo Projects HQ, it shows the live folder tree and page listing that determine which page or layout you are actually about to open.

Navigation and page organization live here.
This is the first stage of the page workflow.
It is not the deepest design surface.

Keep the full Pages tree in view first. The next steps stay inside this live Pages Manager surface while the tour selects the real Pages root, moves into the layouts folder, and then points at a real layout tile from Demo Projects HQ.

This step selects the real Pages (views) root node so the rest of the reference tour stays grounded in the actual Demo Projects HQ page structure.

This step selects the real layouts folder so the reference tour can discuss folder-level actions from the actual Demo Projects HQ tree node.

This step opens the real context menu on the already-selected layouts folder. That makes page-management actions concrete: folder operations such as Rename, Delete, Upload, and Show in Explorer are attached to the actual tree node you selected.

The HTML Editor is the real destination for actual page editing. This step points at the live main.ejs layout tile from Demo Projects HQ, which is the handoff point from page management into layout and structure work.

This is where page construction happens.
Editor-specific tours belong there.
Pages family hands off into it by design.

Bootstrap and App Connect are common next families because page building often moves from structure into styling and then into dynamic behavior.

Bootstrap supports visual layout and component structure.
App Connect supports reactive and dynamic page behavior.
The sequence depends on what the page needs next.

Continue with the Pages hub for guided entry points, or move into Pages Manager, HTML Editor, Bootstrap, or App Connect for deeper detail.

Return to the Pages hub.
Use Pages Manager for page selection workflow.
Use HTML Editor, Bootstrap, or App Connect for deeper implementation detail.

Use Demo Projects HQ page tiles to see the list, detail, and form pages that routing targets.

Once a layout is chosen, the routed content page becomes the screen-specific destination. Demo Projects HQ makes that easy to read because its list, detail, and form pages are all visible as real page tiles.

Collection pages summarize many records.
Detail pages focus one route-selected record.
Create and edit pages turn that route into a task flow.

The Pages tree is the quickest way to tell whether you are looking at shared layouts or the actual routed screens users visit. For route-aware work, the interesting files live at the Pages root rather than inside layouts.

Layouts are wrappers.
Root pages are the destination files.
Routes normally point at these concrete destination pages.

Selecting the real Pages root exposes the content page tiles that map to meaningful routes in Demo Projects HQ. That makes the list, detail, and form patterns visible as concrete files instead of documentation vocabulary.

projects.ejs is the list-style destination. This is the page pattern you open when a route needs to summarize many records and give the user a starting point for navigation.

Collection pages show many records at once.
They usually link deeper into detail or create flows.
They are often the first page a user lands on after login.

project.ejs is the detail-style destination. It exists for a route that identifies one specific record, which is why detail pages usually depend on route parameters or record context.

Detail pages focus on one selected record.
A URL parameter often decides which record loads.
They commonly link back to the collection page.

project_add.ejs is the task-oriented page pattern. It turns navigation into a concrete user job like adding a record, which is why form pages deserve their own route instead of being hidden inside a list screen.

Task pages guide the user through one focused action.
A dedicated route keeps the workflow predictable.
After save, they usually redirect back into a list or detail page.

After the page roles are clear, the next question is how URLs choose between them. That is the routing layer’s job.

Routes map URLs to the correct content page.
Layouts wrap the page after that decision is made.
Internal links should follow those generated route patterns.

Typical Pages path: organize pages, open the right file, and continue building in the HTML Editor.

A typical Pages path is straightforward: choose the right page, open it, then keep working in the editor that matches the job instead of treating every page task as the same kind of work.

Start by finding or creating the correct page.
Open it and switch into the HTML Editor for real editing.
Continue with layout, styling, or dynamic data based on what the page needs next.

Use Pages Manager to stay oriented in the project and pick the correct file. In Demo Projects HQ, that starts with the live tree and page list so you can see exactly which folder and tile you are about to work from.

Find the right folder and page first.
Create new pages there when needed.
Use the manager as the control surface for page selection.

This step selects the real Pages (views) root node so the tour starts from the actual Demo Projects HQ page structure instead of a generic description.

This step selects the real layouts folder so the page list on the right reflects a concrete folder choice. That is the practical Pages habit: choose the correct folder first, then choose the actual page or layout item from its listing.

Once the right folder is selected, the next move is to open the actual page or layout tile you want. This step points at the live main.ejs layout tile from Demo Projects HQ and uses it as the concrete handoff into the HTML Editor.

Management gets you to the right page.
Editing happens in the HTML Editor.
The handoff is the key Pages habit to learn early.

After the page is open, the next decision depends on the job: layout and components, styling, or dynamic data binding. That is why Pages is a bridge family, not the final end point for every lesson.

Use Bootstrap tours for layout building.
Use HTML Editor tours for editor-specific depth.
Use App Connect when the page becomes dynamic.

The practical Pages habit is to separate finding a page from building a page. That keeps the workflow easy to understand and makes the rest of the manual feel more logical.

Select the right page first.
Edit in the right surface second.
Continue into the next specialized family third.