Add `Navigation` model and plugins for dynamic menus

[markfinger]

re #48

@cogat I've rigged up everything except for the 'selected' state detection. I'll pick it back up on Monday, but figured you might want some input on a couple of things:

• On Tai's suggestion, I've added it to icekit.contrib.navigation.
• The nav app defaults to deactivated. icekit/contrib/navigation/README.md contains the minimal settings changes necessary to activate it (installed apps + fluent plugin conf).

Regarding the detection of an item's selected state:

• strict equality (path vs plugin url) is easy
• startswith checks should make it fairly easy to handle nested items. That being said, we're likely to end up with multiple items that intersect and have the selected state. Eg: two menu items /about/ and /about/donate/ would both be selected when /about/donate/thanks is the current path. I don't think there's an easy way around this, at least, without massively complicating the UI and relying on non-technical users to enter regexes. Also, pulling regexes out of the DB and executing them at runtime seems like it has the potential to be an issue (regardless of the superuser permission checks).

We might need to just accept that there will be edge-cases we can't predict and deal with them when they emerge. If so, I could try adding an escape hatch - eg: an optional setting pointing to a callable that takes the current path, a list of navigation items, and the default determination of the selected state for each item. It could return the selected states manipulated to whatever was appropriate for the system.

[coveralls]

Coverage decreased (-0.6%) to 73.103% when pulling 86d55e165864e5160437629f3d46117a7985eb7d on feature/48-alter-the-nav-model into 4435af556fce081c7eadec72a0754b3bdbf022e1 on develop.

[cogat]

Can we activate it by default, please? I think it's something we'll use in every project, and would like to backport to maintained projects. And if it's used in every project, should it be a contrib?

I don't think it should do anything without a template tag to render navs, and that template tag shouldn't do anything if there's no navs defined.

I think a method on the plugin class that returns a match based on a request should work. By default, a startswith query should work. You could get the most precise one by looking at the length of the match maybe.

I think a NavItem.objects.filter(match__iregex=request.path) shouldn't be too outrageous as a fallback if we couldn't find any 'startswith' matches - it's executed natively by postgres.

[coveralls]

Coverage increased (+0.2%) to 73.947% when pulling 7a2a959567f5e06d61f7e8140b4beb9b73daa94b on feature/48-alter-the-nav-model into 23f5fffcf8b70afc8fec28295b1562000a86d85c on develop.

[coveralls]

Coverage increased (+0.2%) to 73.947% when pulling 7a2a959567f5e06d61f7e8140b4beb9b73daa94b on feature/48-alter-the-nav-model into 23f5fffcf8b70afc8fec28295b1562000a86d85c on develop.

[coveralls]

Coverage increased (+0.3%) to 73.994% when pulling b974aeac8dc051c1deffcc5a37c1c34872f7022f on feature/48-alter-the-nav-model into 23f5fffcf8b70afc8fec28295b1562000a86d85c on develop.

[markfinger]

@cogat can you take a look and merge this in, if ok?

[coveralls]

Coverage increased (+0.3%) to 74.016% when pulling f0d70171cfc7d2c0e54ed52de4c949384bde8d52 on feature/48-alter-the-nav-model into 23f5fffcf8b70afc8fec28295b1562000a86d85c on develop.

[markfinger]

Thanks for the feedback, Greg

[cogat]

No probs. Thanks for the neat solution!