| 2008-08-26 18:31:13 |
Andy Altepeter |
bug |
|
|
added bug |
| 2008-08-26 18:31:25 |
Andy Altepeter |
silva: statusexplanation |
|
|
|
| 2008-08-26 18:31:25 |
Andy Altepeter |
silva: milestone |
|
2.2 |
|
| 2008-09-06 18:53:14 |
Andy Altepeter |
silva: assignee |
|
aaltepet |
|
| 2008-09-13 19:32:39 |
Andy Altepeter |
silva: assignee |
aaltepet |
kitblake |
|
| 2008-09-13 19:32:39 |
Andy Altepeter |
silva: statusexplanation |
|
Should the table of contents element be converted into an external source? That would clean up the toolboxes a bit, although content with tocs would need to be upgraded. Kit, I think you've hinted in the past that these custom elements should eventually be converted into ES's. At this point, the only advantage to an autotoc tool is that it is slightly easier to use, being always present as a toolbox. But, converting to an ES would cleanup the kupu codebase, and would arguably be less work to implement. if this is a direction you want to head, I would recommend adding it as a core filesystem-based external source in the SilvaExternalSources product.
Otherwise, I can implement the autotoc features in kupu and the 'toc' edit widget. |
|
| 2008-11-06 08:53:39 |
Kit Blake |
silva: status |
New |
In Progress |
|
| 2008-11-06 08:53:39 |
Kit Blake |
silva: assignee |
kitblake |
todd-infrae |
|
| 2008-11-06 08:53:39 |
Kit Blake |
silva: statusexplanation |
Should the table of contents element be converted into an external source? That would clean up the toolboxes a bit, although content with tocs would need to be upgraded. Kit, I think you've hinted in the past that these custom elements should eventually be converted into ES's. At this point, the only advantage to an autotoc tool is that it is slightly easier to use, being always present as a toolbox. But, converting to an ES would cleanup the kupu codebase, and would arguably be less work to implement. if this is a direction you want to head, I would recommend adding it as a core filesystem-based external source in the SilvaExternalSources product.
Otherwise, I can implement the autotoc features in kupu and the 'toc' edit widget. |
Andy, the one thing that comes immediately to mind is we'll need an upgrader, at some point, to transform existing TOCs (inline or AutoTOCs) into the new code source. But maybe it's better to wait until the code source finalizes. Could be that fields change name or such.
I don't think we need any "code source to code source" transformers. There just aren't that many Multi-TOCs out there. Or if I'm wrong that should become a project. |
|
| 2008-11-10 04:04:15 |
Andy Altepeter |
bug |
|
|
added subscriber Kit Blake |
| 2008-11-18 07:16:13 |
Kit Blake |
silva: importance |
Undecided |
High |
|
| 2008-11-18 07:16:13 |
Kit Blake |
silva: statusexplanation |
Andy, the one thing that comes immediately to mind is we'll need an upgrader, at some point, to transform existing TOCs (inline or AutoTOCs) into the new code source. But maybe it's better to wait until the code source finalizes. Could be that fields change name or such.
I don't think we need any "code source to code source" transformers. There just aren't that many Multi-TOCs out there. Or if I'm wrong that should become a project. |
Andy, where's the note in developer_changes.txt? Maybe I'm not svn upped properly. |
|
| 2008-11-21 02:30:56 |
Andy Altepeter |
silva: status |
In Progress |
Fix Committed |
|
| 2008-11-21 02:30:56 |
Andy Altepeter |
silva: statusexplanation |
Andy, where's the note in developer_changes.txt? Maybe I'm not svn upped properly. |
I added a note to developer_changes.txt and UPGRADE.txt |
|
| 2009-04-17 02:42:54 |
Andy Altepeter |
silva: status |
Fix Committed |
Fix Released |
|
