doc/todo/wikiwyg/discussion.mdwn

   1 Very nice! There are some rough spots yes, but this looks exactly as I'd
   2 hoped it would, and seems close to being ready for merging.
   3
   4 A few observations, in approximate order of priority:
   5
   6 * What's the copyright and license of showdown? Please include that from
   7   the original zip file.
   8  * Done. Check licences folder
   9 * What happens if there are concurrent edits? The CGI.pm modification to
  10   save an edited wikiwyg part doesn't seem to check if the source file has
  11   changed in the meantime, so if the part has moved around, it might
  12   replace the wrong part on saving. I've not tested this.
  13  * When you click the edit button, the exact same protocol is used for saving.
  14    However when you double click to edit, this still is possibly an issue.
  15 * The stuff you have in destdir now really belongs in basewiki so it's
  16   copied over to any destdir.
  17  * Done.
  18 * Personally, I'm not sure if I need double-click to edit a section in my
  19   wiki, but I'd love it if the edit form in the cgi could use wikiwyg. Seems
  20   like both of these could be independent options. Doable, I'm sure?
  21  * Done.
  22 * It would be good to move as much as possible of the inlined javascript in
  23   wikiwyg.tmpl out to a separate .js file to save space in the rendered
  24   pages.
  25  * Done.
  26 * Both this plugin and the [[Gallery]] are turning out
  27   to need to add a bunch of pages to the basewiki. I wonder what would be a
  28   good way to do this, without bloating the basewiki when the plugins arn't
  29   used. Perhaps the underlaydir concept needs to be expanded so it's a set
  30   of directories, which plugins can add to. Perhaps you should work with
  31   arpitjain on this so both plugins can benefit. (The smiley plugin would
  32   also benefit from this..)
  33  * Done. All plugin files are now stored in a tarball. IkiWiki checks for
  34    <plugin name>.tar.gz in the basedir and if the plugin is being used, then
  35    it extracts the files to destdir. Currently IkiWiki does not render these
  36    files though (my plugin doesn't need them to be rendered). However it wouldn't
  37    be too hard to modify it to render them.
  38 * Is there any way of only loading enough of wikiwyg by default to catch
  39   the section double-clicks, and have it load the rest on the fly? I'm
  40   thinking about initial page load time when visiting a wikiwyg-using wiki
  41   for the first time. I count 230k or so of data that a browser downloads
  42   in that case..
  43  * Done-ish. I fixed it so that all of the javascript files(except for the main two)
  44    are loaded after the content is loaded. It is possible to make is so that
  45    the files are only loaded when you double click, however that is *a lot*
  46    more work, plus it will slow the load time for wikiwyg. But if you would
  47    prefer that the files only load after double clicking, I can do that. Also,
  48    I'm working on reducing the file sizes via [Javascript Compression][]. Theoretically,
  49    I can get the size down to about 70kb, I'm working out the kinks now.
  50
  51 --[[Joey]]
  52
  53 Oh, by the way, let me know if I forgot to tarball anything. --[[TaylorKillian]]
  54
  55 [Javascript Compression]: http://javascriptcompressor.com/
  56
  57 ---
  58
  59 Some more comments, on version 1.6. You seem to be making nice progress.
  60
  61 changes.diff:
  62
  63 * I don't really like the tarball approach. Doesn't feel like the right
  64   approach somehow. A list of underlay directories feels to me like a
  65   better approach. One reason is that it's more general than a tarball tied
  66   to a given plugin. A list of underlay directories could also be used to
  67   prefer a translated underlay, and use the english version of untranslated
  68   pages, for example.
  69 * When is the WIKIWYG variable in misc.tmpl used?
  70 * I wish there were a good way to move the code to handle saving a part of
  71   a page into the plugin. But there doesn't seem to be one that's any
  72   cleaner than keeping the code where it is. So I'll probably just apply
  73   that hunk.
  74 * Your patch exports run_hooks, but I don't see the plugin using that.
  75 * I don't know about exporting pagetitle. So far, only the inline plugin
  76   needs to use that function, I generally only export things after it's
  77   clear a lot of plugins will need them.
  78
  79 wikiwyg.tar.gz
  80
  81 * Would it be possible to provide a diff between wikiwyg upstream and any
  82   modifications you made to its files? I'm not sure which version you used,
  83   so I'm seeing changes in diffing that I'm unsure if you made..
  84 * If the files aren't modified, would it be better for users to get them
  85   from the wikiwgy upstream, instead of including them in the plugin? (If so,
  86   they'd go in their own Debian package..)
  87
  88 misc:
  89
  90 * What are your thoughts on handling plugins? Just make preview do a
  91   server-side callback?
  92 * How do I configure it to only support whole-page editing with wikiwyg and
  93   not insert the javascript into html pages?
  94 * When editing a whole page with wikiwyg, I think it would be good to keep
  95   the save, preview, cancel buttons at the bottom like they are in a
  96   regular page edit. Also the comments box. Kind of a least suprise thing, so that enabling
  97   wikiwyg for whole-page editing basically just changes how the edit box
  98   behaves and keeps the rest of the behavior the same. And I think the preview
  99   button should show a preview rendered server-side, like with a regular edit,
 100   since such a preview is able to support all plugins.
 101
 102 Everything else looks fine and ready for merging. If, that is, you think
 103 I should include the plugin with all of its java code in ikiwiki. Thoughts?
 104
 105 --[[Joey]]