New Navigation

Well, I'm disgusted with the navigation system. It seems klunky and brittle, mapping categories to controllers. So lets tear it down and build a better system.

What's needed?

1) A programmatic convention to map categories to controllers.

So that means...

- a category name maps directly to a controller name
- a default action

2) A programmatic convention to map categories to models.

So that means...

- a category name maps directly to a table name or pluralized model name
- a default action

3) A way to override these default mechanisms

So that means...

- a way to specify the model or controller

For example, there are currently the following top-level categories:
-- Public
----- Rentals
----- Expendables
----- Services
----- Specials
----- Resources
----- About
-- Admin
----- Schedule
----- Reports
----- Accounting
----- Public
----- Super User
---------
-- User
----- Accounts
----- Profile
----- Productions
----- Public

The "model classnames" will identify resource controllers.

These are the top navigation items that would appear along the top of the content area. To the side would reside all the categories under the current top item. So if the "Rentals" item is current, then the side would be all the next-level equipment categories for Rentals. If someone clicked an equipment category, all the next-level equipment categories would be exposed for that equipment category and so on.

4) Categories may not be constrained to the top navigation menu or the side menu.

So that means...

- navigation categories can appear anywhere on the page.
- it should be easy to know which categories are in the selected chain
- the system should keep track of the selected chain

For example, Public > Rentals > Cameras would present several groupings of rental equipment, each with a category heading. The heading could have a link that would make that category the current category, showing just the rental equipment for that category, maybe with expanded listings and images.

5) Need a way to persist the category between pages and requests so that users can always see where they are in the navigation of the site. This means even when using RESTful routes for editing DB items.

So that means...

- for non-javascript browsers, passing the navigation in the url
- for javascript, use AJAX to replace DOM containers

==================

So after looking at the current system and what I need, here's what I'll implement this time around:

- create a generic route that looks something like
:controller/:navigation/:action/:permalink
which will allow the navigation to persist between pages and allow individual objects be shown on the page. This is mainly for the public pages,

- create a helper method to generate urls as needed,

- provide a way for the category to specify/override the controller,

- allow a category's child to be the default category for its parent and have that child's url as the parent's link url,

- and for forms, embed the origination url as either the "return to" url or the "origination" url, so that navigation information can be passed to resource controllers and, additionally, the user redirected back to the originating page.


UPDATE (April 27, 2008):

Well, that worked okay but still does not do the trick. The URLs are messy looking, with lots of redundancy and, just, well messy.

So here's another go at it:

Use the :controller/:action pattern and have the :action identify the category. If :action doesn't identify it or is nil, the :controller will identify the category. Finally, the PublicController will be the default.

The controller, if it's not a resource controller, will implement a method_missing method to catch actions that it doesn't define specifically (especially categories of equipment).

I'll let you know how it goes. :)


UPDATE (May 2, 2008):

That worked a little better. It helped to understand that I was fighting a structure war. The category navigation scheme wasn't working so I changed the navigation. But then the categories were not falling neatly into the navigation scheme. Now a change to the categories should make the system work.

For instance: the website, to the public, is composed of three sections: ABOUT, RENTALS AND SUPPLIES, and HELP. The root of the site is a large graphic with those three sections.

The website, to the employees, is those three plus ADMIN.

The super_user adds its own controller.

Each section is a tree. The root defines the controller but any child in the tree can also define a controller.

The generic path is:

:controller/:action/:object_permalink

Often times, the action is the category permalink. But this action can have embedded directives, like order_by and filter_by. So for instance:

stuff/minidv-cameras_filter-by-vendor_sony_order-by-name

If the controller is a resource, that resource controller kicks in and action is dropped (not added to path, to allow the resource to the define and respond to the path.

Categories seem like the right way to go. Pages will either be dynamic or CMS driven. The CMS pages include rental policy, location, hours, staff, etc.

It looks like what can work in the end is a multi-tree structure of categories, if the categories are structured to fit within this forest.