Enable sorting in TitleIndex macro

[carlos.lopezperez@…]

The goal is to be allowed to order the result of the macro TitleIndex in the same way that RepositoryIndex with the addition of the parameters order and desc.

• Order possible values: [title|date]
• Desc possible values: [0|1], same repositoryindex.

For example:

[[TitleIndex(order=title, desc=1)]]

[benjamin.a.lau@…]

patch to reverse the TitleIndex list.

[benjamin.a.lau@…]

I guess what I did is kind of related to this… I wanted to "reverse" the results of the TitleIndex so I added a "reverse" option to do this. I guess this is a very limited version of what this ticket is proposing.

Usage:

[[TitleIndex(reverse=True)]]

[noleti@…]

I used Benjamin's patch and it basically works, but subgroups will be in wrong order if grouping is enabled. I was able to get my intended ordering to work by adding some additional sort() changes similar to Benjamin's.

[tkempitiya@…]

added two parameters order(title|date) and desc(0|1) to the TitleIndex macro. Used sql query to get date information.

[Jun Omae]

The patch seems title sorts by case-insensitive and that is incompatible behavior. We should sort by case-sensitive since WikiPageName is case-sensitive.

[tkempitiya@…]

Thanks, I removed the case insensitivity for title sorting

[Peter Suter]

Thanks for the patch!

The _description string should be updated to mention these new parameters.

Should WikiSystem.get_pages() maybe query and cache the time as well? But then the cache would get invalidated much more often.

[tkempitiya@…]

Thanks, I updated the description. About the WikiSystem I don't think it cache the time. Is there any other way to get time more efficiently

[Ryan J Ollos]

About the WikiSystem I don't think it cache the time. Is there any other way to get time more efficiently?

Another cached property could be added to the WikiSystem class, perhaps named pages_modtime: tags/trac-1.1.6/trac/wiki/api.py@:288-292#L254​. Or should we aim to generalize and add a pages_metadata cached property that returns all of the page metadata (basically, everything except the text)?

In addition to caching the modtime, the aim is to keep SQL out of macros.py. Ideally the SQL would be in model.py, but for now it's fine to extend the existing functions in api.py.

An order_by parameter could then be added to WikiSystem.get_pages.

I'm probably overlooking something, but for what case is p a tuple in index_order?

Unit tests can be added in tags/trac-1.1.6/trac/wiki/tests/macros.py​.

Lines need to wrap at 79 chars, per TracDev/CodingStyle.

[Peter Suter]

For some reason I thought env.get_known_users(last_visit=True) (as proposed in comment:8:ticket:10736) was now allowed, and WikiSystem.get_pages(time=True) would be a logical continuation of that. (But now I see that has not happened.)

A general page metadata solution seems desirable.

An order_by parameter looks clean, but might not allow sorting format=group or format=hierarchy by time.

In those format cases p is a tuple (path_elements, page_name). See tree_group() and tree_hierarchy().

[anonymous]

We could really use a smart "natural" sort mode where in wiki pages like wiki:Meeting/2015/Aug/10 etc. the Aug part is detected as a month abbreviation and sorted "correctly" between similar page names with Jul and Sep.

Sorry, if this is too specific / out-of-scope. A plugin would be fine, but macros don't offer any extension points.

[anonymous]

Replying to Ryan J Ollos:

Or should we aim to generalize and add a pages_metadata cached property that returns all of the page metadata (basically, everything except the text)?

Maybe even the text or at least the extracted page title for #10523.

[Ryan J Ollos]

Replying to anonymous:

Maybe even the text or at least the extracted page title for #10523.

I was concerned about execution speed and memory usage when including text in the query, but I haven't done any profiling. Maybe it wouldn't be significant and we can return a generator to minimize memory usage.

[tkempitiya@…]

added pages_metadata to get date of wiki pages and added new test cases

[Ryan J Ollos]

Thanks for revising the patch. One suggestion - use a ​namedtuple in get_pages_metadata.

[Jun Omae]

Quick review:

• The pages_metadata is incorrect. The latest version of each page should be cached. Also, we shouldn't use costly DISTINCT with all fields in the general cases.
• Using both pages_metadata and WikiSystem.get_pages() is race. The get_pages() uses pages decorated @cached. I think we should use only pages_metadata.
• We should invalidate the cache of pages_metadata when a page is saved, renamed and deleted. See del WikiSystem(self.env).pages in trac/wiki/model.py and trac/wiki/admin.py.
• UnboundLocalError when order=xxxxx parameter is passed.
• In the latest patch, uses of index_order for tree_group and tree_hierarchy are removed. Is that intentional?
• I don't think that if type(p) is tuple in index_order is elegant. How about t10323-index_order.diff​?
• More tests. That tests don't cover the added features.

[Jun Omae]

Replying to anonymous:

We could really use a smart "natural" sort mode where in wiki pages like wiki:Meeting/2015/Aug/10 etc. the Aug part is detected as a month abbreviation and sorted "correctly" between similar page names with Jul and Sep.

Sorry, if this is too specific / out-of-scope. A plugin would be fine, but macros don't offer any extension points.

-1 but please create a new ticket for that if you want the feature.

That feature isn't useful for non-English users. Also, the smartsort parameter naming is not smart. At least, I don't know what kind of sort is used by smartsort.

[Ryan J Ollos]

Unscheduling until comment:13 issues are addressed.

[Ryan J Ollos]

#12319 closed as a duplicate.

[hfrmobile]

vote +1 for "Enable sorting in TitleIndex macro"

[ilewismsl]

If you implement this enhancement, it would be useful to be able to specify that Trac should attempt to sort numerically if a page name ends with a number. Currently page names like Atl1 and Alt10 come before Alt9.

Following the description, perhaps the Order parameter could have a third option titlenumeric or similar.