Separate code from content for non-developer users

Pitfall By design
When non-developer users will administer data in a Docly solution, move display assets (index.hash, shared CSS/JS, masters, partials) into #/Root and #/Folder. The #/ tree is invisible to anyone without developer access, so this keeps the user's workspace free of code files they shouldn't touch.

What you'll see

A developer builds a Docly solution where colleagues or customer users will manage data through the Docly Admin UI. The listing template index.hash, a shared style.css, and a couple of display partials get placed in the same folder as the documents they render. When an admin user opens that folder, they see a mix of documents they should edit and code files they have no idea what are — sometimes editing or moving the wrong one and breaking the site.

What's actually happening

The #/ tree is only visible to users with developer access. Every other user — content editors, admin users, customer users signed in to Docly — sees a workspace where #/ simply does not exist. That isolation is the whole point: templates, assets and configuration can live in the same workspace as the data they render, without cluttering the editing experience of users who aren't meant to touch them.

When index.hash is placed alongside data files, that isolation is wasted. Same for shared stylesheets and scripts, master pages and other display files — they show up in directory listings, in search, and in pickers for non-developer users. They look like editable documents, because technically they are.

#/Root/ and #/Folder/ exist precisely to solve this. Files in #/Root/ are served at the site root (#/Root/style.css is reachable as /style.css). Files in #/Folder/ are inherited by every subfolder that does not override them — a single #/Folder/index.hash renders the listing for every subfolder. Same site behavior, but the files live inside the developer-only #/ tree where regular users can't see or touch them.

What to do

If the solution is administered only by developers, you can keep templates next to data — there's no audience to shield. But the moment non-developer users are involved (admin users, content editors, customer users with Docly accounts), move the display layer behind #/:

  • Per-folder listing template#/Folder/index.hash. Inherited automatically by every subfolder.
  • Site-wide assets#/Root/style.css, #/Root/main.js, #/Root/favicon.ico. Still reachable as /style.css etc.
  • Display templates per schema#/<Schema>.hash at the top of #/ (or #/Folder/<Schema>.hash for folder-scoped variants).
  • Master and partials#/master.hash, #/Header.hash, #/Footer.hash.

Before — admin user sees code files mixed with data:

Customers/
  ├── .docly
  ├── index.hash         ← admin can edit and break the listing
  ├── style.css          ← admin can delete it
  ├── Acme Corp.docly
  ├── Globex.docly
  └── Initech.docly

After — admin user sees only data:

Customers/
  ├── .docly
  ├── Acme Corp.docly
  ├── Globex.docly
  └── Initech.docly

#/                       ← invisible to admin users
  ├── Folder/
  │   └── index.hash     ← inherited by every subfolder
  └── Root/
      └── style.css      ← reachable as /style.css

The admin user opening Customers/ now sees three documents, all editable, all theirs. The template that renders the listing and the stylesheet that styles it both live somewhere they can't reach — which is exactly where they belong.

See The "Root" folder and The "Folder" folder for the full resolution rules.