feat: expand EasyCode software factory workflows
This commit is contained in:
@@ -0,0 +1,37 @@
|
||||
# Legacy Menu Code Navigation Design
|
||||
|
||||
## Problem
|
||||
|
||||
Legacy frontend page designs may store a business menu code such as
|
||||
`announcements` in `menu_code` while the page code is
|
||||
`announcement_list_page`. These records do not declare a navigation level or
|
||||
parent menu.
|
||||
|
||||
The current generator treats every differing `menu_code` as a parent menu
|
||||
code. It therefore renders an artificial directory named `announcements`
|
||||
instead of the page's display name.
|
||||
|
||||
## Design
|
||||
|
||||
Menu hierarchy must be driven only by explicit navigation metadata:
|
||||
|
||||
- A page is secondary when `navigation.menuLevel` is `secondary`.
|
||||
- A page is secondary when `navigation.parentMenuCode` is present.
|
||||
- Otherwise the page is a primary menu, even when `menu_code` differs from
|
||||
`page_code`.
|
||||
|
||||
The existing `menu_code` remains the primary group's stable key. Its display
|
||||
label continues to come from `navigation.menuName`, then `page_name`, then
|
||||
`page_code`.
|
||||
|
||||
## Compatibility
|
||||
|
||||
Explicit directory and secondary-menu configurations are unchanged. No
|
||||
database migration is required.
|
||||
|
||||
## Verification
|
||||
|
||||
Add a generator regression test using a page whose `menu_code` differs from
|
||||
its `page_code` and whose layout has no navigation hierarchy metadata. The
|
||||
rendered application must contain one clickable primary menu using the page
|
||||
name and must not contain an artificial directory using the menu code.
|
||||
Reference in New Issue
Block a user