refactor table of contents+ticket line view

The big change is that we're going to generate the table of contents in the browser with JavaScript manipulating the browser's dom parsing. At the same time we'd like to address most or all of these:

There may be others, check:

Development Tickets (by status)

 

Ideas

 

Documentation Tickets

 

Support Tickets

 

now starting to think this might be possible to do as chunks.  tagging 1.5.3 but just want to have a look.


(would restore old functionality, with an eye toward these other issues)

  --Ethan McCutchen.....Fri Feb 18 10:16:39 -0800 2011

 


 

The idea I had for getting refactor table of contents working in wagn 1.5+3 would mean moving the handling into lower level rendering, which I'm now realizing would make it hard to have any rendered content view (including content and naked) without the toc.

 

The takeaway is that we might want to give toc some more talking over.

--Ethan (from make toc work on Related subtabs)


You want to talk about toc?

  --John Abbe.....Mon Feb 28 10:13:26 -0800 2011


We'd offer some flexibility if we class ToC links to anchors based on whether they're from the root card of an inclusion.

  --John Abbe.....Tue Mar 22 21:43:11 -0700 2011


We've been asked how to display the TOC bullet points as numbers instead of Roman Numerals.

  --John Abbe.....Tue Mar 22 21:58:02 -0700 2011


What about merging these thoughts and features with things like 'fold' processing. Seems to me that the TOC is just another section/variation of the card's content. I think I would make it a separate view (view=toc), then the Javascript can fetch and display it how it wants. If the style is just nested divs with classes indicating how deeply nested a given div is, lots could be done with styling alone.

--Gerry Gleason.....2013-06-08 21:40:20 +0000

Then also use the show/hide mechanism too?

--Gerry Gleason.....2013-06-08 21:40:59 +0000

+1 re show/hide

--John Abbe.....2013-06-09 03:19:36 +0000

I like the idea of its being a view. Though one thing I figured we should do with this refactor is move most of the HTML parsing into javascript. It's not "just another view" if the ruby suddenly has to get smart about HTML. Because for this to work we need sophisticated parsing. We don't want header tags inside closed view.

--Ethan McCutchen.....2013-06-10 03:02:45 +0000