Re: [ANNOUNCE] navigation.module

On Sun, 29 Feb 2004 21:05:29 +0100 (CET)
Dries Buytaert <dries@xxxxxxxxxxxx> wrote:

[...]
 
> Works great.  It is flexible and intuitive.

Thanks.  :)

[...]

> Does your module supersede any of the existing modules in the
> contributions repository?

I don't honestly know -- my primary focus was being able to create CSS
tabs.  Being able to export the same menu structure in other formats was
simply a logical extension.  Reading about the other modules that do
similar things, it sounds like they all share quite a bit in common. 
Perhaps someone that uses/is familiar with the other similar modules can
comment.

Here's a list of modules that sound similar:
 - menus.module 
 - taxnav.module
 - taxonomy_html.module
 - taxonomy_jsmenu.module
 - taxonomy_menu.module

I have no intention of making javascript based menus.  I do see perhaps
merging mouse-over CSS menus.

>  If not, what needs to be done to supersede
> them?

The navigation.module will supersede my taxnav.module when finished -- all
that's left is to add an associate between menu items and taxonomy terms,
and to allow one to import a vocabulary.  I was hoping to have time to
implement this today, but it looks like I won't.  Next weekend, hopefully.

[...]

> While the navigation module is really nice in its current state, I'd
> start working towards better integration with core so that it could be
> used to manipulate the 'default navigation menu' and such that it could
> re-use the rendering code in menu.inc (or vice versa).  Quite a few
> people want to add, delete, rename or reorder menu items in the default
> navigation menu so integration seems to be key.

Quite honestly, I intentionally didn't work too closely with core as it
tends to change so quickly, and I don't have time to keep up.  The current
design is such that core can change substantially and I won't have to make
all that many changes to my module.

I did look through menu.inc when I was writing the code to export menus. 
It's very clean, but I believe it operates on the assumption that menus
are in a logical order.  Once you add the ability to add links to
arbitrary url's, this assumption is no longer valid.  That is, menu.inc
builds menus that look like:

one/
one/a
one/a/1
one/a/2
one/b
one/b/1
two
two/a
two/a/1
two/b

Thanks to aliasing, you can make all on-site links fit into this
structure.  But when you start permitting off-site links, it becomes less
logical to determine what tabs are active/collapsed/visible...

Perhaps rather than do what I've done, offsite url's could be given a
virtual path (much like an alias).

> As far as integration is concerned, I think we should focus on the 'user
> menus' (eg. 'recent posts', 'my account') and not on the 'administration
> menus'.  It simplifies the problem a LOT.

My current focus is getting something that meets my own personal needs
with 4.4.  That done, and once 4.4 is out the door, I'll look into closer
integration. 

Ideas are welcome.  And of course, patches are always appreciated...

Cheers,
 -Jeremy