On Mon, Sep 13, 2010 at 12:25 PM, Christian Boos <[email protected]> wrote: > Hello, >
:o) > On 9/13/2010 5:20 PM, Olemis Lang wrote: >> On Sat, Sep 11, 2010 at 5:34 AM, Christian Boos<[email protected]> wrote: >>> On 8/21/2010 2:18 PM, Itamar O wrote: >>>> >>>> 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: >>>> >>> 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) >> >> I've read this page and all that's awesome !!! >> >> About compatibility with other wiki markups ... >> >> Q: >> - What's the idea ? Are you planning to release support >> for multiple markups or just incorporate useful and >> advanced features missing in Trac ? > > The second, incorporate useful and advanced features missing in Trac. ok [...] > Of course it's not possible nor desirable to support *all* possible markups, > if only because of the incompatibilities, ... or provide placeholders for extra syntax providers (e.g. similar to processors ...) > but when there's an unambiguous > and useful piece of syntax that "fits" in the rest of the puzzle, it can be > an useful addition. > +1 > However, as the new wiki parser for 0.13 will hopefully make it possible to > support more complex bits of syntax through the plugin system than what is > currently possible, I expect that we should be able to move some of the > advanced stuff in optional components. That way, the base syntax will remain > simple, on the level of Trac 0.11 even i.e. the creole compatibility could > become optional, I'm sure those who are from the "there should be one and > only way to do it" camp will be happy ;-) > +1 >> - What's the really advanced stuff ? wanna know ... >> ñam , ñam ... > > Well, for now that was the link you cited above. Is this transclusion thing > not enough advanced for your taste? ;-) I want more advanced stuff ... :P > Besides, Itamar proposed a detailed list of other advanced enhancements in > the first mail of this discussion, and I'll integrate those ideas one of > these days in the TracDev pages (though as I already said, this is more for > the longer term, 0.15 even). > ok, I just thought you had your own list of other advanced stuff ... >>> 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, >> >> Q: >> - what are wiki properties are exactly ? > > The equivalent of the ticket custom properties, but for wiki pages. > got it . This is really important (e.g. plugins like WikiPrint or DOC converters would be able to use these data in order to add custom properties to documents) . MOSS has tight integration with DOCs properties, I suppose that similar attachments properties using IFileProperties or something like that may be useful to implement similar properties for attachments, and files in general (e.g. files committed to VCS). >>> as well as the >>> possibility for plugins to define new resources easily (e.g. >>> "documents"). >> >> Q: >> - How would it look like ? > > No idea yet ;-) > > A document would be a structured aggregate of wiki pages. While this could > be done by building yet another wiki page, using a dedicated kind of > resource would make it possible to have a distinctive view and edit mode. > For example, we could even have two main viewing modes, single page mode and > multi-page mode, the second could look like a two panes TOC + content. The > edit mode could feature some convenient ways to organize the pages, etc. > ok ... I get the idea , I was just thinking of the *easily* part (i.e. the way to do it simpler ...) >>> In the same vein, a generalization of ticket workflow to e.g. wiki >>> workflow >>> should also be possible, longer term. >>> >> coooool !!!! ... however firstly tickets, next wiki pages, ... why not >> to think on resource workflows (i.e. if somebody creates a custom >> resource in plugin, then provide components or mechanisms to attach a >> workflow for them ...) ??? > > Well yes, the idea has been floating around for some time, especially for > milestone (planning, freezing, retiring, etc.) but currently the workflow is > quite closely tied to the inner working of the ticket module, so this will > likely be not trivial to generalize. > challenging ... but still useful ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- 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.
