-
Notifications
You must be signed in to change notification settings - Fork 3
Feature/ba 2656 be setup routing for wagtail and base app pages #313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: epic/wagtail-graphql
Are you sure you want to change the base?
Feature/ba 2656 be setup routing for wagtail and base app pages #313
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
Acceptance Criteria
Investigate Solution for Router
Routing Behavior
Given a URL path is requested that matches both a Wagtail page and a BaseApp page,
when the routing logic is executed,
then the Wagtail page should be served.
Given a URL path is requested that matches only a Wagtail page,
when the routing logic is executed,
then the Wagtail page should be served.
Given a URL path is requested that matches only a BaseApp page,
when the routing logic is executed,
then the BaseApp page should be served.
Given a URL path is requested that matches neither Wagtail nor BaseApp pages,
when the routing logic is executed,
then a 404 response should be returned.
Given a Wagtail page is served via the unified router,
when metadata is rendered,
then it should use the existing BaseApp metadata structure.
URLPath Syncing
Given a Wagtail Page is created or updated,
when the operation completes successfully,
then a corresponding
URLPath
entry should be created or updated to match the new path.Given a Wagtail Page is created or updated,
when the
URLPath
cannot be synced due to a validation error or path conflict,then a clear and descriptive error message should be returned.
Given a Wagtail Page is deleted,
when the deletion is complete,
then its associated
URLPath
entry should also be deleted.URLPath Query Support
Given a valid
URLPath
exists for a Wagtail Page,when querying URL-based data in GraphQL,
then the correct path, slug, and page details should be returned.
Given a Wagtail Page is saved with a conflicting or invalid path,
when the system validates the path,
then a meaningful and specific error should be returned.
Backward Compatibility
Given existing functionality relies on
baseapp-pages.PageInterface
,when
wagtail-grapple
andWagtailPageInterface
are introduced,then all existing
baseapp-pages
features should continue to work without regression.Given no updates are made to the legacy REST layer,
when endpoints using
baseapp-pages
are called,then they should continue to behave as previously defined.
Documentation and Developer Guidance- Given the integration betweenbaseapp-pages
and Wagtail has changed,when a developer reads internal documentation,
then it should clearly explain how
WagtailPageInterface
reuses logic fromPageInterface
.- Given a developer reviews README files or code comments,when examining the GraphQL metadata or URL path behavior,
then the updated interface usage should be clearly documented and easy to follow.
Notes
SPIKE Deliverable
Make use of
baseapp.pages.URLPath
to integrate all URLs in the system and also to allow for Wagtail pages to live in the root like:domain.com/about
.Approvd:
https://app.approvd.io/silverlogic/BA/stories/36399
Setup
Demo
https://www.loom.com/share/7b468c6cbc0b4be4b778d7b63c69bca2
PRs