Some pages in a website have a specific purpose while they could otherwise use the generic Page model. By introducing a mechanism for these specific purpose pages to use the generic Page model, we can prevent having to introduce and maintain specific models for each. Examples of these pages:
- Home page: identical to generic page, except that it is required, unique, and has no slug.
- Search page: identical to generic page, except that it is required, unique, and is server-rendered.
- Input error page (400): identical to generic page, except that it is required, unique, has no slug, is possibly server-rendered (with a specific error message), and should not be indexed.
- Not found page (404): identical to generic page, except that it is required, unique, has no slug, is possibly server-rendered, and should not be indexed.
- Server error page (50x): identical to generic page, except that it is required, unique, has no slug, is possibly server-rendered, and should not be indexed.
- Contact page: currently not in scope, but typically a generic page that is specifically linked to from different places like the main menu.
I see two possible mechanisms to use generic Page model pages for these specific purpose pages:
- Use a
key field on the Page model: this would be an optional unique field where editors can select from pre-defined keys (home, search, etc). Benefit is that it's a small change and can be a generic solution (record IDs are a system reference, slugs are url reference, keys are a developer reference). Disadvantage is that it's hard to ensure each special purpose page exists (editors could delete them). And if we offer multiple models there's no built-in way to keep keys unique across models.
- Link special pages from the
app model: we could add a section for "Special pages" with required links for each specific purpose page. Benefits are that there's a clear place, and that we can enforce that each page is required and unique. The app model is also written to disk in a prep script, so it's easy for parts of the codebase to synchronously access it. For example for getting the search path needed in the main menu link and opensearch.xml endpoint.
Some pages in a website have a specific purpose while they could otherwise use the generic Page model. By introducing a mechanism for these specific purpose pages to use the generic Page model, we can prevent having to introduce and maintain specific models for each. Examples of these pages:
I see two possible mechanisms to use generic Page model pages for these specific purpose pages:
keyfield on the Page model: this would be an optional unique field where editors can select from pre-defined keys (home,search, etc). Benefit is that it's a small change and can be a generic solution (record IDs are a system reference, slugs are url reference, keys are a developer reference). Disadvantage is that it's hard to ensure each special purpose page exists (editors could delete them). And if we offer multiple models there's no built-in way to keep keys unique across models.appmodel: we could add a section for "Special pages" with required links for each specific purpose page. Benefits are that there's a clear place, and that we can enforce that each page is required and unique. Theappmodel is also written to disk in aprepscript, so it's easy for parts of the codebase to synchronously access it. For example for getting the search path needed in the main menu link andopensearch.xmlendpoint.