Browsing Entity Reference Pages and Related Details

Opening an entity reference page from project and public documentation

In Atloria, you can open an entity reference page in two places: inside a project workspace and in published documentation. The project view is the working area your team uses while reviewing generated technical documentation alongside drafts and unpublished content. The public view is the published reading experience that outside readers or broader internal audiences use after documentation is released.

If you already worked through Managing Technical Documentation Browsing and API Reading, the main difference here is that you are no longer just browsing section lists—you are opening one specific reference item and reading its full detail page.

Common ways to reach an entity page include:

• Clicking an item in an API reference list
• Opening a result from search
• Selecting an item from a namespace or module page
• Following a linked type or member name inside another reference page
• Choosing a related symbol from a member list

In the project workspace, start from your project’s technical documentation area and open the API reference section. From there, select an item from the reference index or drill down through grouped pages until you see the entity name you want. In published documentation, use the public navigation, search, or linked names inside the page content to open the same kind of detail page.

You can usually tell which context you are in by the page frame around the content. Project pages appear inside the project workspace navigation, while public pages appear in the published documentation layout. Breadcrumbs also help: project breadcrumbs keep you inside the project’s documentation structure, while public breadcrumbs reflect the published documentation path.

When several items share similar names, use the breadcrumb trail and the page title together before you continue. That helps confirm you opened the right reference item.

Reading the main details shown on an entity page

At the top of an entity reference page in Atloria, the header gives you the fastest way to identify what you are looking at. Start with the entity name shown as the main title. Near that title, you may also see a kind label that tells you what sort of item it is, such as a type, method, property, event, or another reference item. Many pages also show a fully qualified path near the top, which helps distinguish similarly named items that belong to different modules, namespaces, or sections.

A short summary may appear directly under the title area. Read this first before moving into the detailed sections. It usually gives the clearest one-line explanation of what the item represents or how it is used.

Signature information is typically shown near the top of the page as a formatted block. Depending on the item, this block may include the item name, parameter list, return type, generic type parameters, and modifiers when Atloria has that information available. You do not need to interpret every symbol immediately. Focus on these questions:

Status indicators may also appear near the top or beside the item name. If you see labels such as deprecated, internal, experimental, or inherited, treat them as reading cues. They tell you whether the item is older, limited in visibility, still changing, or coming from a parent item rather than being defined directly here.

Description and remarks sections usually appear below the signature. Inline links inside those sections often point to related items, letting you understand the current page without leaving the reference flow unless you need more detail.

Interpreting related information attached to the entity

Most entity pages in Atloria include grouped sections below the main header. These sections help you move from “what is this item?” to “how does this item connect to everything around it?” The exact sections vary by item, but you will commonly see details such as parameters, properties, methods, events, examples, or inherited members.

When you read these sections, treat them as layers:

• The header identifies the item
• The description explains it
• The related sections show how it behaves or what belongs to it

For example, a page for a larger reference item may include a member list showing its properties or methods. A page for a callable item may include a parameters section and a return value area. If examples are available, read them after the summary and signature so the example has context.

Type references inside these sections are often clickable. Selecting a linked type name opens another entity page so you can inspect that related item directly. Relationship labels help you understand why the link is there. A parent relationship points upward to the containing item. A child relationship points to members or nested items. Dependency-style links usually point to types or related items used by the current page.

You may also see source-related details when Atloria exposes them. These can include package, module, namespace, file, or version information. Those labels help you place the item in the broader documentation structure, especially when names repeat across different areas.

Status tags are especially important in related sections:

Moving between related reference items on the page

Long reference pages in Atloria are easier to use when you rely on the page’s built-in navigation instead of scrolling from top to bottom every time. Start with the table of contents or section links if they are shown. These let you jump directly to areas such as parameters, properties, methods, examples, remarks, or inherited members.

Anchor links are especially useful when you are comparing several parts of one page. If a member list is long, click the member name in the list to jump directly to that member’s detailed section. This is faster than searching visually through repeated headings.

You can also move outward from the current page by following linked names inside the content. Common links include:

• Parameter types
• Return types
• Base classes
• Implemented interfaces
• Related members
• Parent items in the breadcrumb trail

These links help you build context one step at a time. For example, if a method returns a type you do not recognize, click the return type name to open that type’s page. If a property is inherited, use the parent link or breadcrumb to move up and inspect the containing item.

Breadcrumbs are the quickest way to back out without losing your place. Use them to return to the containing namespace, module, package, or category page. From there, you can open sibling items—other items listed beside the one you are reading—to compare nearby reference entries without starting over from search.

A practical reading pattern is:

1. Read the page header and summary
2. Jump to the section you need with the table of contents
3. Open linked types only when a term is unclear
4. Use breadcrumbs to return to the parent page
5. Open sibling items from the member list or side navigation

This approach keeps you oriented even when the reference set is large.

Switching between project and public views without losing context

In Atloria, the same entity can appear in both the project workspace and the published documentation view. The page content may look similar, but the surrounding navigation and available content can differ. When you switch between these views, your goal is to confirm that you are still reading the same reference item.

Start by checking three identifiers on the page:

If Atloria provides a view-switching control or separate navigation paths for project and public documentation, use those rather than manually retracing your steps. Matching breadcrumbs are also useful. In the project workspace, the breadcrumb trail keeps you inside the project’s documentation structure. In the public view, the breadcrumb trail follows the published structure. Even when the layouts differ, the entity name and path should still line up.

Expect some differences between views. In the project workspace, you may see draft descriptions, unpublished items, or content still being reviewed. In the public view, those items may be hidden or filtered out. Public pages may also show only what has been released, which can make a member list look shorter than the project version.

If something looks different, compare the page title, path, and nearby related links before assuming it is a different item. Stable names and linked relationships usually make the match clear.

This matters most when you are checking whether published documentation reflects what your team sees internally. If the project page includes more detail than the public page, that often means the content has not been published yet rather than the reference item being missing entirely.

Recognizing common navigation issues on reference pages

When an entity page in Atloria does not look the way you expect, the issue is often the current view, the page path, or the amount of generated detail available for that item.

One common problem is a missing related member list. If you expected to see more properties, methods, or inherited items, first check whether you are in the public documentation view. Public pages may exclude internal or unpublished content that is still visible in the project workspace. If the page is shorter in public view, switch back to the project documentation area and compare the same entity there.

Another issue is opening the wrong item from a link. This usually happens when several items share a similar name. Before reading further, verify the fully qualified path, the breadcrumb trail, and the kind label near the page title. Those three details usually tell you whether you opened the correct item.

You may also click a referenced type and find that there is no full detail page. In Atloria, that can happen when the linked name points to an external reference or to a symbol that does not have its own generated page. In that case, return to the previous page and continue using the local description, signature, and remarks for context.

If the page feels incomplete, check whether the missing section was ever provided for that item. Some pages include examples, remarks, and source details, while others only include a title, signature, and short summary.

Use this quick check when something seems off:

• Missing members: compare project view and public view
• Wrong item opened: confirm breadcrumb, path, and kind label
• No detail page for a linked type: treat it as an external or undocumented reference
• Thin page content: look for whether examples, remarks, or metadata are simply not available

Overview

This guide focuses on how to read a single entity reference page in Atloria and move confidently between related reference items. Unlike broader API reference browsing guides, the emphasis here is on the details that appear once you open a specific item: the page header, summary, signature block, related sections, status labels, and links to connected items.

You will use this workflow in both major reading contexts:

• Project documentation view for internal review and unpublished reference content
• Public documentation view for released documentation that readers can browse after publication

The most important habit is to orient yourself before diving into the details. On every entity page, begin with the entity name, kind label, and qualified path. Those three elements help you confirm that you are on the correct page, especially when multiple items have similar names. From there, read the summary, then move into the sections that matter most for your task, such as parameters, properties, methods, examples, or inherited members.

This guide also explains how Atloria connects one reference item to another. Type links, member lists, breadcrumbs, and parent pages all work together so you can move through the reference set without restarting your search. That is especially useful when you are tracing relationships between items or comparing the internal project view with the published public view.

If you need a refresher on broader reference navigation before focusing on individual entity pages, return to Managing Technical Documentation Browsing and API Reading. The next step after this guide is Reading API Reference in Project and Public Views, which focuses on comparing the overall reading experience across both contexts.

Prerequisites

Before using this guide, make sure you can already open technical documentation in Atloria and move through API reference sections at a basic level. You do not need advanced technical knowledge, but you should be comfortable recognizing page titles, breadcrumbs, search results, and linked reference names.

You will get the most value from this guide if the following are already true:

If you are still getting familiar with technical reference layouts, start with Reading API and Technical Reference Pages. If your work happens mostly inside a project workspace, Managing Technical Documentation Browsing Inside Projects is the best companion for understanding internal navigation. If you often review released content, Using API Reference Pages in Published and Project Views helps you understand how the same reference content appears in both contexts.

You should also have at least one entity page available in Atloria—opened from a search result, reference index, namespace page, module page, or related symbol link—so you can follow the reading and navigation patterns described in the sections above.