X-Git-Url: https://scripts.mit.edu/gitweb/www/ikiwiki.git/blobdiff_plain/bcb8b3c5c5e4ae893412edb59bda888bcbde8555..71555b595167abf77c71c1b4b8c26669d0b0130e:/doc/todo/preprocessor_directive_for_proposed_changes.mdwn diff --git a/doc/todo/preprocessor_directive_for_proposed_changes.mdwn b/doc/todo/preprocessor_directive_for_proposed_changes.mdwn index d38ca87f9..e73e6c09e 100644 --- a/doc/todo/preprocessor_directive_for_proposed_changes.mdwn +++ b/doc/todo/preprocessor_directive_for_proposed_changes.mdwn @@ -7,7 +7,7 @@ which can't be made through the web interface: Of course in these cases, you can add your request to a discussion page and wait for someone with the access/confidence to apply them. -Maybe this can be enhanced with a [[PreprocessorDirective]]: +Maybe this can be enhanced with a [[ikiwiki/PreprocessorDirective]]:
\[[suggest op=merge dstfile=trunk srcfile=branches/jk oldrev=1234 newrev=1342]] @@ -24,20 +24,37 @@ Index: IkiWiki/CGI.pm """]]-These would expand to a description of the changes to be effected, a toggleable diff -of them if appropriate, and of course an "apply theses changes" button. -Ultimately my planned [[review_mechanism]] would manage pages with such directives -by itself. +These would expand to a description of the changes, +and provide "apply theses changes", "preview changes", and maybe +"show diff" buttons. When those would be clicked, +an rcs_ function would be called to apply the changes in +the working copy, and depending on the request they would +be svn diff'ed or rendered and shown, and kept. +(all the affected pages would be inlined for the preview) + +Ultimately my planned [[review_mechanism]] would manage pages +with such directives by itself. + +Thinking about it, describing changes inside a directive rather +than as pages of their own is a bad remedy for the temporary +lack of web-based file upload in ikiwiki. + +Implementing this as new pages formats would be simpler, +and combined with inlining and file uploading it would be +at least as powerful. It would be easier to handle changes +automatically (for instance, moving the change pages once +they have been applied). There would still be associated +discussion pages in markdown. + +Regular pages could be used as change pages as well, +if they provide subpages in a format describing changes. +This would allow grouping and documenting changes. I'm still uncertain about many things, so please anyone feel free to comment. Specifically: - * What would an optimal syntax look like? - * Do I need to / should I define a new rcs_ function to handle such operations? - * Would it be acceptable for an ikiwiki module to use temporary file (ie. to calculate diffs)? - * Should the diff be calculated at page build time (which means the page should be rebuilt - whenever a target file changes), or should the CGI be used when someone requests it? - * Would it be possible to detect already applied changes (without extra state, that is), - and propose to "revert changes" in that case? + * Would it be possible to detect already applied changes + (without extra state, that is), and propose to "revert + changes" in that case? --[[JeremieKoenig]]