Re: Storing menu structures in DB
Posted: Wed May 06, 2009 3:04 pm
I think I've come up with a good system that I am happy with. Just wanted to share in case anyone else was working through the same problems.
Thus, I have all my handlers (controller/view pairs) available for use.
When I want a specific controller loaded at a specific location, I pair a url and a handler_id.
Each page (and any other type of content that is reachable by a url) has a location, which automatically gives it a url and a handler.
Each page also has an optional linked menu item (link). If the menu item is linked, then editing the page title will automatically update the link's title.
Each link can also be attached to a location (using a link_location). If you move that location (change it's url) the link changes with it.
It's amazing how much simpler my queries got when I found the right balance of normalization. Right now I'm currently thinking about how to present content type/handler pairs to a user. They may use the same content, but the handler can present that content in any manner, along with extra functionality. Basically, a standard page that just lists its content, compared with a directory page that lists its content plus any child pages, are almost two different types of content to the user. I am tempted to completely hide the concept of handlers from users, so by picking a content type they are really picking a content type + handler.
Code: Select all
Pages
-----
id
title
location_id
link_id (can be null)
locations
---------
id
handler_id
url
handlers
--------
id
title
class_name
links
-----
id
title
url
link_locations
--------------
id
link_id
location_idWhen I want a specific controller loaded at a specific location, I pair a url and a handler_id.
Each page (and any other type of content that is reachable by a url) has a location, which automatically gives it a url and a handler.
Each page also has an optional linked menu item (link). If the menu item is linked, then editing the page title will automatically update the link's title.
Each link can also be attached to a location (using a link_location). If you move that location (change it's url) the link changes with it.
It's amazing how much simpler my queries got when I found the right balance of normalization. Right now I'm currently thinking about how to present content type/handler pairs to a user. They may use the same content, but the handler can present that content in any manner, along with extra functionality. Basically, a standard page that just lists its content, compared with a directory page that lists its content plus any child pages, are almost two different types of content to the user. I am tempted to completely hide the concept of handlers from users, so by picking a content type they are really picking a content type + handler.