@agentrickard,
I have developed Node Menu in order to achieve the following use case:
1. I need a cool Menu Page, with a nice Icon and long description for every item
2. Items can link to itself, other nodes or other sites
3. I need a block version of that menu, without icons and description (just a normal Drupal menu)
4. System should care about user permissions, listing only the items user is granted to view
In other works, the power of views+content(cck)+imagefield+menu+menu_access
So, what node_menu.module does is to create associations between menu links (mlid) and nodes (see: menu_core-vs-node_menu.jpg). It also keeps sync between node's title & body and menu's title & description, in order to build the Menu Page with no theming. That is why node_menu.module exists, otherwise link.module can do the magic.
That said, I would like to collaborate with you in order to interchange functionalities. In example, I can move the views integration to Menu Node Views and, to use Menu Node API with Node Menu.
Thanks in Advance,
Blessings!
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | menu_node_views.zip | 7.03 KB | agentrickard |
| menu_core-vs-node_menu.jpg | 56.01 KB | develcuy |
Comments
Comment #1
agentrickardLet's call this a task.
What Menu Node API does is abstract all the storage functions -- and it responds to changes from the Menu side or the Node side. It also calls its own internal hook functions, which will let modules act on changes to the menu system.
See section 5 of the README.txt
But Node Menu still needs its own hook_form_alter() implementations, I believe.
Comment #2
joachim commentedHi.
Just seen both of these modules for the first time tonight chatting on IRC.
I wrote this a few months ago: http://drupal.org/project/views_menu_nodes
which answers pretty much the same use cases as develCuy's module, though goes about things a different way.
My module doesn't store any data, and is really just declares the D5 menu table to views module, with a bit of ugly regexping to get a nid from "node/nid" paths.
I was still scratching my head over how to upgrade it to D6!
So we should definitely work together, possibly even merge develCuy's and mine.
develCuy, can you explain what the extra form you're adding to nodes does? It seems like both our modules have one goal that's the same, but I'm not sure I follow what the other stuff does.
Comment #3
develcuy commented@joachim awesome! I'm quite interesting on merging!
The extra fieldset node_menu.module adds to node form works the same as core fieldset + custom path. So, you can edit item weight and select its parent. Description field is not included since Body works as Description. Perhaps moving those fields out of the fieldset will help realize the idea of a node merged with a menu item.
Blessings!
Comment #4
agentrickardI was stuck in the airport yesterday (without internet access), and wrote the attached.
We should merge this with Joachim's code.
The question is: What module is the release?
Comment #5
joachim commentedWell, given the API module is menu_node, it makes more sense to add suffixes to the name and have dependent modules be called menu_node_foo. So menu_node_views would be the best name for the views support module.
However, develCuy's module does stuff beyond the basics of providing views support -- I'd prefer to have a lean module that just supplied views support on top of the API module.
This is the bit I don't get and I've not had time to poke at the code:
> The extra fieldset node_menu.module adds to node form works the same as core fieldset + custom path. So, you can edit item weight and select its parent.
So how is that different to the core field?
Comment #6
agentrickardI don't know.
When I get a chance, I will open a project for Menu Node Views.
Anyone want CVS access?
Comment #7
agentrickardhttp://drupal.org/project/menu_node_views
Let's collaborate over there.