Enable Generic Navigation Item Ordering

[ilias@…]

See #3692 for background

Custom Navigation Items can be created dynamically.

The ordering mechanism is hard-coded within chrome.py.

The ordering functionally could be refactored in order to avoid the necessity to hardcode the option within chrome.py.

Possible Implementation 1:

A generic options within a new "navigation" section.

chrome.py would read-in this section whlist creating dynamically the navigation-sort-information

Possible Implementation 2:

INavigationContributor gets a new method with an addition parameter "priority". The Menu items are aligned base on the priority setting.

[Christopher Lenz]

The order is not hardcoded, it can be configured in TracIni. What's defined in trac.web.chrome is just the default ordering for the builtin components.

Am I missing something?

[Christian Boos]

… probably #3692 and more specifically comment:ticket:3692:4

[ilias@…]

Replying to cmlenz:

Am I missing something?

I've missed to state that this is about "creating an new navigation category".

The ordering options are available (hardcoded in chrome.py) for the navigation category "mainnnav" and "metanav".

If a developer adds a new navigation category (e.g. projnav), an would like to have users choose ordering for this category, he must hardcode a new option into chrome.py.

This should be adressed to become more generic, thus trac becomes more flexible.

(this is not something with a priority to me, it just raise out of the ticket #3692)

[ilias@…]

I've implemented this as an component, see:

​http://dev.lazaridis.com/base/browser/infra/TracX/tracx/menus.py?rev=125#L30

This can be uses as a template to provide the direct implementation in the trac sources (I can do it, too. Just verify the naming etc.).

[ilias@…]

removed milestone assignment (to be assigned by a developer)

[osimons]

I'm not quite sure I get the purpose of this ticket, and following the closing comments on #3704 and general features of Trac 0.11 I'm not sure it is needed? If an external plugin adds a new nav to the rendered page, is it not up to that plugin to implement whatever ordering mechanism it sees fit?

Propose 'wontfix'.

[ilias@…]

Replying to osimons:

I'm not quite sure I get the purpose of this ticket, and following the closing comments on #3704

#3704 is not related with this ticketi, but #3692

and general features of Trac 0.11 I'm not sure it is needed? If an external plugin adds a new nav to the rendered page, is it not up to that plugin to implement whatever ordering mechanism it sees fit?

The ordering mechanism is already implemented.

This is about extending it to serve equally custome nav-trees.

Many things (like navigation orderin) is hardcoded within the trac-codebase, which makes elegant customization difficult.

Moving everything out to plugins in order to overcome hard-coded limitations is not the way to go (bad design).

Propose 'wontfix'.

You should not propuse "wontfix" just because you've not understood a ticket.

[osimons]

Replying to ilias@lazaridis.com:

You should not propuse "wontfix" just because you've not understood a ticket.

Enlighten me please. I still don't see the purpose of what remaining issues this ticket may have that is of importance with the tools available for 0.11. Is it…:

• ordering within a new nav element without plugin config, solved by making a new Trac config section and options???
• or is it ordering of the nav elements themselves, so that you for instance have <div> for projectnav, then ctxtnav, then metanav, then mainnav? Via config?
• something completely different?

Use cases with expected input and behaviour is badly needed by me…

[ilias@…]

I've explained everything within this ticket and the links. cboos has sheduled this for 0.12, where navigation will be hanled hopefully more generic.

You can even close this ticket, I've implemented it anyway within my system.

[Christian Boos]

For what is worth, cboos did only set a "consider" keyword for triggering further discussion on the topic, it's not exactly the same as if I had endorsed the feature…

But it's true that the INavigationContributor itself lends to reuse besides mainnav and metanav (the API doc says only "return a tuple in the form (category, name, text)"), whereas its usage in Chrome.prepare_request used to assume mainnav and metanav only. Now with #3692 fixed, there's no such assumption anymore, and extra categories can be used. The only problem is that their entries are left unsorted, and that's the topic of this ticket.

I think it's also somewhat related to this discussion in ​googlegroups:trac-dev:0f292c610d159261

If we would do that, would could pick config.get(category, 'order') as the default order (or even maybe config.get(category, 'order') or config.get('trac', category) for backward compatibility).

Hope this clarifies the issue!

[ilias@…]

Replying to cboos: …

If we would do that, would could pick config.get(category, 'order') as the default order (or even maybe config.get(category, 'order') or config.get('trac', category) for backward compatibility).

You need to use generic ini entries (as you don't know the names which are used by the customizing user, e.g. you don't know that I use "projnav")

	        config = self.config['navigation-order']           
	        navorders = {}
	        for category, value in config.options():
	            navorders[category] = config.getlist(category, sep=',')

​http://dev.lazaridis.com/base/browser/infra/TracX/tracx/menus.py?rev=125#L30

the trac.ini contains the this section:

	    [navigation-order]
	    projnav = guide, license, plans, services,
	    usernav = x, y, z
	    ... (define your own navigation_sets)  

mainnav and metanav can be included there, too (or at the usual place for backwards-compatibility).

hope this clarifies things a bit.

[osimons]

Replying to cboos:

Hope this clarifies the issue!

It certainly clarifies the 'what'. Thanks.

I haven't come to terms with the 'why' though. So basically I have a plugin that recommends using the already existing INavigationContributor interface to collect menu items from various other plugins. No problem with that, and that should work well for collecting.

Then my plugin needs to actually inject that menu into the page somehow. Thinking like a plugin developer, I would in my plugin:

• Declare a ListOption for project-specific ordering in my own section and with my own specified name. Or decide on custom fields-standard way of doing it. Or perhaps sort the entries by time or some other criteria without option. Perhaps I group them and then order groups and sublist. That all depends on what I'm actually doing.
• I then need to implement the IStreamFilter API, prepare the req.chrome['nav']['mynav'] items as I like, and inject my markup into the stream at the relevant location.

Everything is done inside the plugin, and why would I really need Trac to do anything to the items? I just don't see the value of adding complexity to Trac for this - a feature needed by very few, and done in a way that guarantees it will not suit everyone.

It was mentioned that "lack of options is bad design". It really isn't. It would be absolutely unusable and unmaintainable to try and be all things to all people only through options. For features such as custom navigation, Python + ITemplateStreamFilter is a much better alternative than any variety of Trac options.

[ilias@…]

Replying to osimons:

Replying to cboos:

Hope this clarifies the issue!

It certainly clarifies the 'what'. Thanks.

I haven't come to terms with the 'why' though.

…

Mr. Simons, the 'why' is very easy.

Most possibly, the initial developer has implemented the navigation system in a generic way (can be verified, looking at the initial sources of trac).

Then, a developer has added quick&dirty a sorting mechanism, exclusively for "mainnav/metanav". This solved a user need, but not in an generic way.

No one has detected this (or has detected it, by silently implemented a workaround within its own code base).

Then, another developer (me) has used the existent mechanisms (reuse) to implement a "projnav", hitting on a barrier #3692, which was solved.

The sorting mechanism is still specific for "mainnav/metanav", which breaks the initial generic design.

Essentially, this is a (design)defect, which can be simply solved using e.g. the mentioned method.

You, like any other person involved within this project, should honestly rate the level on which you operate on the trac project.

Levels: User, Power-User, Admin, Developer, Framework-Developer, Core-Developer.

I am (by my nature and experience, see ​resume) a Framework and Core Developer.

If you carefully see cboos contributions, you'll see that he's a Framework and Core Developer.

There is a tendency within Open Source Projects that every contributor likes to be involved in every decision taken.

This is of course possible, but it's an innovation killer. For sure it will lead to a bad design, simply because e.g. not everyone can rate the details of the implementation.

Users can (and should) rate the effects (e.g. "why isn't this handled in a unique way"), but they cannot rate the underlying technical details.

Even a developer (with no tendencies to produce reusable framwork code) will permanently reject the efforts of a framework-developer, e.g. because he does not see the need for this flexibility.

Basicly, this is what happens within trac, highly supported by the possibility to implement thins into plugins. A flexible design method which (when abused or overused) results in very fragmented difficult to maintain implementations.

This ticket is filed as an "enhancement", but strictly speaking, it's a defect. Nearly any Framework-Developer would confirm this.

Simple Implementation Rule: "Whenever possible, functionality should not be hardcoded"

[Game_Ender]

This is not exactly what is requested here, but it adds the ability of a plugin with a single INavigationContributor to keep the order of its supplied navigation items consistent (essentially the order they are returned, is the order they are displayed). See the ticket/patch/enhancement here: #7898.