Hello Itamar,
Sorry for the delay in answering your very interesting mail, but you
sent it right in the middle of my holidays...
On 8/21/2010 2:18 PM, Itamar O wrote:
Hi,
I am wondering what is the recommended method to manage "complex"
wiki-documents, and by "complex" I mean documents that are scattered
across multiple wiki-articles using WikiLinks.
To make it short: I'd like to see all of this happen, and this "program"
matches quite closely what I had myself in mind for the future of Trac's
wiki. It will probably take us a few more release to get there, but I
believe it's all possible to achieve.
I have users that are used to writing long specification & design
documents as Word documents, and have expressed interest in starting
to work in Trac-wiki instead.
As far as document management & versioning is concerned, I would like
to allow them to manage their wiki documents at-least as easily and
intuitively as file-based documents allow.
The main use-cases include:
- The ability to specify that a wiki-page is a part of a "document"
(ideas: page-hierarchy, wiki-properties?)
- Embedding some header / footer in all wiki-pages that "belong" to a
specific document with some metadata and a link to the "document root"
(ideas: based on solution to previous bullet, inject custom template
with a plugin?)
- Allow management of *document*-metadata (as opposed to
*wiki-page*-metadata) in some convenient way (metadata includes:
organizational-reference, business classification, version info &
version history, authors, reviewers).
- Support document-versioning that is *at-least* as good as copying
"myDoc-v1.doc" to "myDoc-v2.doc" and updating the metadata
accordingly. I write "at-least as good" because it seems that the wiki
infrastructure should allow much better abilities, like automating the
version-tagging-process, possibly supporting constraints (chain of
review-approve), diffs between versions, showing a "jump to"
navigation bar between document versions (like in the source browser),
etc.
- When viewing a document that "was not released" show a "draft"
watermark.
- When trying to edit a "released version" of the document, warn the
user and suggest branching a new version.
- Allow automatic generation of document-wide table-of-contents and
document-map (like TracGuide) (ideas: if using page-hierarchy,
TOCMacro might be able to do it).
- Support document navigation based on flow (something like "next/prev
page", with "up" taken care by page-hierarchy).
- Enable "document-export" (for printing / archiving purposes) into
PDF / DOC, ideally supporting custom document templates that are
populated according to some business-logic (e.g. metadata, list of
figures, etc.)
- Allow cross-references between documents that are version-aware,
possibly allowing automated generation of "applicable documents" and
"this document is referenced by ...".
First, 0.13 will hopefully feature a rewrite of the wiki parser that
will make authoring content more "robust" (less quirks, more expressive
power). Some advanced operations like (batch) copy are also on my list.
I have also laid out a plan for supporting transclusion and other
powerful mechanisms inspired from MediaWiki (see
http://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedWikiFormatting#Transclusion)
which I believe will also provide some of the infrastructure support for
composing complex documents from individual pages. Finally, progress on
the GenericTrac model will bring the addition of wiki properties, as
well as the possibility for plugins to define new resources easily (e.g.
"documents"). In the same vein, a generalization of ticket workflow to
e.g. wiki workflow should also be possible, longer term.
The TracGuide is an example for such a document.
It contains a table-of-contents (not sure how it is generated),
and version-branches (e.g. 0.11/TracGuide)
(although I'm not sure whether this process is manual or automated -
Christian?),
but I listed many other use-cases that are not present in the
TracGuide example.
Well, the table of contents for the TracGuide is generated by a macro,
which contains a hard coded list of pages, and the rest of the
automation indeed relies on me ;-)
What I would like to hear from dedicated readers who made it to this
part (thanks! :-) ):
- Ideas how to implement some of the use-cases I described based on
existing Trac (0.12) features.
- Pointers to plugins that may assist.
- Suggestions on how to implement by writing a new plugin.
- Maybe additional use-cases from users with similar needs.
Sorry, for /that/ I can't help you much ;-)
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
