Thanks for the info. The unmanageable part is probably more to do with the database design which, I feel, does not allow very much flexibility. The confusing aspect of the whole thing is when the end-user gets hold of it and tries to add a page it is quite complicated for them as to where the page will be located in the menu system.

They can add a page that will either become the first page when a category is chosen or the first page in a menu, submenu or page underneath a submenu.

Below is the db tables that I am currently using:

circuit (hold the main categories - top level) contains amongst other fields:
contentid
menus (holds the main menus of each category) also contains amongst other fields:
contentid
submenus (hold sub-sections of the menus)
contentid
content (holds the content)
submenuid (which may be 0 if the contentid is linked directly to one of the above tables.)

Ideally I want a system that doesn't care how many levels there are in the system.

Does anyone have any example db schema I could take a look at.

I really want to make the current system simpler without sacrificing the functionality.

Cheers

Dave



At 12:50 1/14/2003 +0000, you wrote:
Dave,

> I am about to begin the early stages of a new site management
> system which
> will supersede our current CMS.  One of the major problems we
> have found is
> that the product is very hard to port to different sites
> because of the
> menu systems that each site uses is slightly different and
> our old system
> generates menus, submenus and pages dynamically based upon
> the content
> which requires me to re-write the navigation code base for
> each project.
>
> How do most CMSs handle the menu/navigation of dynamically
> generated content?

Having had a quick look at a few of your sites, I'd say that they are pretty
much what most of us would do.  In what way are they unmanageable?  As far
as I can see, they are very manageable, assuming that you store each page
(and therefore menu) in a database properly, I don't see any problem.

The difficult part of all of that is getting the database right (as with
most things really).

The only thing I would say is if you can store your "main" navigation in a
common format (for example XML) than you would be able to create an settings
file or something like that for each site, meaning that you wouldn't have to
mess around with the navigation code...

Each site will need some customisation and settings files are very helpful
with that.

> Any suggestions or helpful pointers would be most appreciated.
>
> If you want to see an example of a site running our system
> then take a look
> at www.abingdon.org.uk.
> The main categories at the top are the only fixed navigation.
>  All the
> other menus are generated based on the content in the db.
>
> Is there a better way to do this?

Yes there is (see above), BUT is it really worth doing?  Unless you are
going to package the product up is it worth investing the time and energy
into something much more complex?

I dunno if I'm answering the question properly, but that's just my two
pence.

Paul




--
** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For human help, e-mail: [EMAIL PROTECTED]

============================================
Phipps CF Development
Oxford, Oxfordshire.
Telephone: +44(0)7718 896696
http://www.phipps-cf.co.uk
============================================


--
** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For human help, e-mail: [EMAIL PROTECTED]

Reply via email to