tigefa4u projects Trac

Timeline refatoring: `changeset_collapse_events` now defaults to `false`.

Fix range order and log link which are generated when this feature is activated.

Timeline refactoring: clean-up the API changes that were introduced during 0.11dev.

The main idea of the original refactoring has been kept: don't render the events directly when generating them, but defer this last step when the event is actually processed within the template.

But instead of requiring a intermediate `TimelineEvent` object, we now rely on a `render_timeline_event` method of the `ITimelineEventProvider` to do the job. The event itself is still a tuple, but of different arity than the one of 0.10, so that we can easily make the difference and keep backward compatibility. The new tuple enable the components to add an arbitrary amount of "private" data to the tuple, for the rendering needs

timeline-refactoring: start new branch for cleaning-up the trac.timeline API changes that occurred during 0.11dev

Merged the [source:sandbox/context-refactoring@... context-refactoring] branch into trunk.

context-refactoring: merging [6135], [6136] and [6137] from trunk

Expand the range of valid InterTrac links by being less strict when interpreting the links on the remote side:
* Use `trac:wiki` or `[trac:wiki]` for linking to the Wiki module
* Use `[trac:]` for linking to the toplevel (#4314)
(replace `trac` by any valid intertrac prefix)

Fixes #5968

Make the error.html template more useful when Javascript is not enabled.

The default view is the plain text view, and only when Javascript is available does the interactive view and the toggle button get shown.

Follow-up to r6126: finally understood what that `del req.chrome` was good for...

This was needed when an error occurs during the rendering of a template.

Here's a summary of what happens:
1. render_template() is called normally, the data is prepared and the chrome data is filled with the initial values obtained from the req callback for chrome, augmented by all calls to add_link, add_scripts etc.
2. right before the template stream is rendered, the req.chrome fields are reset to empty lists, which are also reachable by the `late_links` and `late_scripts` values
3. oops, an internal error while rendering
4. the `req.chrome['links']` are restored so that they can be used while rendering the error template
5. the error handling code does another round of render_template(), this time for the error.html template
6. now the interesting stuff happens if it's an internal error:
- the chrome data gets updated again with the req.chrome, which are at this point still the (empty) "late" lists, and because of that, the jquery.js script is not loaded and the nice interactive stack trace display ''doesn't work'' anymore
- before, when we had the `del req.chrome`, when the chrome data got updated by the req.chrome, this triggered ''another'' call to the req callback for "chrome", i.e. another Chrome.prepare_request, which would add among other things the jquery.js back...

So I think an "obvious" fix of this problem while still preserving the #5594 behavior is to restore the 'scripts' as well at point 4.

Of course, the management of the chrome data could probably be greatly simplified at some point after 0.11.

context-refactoring: merging changes from [6115:6128/trunk]

context-refactoring: fix "typo" (TICKET_VIEW instead of WIKI_VIEW)