Tags:
create new tag
, view all tags
Editing in a browser's textarea is no fun. How about downloading the text to your favorite local editor and uploading it back up again? Besides being more convenient while editing, the turnaround time could be faster.

Ideas

  1. The download part is rather trivial: send down the pages text, with proper spacing;
    • I'm using that now, then paste back from the editor into edit pages textarea
  2. Do not send down form fields; it is a form, because you want to enforce values - you can't in the editor
  3. For upload, change the edit page - instead of textarea, have an upload button like the attach page; handle the form stuff there
  4. Use this as a primitive ReadWriteOfflineWiki
    1. download web in one go
    2. edit locally
    3. upload touched files manually

Problems:

  1. How to connect the upload dialog and your editor session? Filename is a bit clunky:
    1. download this to c:\temp\DownUploadForEdit
    2. hit upload
    3. manually select c:\temp\DownUploadForEdit
  2. To make things worse: often, the browser picks completely incomprehensible, temporary filenames! I tried the HTTP Content-Location field, but it doesn't do the trick

Any tips for implementing the upload page + clever filename handling?

-- PeterKlausner - 23 Aug 2002

Great idea (I have been thinking about it myself smile )

Yes, all meta tags should be removed and later on added again, but the problem is that you don't know what version you were editing. So possibly, add a %META:REVISION{r1.2}% - Don't remove this line! to the top of the text. If it's not there, pretend that it is the latest version. Ok, this all doesn't really matter now, but one day TWiki will perhaps be able to do revision merging, and we should be ready smile

As for downloading file names, content-disposition: inline; filename=%TOPIC%.twiki should do the trick. Not all browsers honour this, though, but netscape and ie seem to.

And the panel where you download the file could already have a form to upload it with the filename preloaded, so that you can easily edit it and just click on upload.

And as for starting the editor from the browser, because I chose .twiki as the extension, you could configure your browser to automatically run your editor with that type of file.

So it's all possible, with a little tweaking on the user side, but that's easily explained.

-- WoutMertens - 23 Aug 2002

Thanks for the tip; before that, the files used to have no extension. Still, netscape sometimes turns the name into garbabe like VUG8GIJG.twiki. Hmmm. Could be this happens, when I download the same name twice? Anyway, here's the diff, which adds the option ?download=on to the view script.

diff -c view raw
*** view        Thu Aug 22 14:24:21 2002
--- raw Fri Aug 23 15:42:58 2002
***************
*** 73,78 ****
--- 73,79 ----
      my $revuser = "";
      my $pdftitle = "";
      my $pdfcall = "";
+     my $download = $query->param( "download" ) || "";
      my $viewPdf = $query->param( "pdf" ) || "";
      my $viewRaw = $query->param( "raw" ) || "";
      my $unlock  = $query->param( "unlock" ) || "";
***************
*** 116,121 ****
--- 117,132 ----
              $text = &TWiki::Store::readTopicRaw( $webName, $topic );
          } else {
              ( $meta, $text ) = &TWiki::Store::readTopic( $webName, $topic );
+           if ( $download ) {
+               print "Content-Type: application/twiki-text
+ Content-Location: $theUrl/$webName/$topic
+ Content-Disposition: inline; filename=$topic.twiki
+
+ ";
+               $text =~ s/^    /   /mgo; # convert _leading_ tabs
+               print $text;
+               exit;
+           }
          }
          ( $revdate, $revuser, $maxrev ) = &TWiki::Store::getRevisionInfoFromMeta( $webName, $topic, $meta, "isoFormat" );

-- PeterKlausner - 23 Aug 2002

Nice. I would make the Content-Type be 'text/x-twiki' though, I think that follows the standards more. What about adding a timestamp so that you never download the same file twice?

I tried making text/x-twiki being handled by Kate on my KDE desktop, but the problem is then that when I open the file directly from the web, it gets a random filename. When I download with mozilla, it doesn't, but it adds a "-1", "-2", etc if the file already exists.

I also tried embedding it as an <OBJECT>, but that didn't really do any good either...

Ah well, at least I can edit the text in gvim now, all we have to do now is uploading it.

-- WoutMertens - 25 Aug 2002

Zope (www.zope.org) has a thing called ExternalEditor. It's a system based on a clientside helperapp. You download the file/document you want to edit, the helperapp gets fired up, helperapp then fires up your preferred editor and keeps track of the (temp) file. Every so often the helperapp uploads/saves your file, and when you close the editor it saves the file for good and unlocks the file.

See http://www.zope.org/Members/Caseman/ExternalEditor/readme for a more detailed explanation and http://www.zope.org/Members/Caseman/ExternalEditor for sourcecode etc.

Perhaps with a little change (e.g. get rid of webdav) it could be a great add-on to TWiki. If we then also can make a wysiwyg WikiML editor (just a normal desktop thingy, not a plugin) or a WikiML mode for e.g. Word/Emacs/.../... then we're there I guess. Also it then becomes a breeze to store e.g. Excel sheets in wiki, edit and save to the wiki - total office integration (a la Livelink).

JeroenVanDongen - 31 Oct 2002

First Pass at a Solution

So eventually a grad student wasting time is going to post a script...

I've written a little daemon that uses a FIFO to communicate to get and store files to a TWiki. You supply your authentication to it and then talk to it over the pipe, checking a log for errors and results. Add a couple of scripts for the VimEditor and essentially the editor turns into a primitive Wiki browser/editor system.

I've put this up on the page EditDaemonWithGVimIntegration

-- SimonClift - 12 Nov 2002

Interesting stuff - I use VimEditor a lot for coding so it would be nice to use it for TWiki editing as well. The page you mentioned doesn't exist yet, but I'm sure it will smile

-- RichardDonkin - 12 Nov 2002

You were too quick... wink

-- SimonClift - 13 Nov 2002

A couple of related pages are http://www.emacswiki.org/cgi-bin/wiki.pl?WikiRemote (similar concept for EmacsEditor and EmacsWiki) and http://www.decafbad.com/twiki/bin/view/Main/XmlRpcToWiki (using XmlRpc to link a WebLog to TWiki). However, neither of these uses vim so clearly not as good smile

-- RichardDonkin - 17 Nov 2002

The text mode browser 'w3m' uses vim (or whatever $EDITOR is set to) when editing textareas. See the update at the bottom of EditDaemonWithGVimIntegration for more.

-- TWikiGuest - 03 Dec 2002

It looks like the Zope-Guys do have a solution for this take a look at this for details. I'm not sure how it works but maybe it helps.

-- NilsBoysen - 03 Jun 2003

The mechanism of the Zope solution is the vision of this topic. Unfortunately, the server part does not exist (yet). http://www.zope.org/Members/Caseman/ExternalEditor/readme explains:

7
Every so often (if so configured), the helper app stats the content file to see if it has been changed. If so, it sends an HTTP PUT request back to Zope containing the new data.
If TWiki understood WebDAV PUTs, i.e. TWikiWebDavServer were implemented, at least we could re-use the client helper app.

...

Just to have a primitive starting point: I hacked savemulti like so:

RCS file: /var/cvs/twiki/bin/savemulti,v
retrieving revision 1.1
diff -c -r1.1 savemulti
*** savemulti   2002/07/17 08:23:51     1.1
--- savemulti   2003/06/05 20:18:53
***************
*** 83,88 ****
--- 83,97 ----

      # get text and other parameters
      my $text = $query->param( "text" );
+     my $textfile = $query->param( 'textfile' );
+     if ( $textfile )  {
+       my $tmpFileName = $query->tmpFileName( $textfile );
+       open TMP, "<$tmpFileName" or die
+                               "can't read $textfile from $tmpFileName: $!";
+       undef $/;
+       $text = <TMP>;
+       close TMP;
+     }
      my $unlock = $query->param( "unlock" ) || "";
      my $dontNotify = $query->param( "dontnotify" ) || "";
      if ( $saveaction eq "Checkpoint" ) {
Then the added this form to the oopsmore.tmpl template:
<form action="%SCRIPTURLPATH%/savemulti%SCRIPTSUFFIX%/%WEB%/%TOPIC%" method="post" enctype="multipart/form-data">
   * *Overwrite topic:*
      * Select local file
        <input type="file" name="textfile" value="c:\temp\%TOPIC%.txt" >
        then
        <input type=submit value="Upload">
</form>
-- PeterKlausner - 05 Jun 2003

BUG WARNING: this kills your form content frown Which is odd, as other meta data like attachments and the form assignment stay intact! ... 5 seconds of thinking reveal: of course this is not odd, it is obvious, as this is what people manipulate from within the edit page, not the form type, not the attachments...

-- PeterKlausner - 06 Jun 2003


The Electrix addon for Mozilla 1.3+ lets you use the editor of your choice for textarea. Mozilla freezes while the external editor is open; the author says he is looking for away around this. Personally in the light of problems like BackFromPreviewLosesText I think this might be feature.

http://reddleman.org/site/projects/electrix/index.html

-- MattWilkie - 27 Jul 2003

I have a different method that works around this and suits me well. On unix, I keep a GUI browser and lynx side by side on the screen. When I want to edit a topic, I pick up the URL from the GUI, paste it into lynx and change view to edit. Lynx uses my preferred default editor (^Xe on an editable text area to get it) and I can easily save a copy to my own /tmp/foo as I work, e.g. if the phone rings. Things like search/replace are easy, and you get a view of the (original) GUI-presented topic while you edit which I find saves a lot of head-scratching delays. This method might suit some other unix people who have strong favourites for text editors, in the interim at least.

-- SueBlake - 28 Jul 2003

By the way, Lynx now supports binary file uploads to TWiki attachments - see BrowserIssues for the version required.

-- RichardDonkin - 29 Jul 2003

ThoughtsAboutUsingExternalApplications discussses the generalization of this: using external applications to edit attachments, e.g. VISIO for drawings, Excell for *.XLS.

I'm thinking about trying to use HTTP PUT. (I've learned more than I wanted to know about HTTP trying to get RedirectWikiUrls.)

Q: I swear that I've seen some GNU EMACS packages that allow wiki editing.

-- AndyGlew - 26 Sep 2003

This scenario can be simply realized with Mozex:

http://mozex.mozdev.org/

and if you want also to refactor, search and preview your topics, you may use Mind Raider wink

http://mindraider.sourceforge.net/docTwiki.html

-- MartinDvorak - 01 Mar 2005

By the way, I have tested EditTWikiExternalEditorAddOn and it worked pretty well with several editors (including emacs). However, that was on Beijing; I have not tested it against Cairo yet. There also is EditorDaemonAddOn which I believe people have used with vim.

-- ThomasWeigert - 02 Mar 2005

I have been using GNU EMACS' w3m, a web browser within EMACS, so I click on the text area and get an EMACS buffer that I can do real editing on.

In ThoughtsAboutUsingExternalApplications I write about using generic external applications, possibly even Word or Vision Most recently have added thoughts about doing file format conversion on the server side, so that a Word document, e.g., can be converted to wiki text. Or, my interest, a Visoo drawing to a GIF so that it can be seen on the wiki page.

-- AndyGlew - 15 Jul 2005

Edit | Attach | Watch | Print version | History: r21 < r20 < r19 < r18 < r17 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r21 - 2005-07-15 - AndyGlew
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.