It will depend on how the navigation links are being stored. I myself am using an adjacency list and will provide a brief overview how I made this possible in a generic CMF format.
I added a field to my navigation links table that stores a data query, Yes, you heard me right, a database query. Each time a menu is built all navigation links that are database queries are replaced my result of the query. The result of the query must always include two fields; id,label. The id being the unique id for rows returned by the query. The label being the title for the link.
The id than allows me to clone a dynamic link when it is moved or sorting is changed. So after I run the query to grab all my dynamic links any cloned links are removed from the result set, and the data is pushed to clone.
So in the end, the fields I added to my basic adjacency list are query,query_id, query_row_id. query_id and query_row_id being specific to links that have been moved or sorted that are generated dynamically from a query. The query_id referenced the query that the link was generated from and query_row_id the result set row unique id of returned items.
From there building the menu is just a matter of running the dynamic queries. Than injecting the result sets into the static menu links when no clones exist or pushing the query data to the clone, since it actually is a row in the database.
Here is a rough example:
id | parent_id | label | query | query_id | query_row_id
----------------------------------------------------------------------------------------------------------------------------------------------
1 | NULL | Home | NULL | NULL | NULL
2 | NULL | About Us | NULL | NULL | NULL
3 | NULL | Categories | NULL | NULL | NULL
4 | 3 | NULL | SELECT id,title label FROM cats | NULL | NULL
5 | NULL | Featured | NULL | NULL | NULL
6 | 5 | NULL | NULL | 4 | 10
Example Menu:
- Home
- About Us
- Categories
[list]
- Shirts
- Scarfs
- Pants
[/list]
- Featured
[list]
- Shorts
[/list]
My approach is a little more sophisticated than placing a query in the database, but I figured that would be the simplest way to explain it. In actuality query is really broken up into multiple columns that allow me to call a method in my data access layer, rather than storing a query directly in the database. This all makes it possible for me to mixin truly dynamic links and create real-time build outs of entities as links while also allowing sorting and moving of them.
Instead of query what I actually use is:
pkg (location of class)
method: (method to call)
args: (serialized array of arguments to pass to method)
So any navigation link with a pkg defined is a dynamic link mixin.