Tags:
create new tag
, view all tags
Early version of a Javascript based editor, based on David's contribution in AppletBasedEditor.

Couldn't get it to work in topic, probably some sort of script problem. So done as an attachment.

  • IE only
  • Some bits don't work because not rendered by TWiki e.g. topic list and signature text.
    • [ MartinCleaver ] Signature would have to be pre-evaluated methinks.

  • could have this as a skin for edit e.g. edit.js.tmpl, user could specify this is required in preferences
    • [ PeterThoeny ] Good idea. Better to call edit.iejs.tmpl since it is for IE only.

Basic editor (IE)

-- JohnTalintyre - 29 Jun 2001

Oh yes. That's gorgeous! Well done!

-- MartinCleaver - 29 Jun 2001

This is great stuff!

  • Is it possible to check for the browser version and to deliver the enhanced version only if it is IE?
  • How difficult is it to get it to work with Netscape (with browser detection) ?

-- PeterThoeny - 29 Jun 2001


How about allowing the user to decide whether he wants scripting or not? (Could be saved as parameter in the URL.)

This would suit those who are as paranoid as myself smile

-- JoachimDurchholz - 30 Jun 2001

I think detecting IE makes a lot of sense for this. I'm not so sure about the paranoia - that's surely more down to the sites you go to and your email client. I think best bet might be user preference, plus browser detection.

This uses some fairly obscure parts of IE's DOM, which are suprisingly difficult to use. I don't know what equivalents Netscape has - only know for certain that we could do a least as well with Java.

JohnTalintyre - 30 Jun 2001

There is one feature that this javascript needs that I don't think Communicator has (Mozilla probably has it). This features is the ability to access the current selected text in the TEXTAREA box... The only workaround would be to write a plug-in which would be platform dependent to try to access this information (but that would be tricky)...

Java seems the way to go as long as the applet is not to heavy to load and the user's have the choice (maybe with a link in the standard EDIT page to open the applet)..

-- LudovicDubost - 30 Jun 2001

I think both approaches should be offered. It doesn't make much sense to have users use a heavy Java-applet if the whole company is using IE. And besides, this is a solution that could be put into the release right away; I don't know how far long in the development that Java-applet thingy is.

I've written Dave Winer with a request for permission to use the Manila stuff in Twiki. I can't imagine him turning us down. I'll post his response as soon as it's in.

-- DavidHeinemeierHansson - 30 Jun 2001

Note that any use of Manila code in TWiki would require the extracted code to use the GPL. It's not impossible that Dave Winer would do this, but seems a bit doubtful...

-- RichardDonkin - 30 Jun 2001

I wonder how much an issue licensing is. There is very little code and what it really does is show how to use the TextRange object.

-- JohnTalintyre - 03 Jul 2001

Yearh, especially after the code has been customized some. Besides, Winer hasn't yet taken the time to respond to my request for permission, so we should probably just proced.

-- DavidHeinemeierHansson - 04 Jul 2001

Does it make it to TWikiReleaseSpring2001?

-- MartinCleaver - 10 Jul 2001

This can be done by just changing the edit.tmpl template. The only problem I have for TWikiReleaseSpring2001 is making it optional. At present we have no mechanism for conditional template inclusion based on browser type and/or user preferences. Any ideas?

-- JohnTalintyre - 10 Jul 2001

I hope we would do a re-write rather than just taking the code from Manila (assuming Dave Winer does not respond). There are some unfortunate examples where copyright holders have asserted their rights very late in the day and forced a re-write at that point. Under the DMCA the consequences could presumably be even worse, so I'd really rather not see TWiki including copyrighted code not licensed under GPL.

-- RichardDonkin - 10 Jul 2001

The Javascript editor has now been uploaded to CVS. Some comments:

  • With code freeze for TWikiReleaseSpring2001 on I've only done this as only code change was clean one in edit script.
  • As stated before, the code from Manila was used to show how to use ranges, otherwise little was used from Manila. I haven't references Manila in the code, but if people think it's sensible I can say "inspired by ..."
  • You only get this editor if:
    • You are using IE - simply checks for MSIE in user-agent field
    • Preference EDITOR is not set to none
  • Optional inclusion code is a simple, but not great design and is based on optional template inclusion, see http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/twiki/twiki/bin/edit?rev=1.31&content-type=text/vnd.viewcvs-markup

-- JohnTalintyre - 11 Jul 2001

Some thoughts on the latest CVS commit:

How about decoupling this completely from the code base? I suggest to create an edit.ie.tmpl skin that has all JS code embedded, including discovering the Browser type and version (there are tons of pages around that do that). Non-IE browsers simply don't do the graphical editor stuff.

Advantage:

  • User can selectively switch this on and off in the preferences
  • A site manager could rename edit.ie.tmpl to edit.tmpl to enable that behaviour for all.
  • No change in Perl source needed (maintenance and KISS)

So I recommend to revert the changes to the edit script, to remove the extra template files, and to create the skin that detects the browser. (Skin can be done after the release if there are time constraints)

-- PeterThoeny - 11 Jul 2001

I had thought about doing browser detection using client side Javascript, but given the nature of the editor I felt server side processing was much more effective e.g. cutting out the edit buttons is easier and more efficient server side - IE and DOM would allow this, but I believe it's a fair bit harder than server side processing. Saving on the download of Javascript is also easier server side. On the points above:

  • User can already turn on and off in preferences (with EDITOR setting). This is kept separate from the skin, I feel that choice of editor is not really a skin. However, if it is seen as a skin then, how does a user combine different skins? When there's a Java editor as well, isn't it more obvious to change editor rather than skin?
  • A site can have users with multiple browsers, so edit.ie.tmpl would need client side Javascript to deal with different browser types.
  • Less change to Perl code is obviously good. Current change is minimal, but I don't think it can be done via current Plugin API. Almost can, but needs to offer template for processing.

My suggsetion if this is seen as inappropriate for this release

  • Cut edit script from new release, attach to this topic for people that want to use it
  • Post release, allow plugins to cut in on template processing so that this can be done as a plugin.

-- JohnTalintyre - 12 Jul 2001

To reduce code complexity and keep it simple I suggest to revert the changes to edit back to before. This is just for the new release, after that we can think about a clean design.

JS based Browser detection does not take too much code, so the page download does not increase much.

RE conditional rendering of editor toolbar: I have not tried this, but it should be straight forward. Simply add a JS call inside the HTML body that conditionally builds the toolbar, just above the TEXTAREA. It might even be possible to do this transparently for browsers with disabled JS.

-- PeterThoeny - 11 Jul 2001

OK, I did some testing. editor2.html is the 2nd cut that detects the browser and creates the toolbar (or not) depending on the browser type and version. All conditional HTML output is done with JS.

There is an unsolved problem: JS strings can only be defined by 'single quoted text' or "double quoted text" on one line. The HTML for the toolbar can be created over multiple lines, but each line must have enclosing quotes. I.e.

  var toolbar = 
  '<table border="1" ...>\n' +
  '<tr>\n' +
  '...\n' +
  '</tr>\n' +
  '</table>\n';

That works fine with static text, but it fails with variables that get expanded on the server by the scripts in case a variable gets expanded over more then one line (i.e. %TOPICLIST% ), or in case the variable has embedded single quotes.

-- PeterThoeny - 13 Jul 2001

The problem of the %TOPICLIST% variable expanded over more then one line is solved: There is now a new separator="..." parameter where you can change the default new line separator between items: %TOPICLIST{"" separator=" "}%

Attached is the 3rd cut, the edit.iejs.tmpl skin. This skin is based on the s2nd cut (editor2.tmpl) for the JavaScript part, and the latest Alpha template (edit.tmpl) for the rest. This skin generates code conditionally:

  • Browsers with JavaScript disabled: Edit the usual way, toolbar is missing. Has a note at the bottom that there is an enhanced editor for IE.
  • Non-IE browsers with JavaScript: Edit the usual way, toolbar is missing. Has a note at the bottom that there is an enhanced editor for IE.
  • IE browsers with JavaScript: Toolbar is shown for enhanced editing.

The edit.iejs.tmpl skin is installed on this server. Edit this topic with the experimental JavaScript editor (needs IE.)

Can someone take this over from here and enhance the toolbar? Some actions need to be made "safe for fools", i.e. prevent a second bullet if there is already one there.

-- PeterThoeny - 14 Jul 2001

This is quite impressive, just tried it on this topic using IE5.0. However, the bold/italic and bullet buttons didn't work - showed the URL etc. The Signature button and dropdowns did work, and I do have JavaScript enabled, so I'm not sure what's wrong.

-- RichardDonkin - 15 Jul 2001

I don't think this picked up the most recent Javascript from CVS.

-- JohnTalintyre - 15 Jul 2001

I merged John's latest code into the edit.iejs.tmpl skin, is also attached. Should work now with IE 5.0. The *B*, _I_ and =C= formatting does not work with IE 4.0.

Listing all webs is nice, but has a download time issue for a large web. The topic list is defined as %TOPICLIST{"" separator=" "}%, e.g. the topic name needs to be defined twice because of the JavaScript code. The size of the expanded %TOPICLIST{...} variable is: numberOfTopics * (2 * averageTopicLength + 25). The Codev web has now almost 600 topics, editing a new topic in Codev with the edit.iejs.tmpl skin has 48 KB vs 5 KB for the classic edit page.

In case you like the new editor here at TWiki.org you can define a personal preference variable in your home page: * Set SKIN = iejs

-- PeterThoeny - 17 Jul 2001

Added new attachment. Bullet and headings now a bit more sensible with replacement of previous values. Still no IE 4 fix. Given download size perhaps another skin without Webs listed? Alternatively, may be it's worth going for a dialog box that only queries the server if required.

-- JohnTalintyre - 17 Jul 2001

I've set the SKIN variable on MartinCleaver but has not taken effect, have I done something wrong?

-- MartinCleaver - 17 Jul 2001

Also doesn't work for me.

-- JohnTalintyre - 17 Jul 2001

Just updated the skin at the TWiki.org installation with John's latest cut (plus a small fix in TOPICLIST). Works now for me. Give it another try.

-- PeterThoeny - 18 Jul 2001

Odd, still doesn't work for me. I tried looking at Main.PeterThoeny, but couldn't see your settings to check.

-- JohnTalintyre - 18 Jul 2001

Doesn't work for me either.

-- MartinCleaver - 18 Jul 2001

Should this work on TWiki.org now?

-- MartinCleaver - 28 Sep 2001

If this is a skin, how does it work in conjunction with other skins, e.g. TigerSkin?

-- MartinCleaver - 05 Nov 2001

It's not really a skin. A single .tmpl files is supplied that can be used in place of the default skin file for editing, either by replacement or by going for it as a skin. The differences between this and edit.tmpl can be used in other skins.

-- JohnTalintyre - 06 Nov 2001

I've updated the edit.iejs.tmpl file:

  • Version 1.4 as-delivered version in TWiki 01 Sep 2001 release
  • Version 1.5 corrected the NoCancelEdit error

-- MikeBarton - 18 Nov 2001

This is very nice! Added some simple setup pointers to InternetExplorer. One question: why are there two toolbars, top and bottom? This takes up screen real estate and doesn't seem like much of a benefit.

Also, has anyone tried getting this working in a recent Mozilla, or Opera 6?

-- RichardDonkin - 26 Mar 2002

You are usually working at the top of the page or the bottom, tools bar top and bottom save scrolling. Including topics via a drop down is not too hot, could really do with a pop-up and being able to select the Web.

-- JohnTalintyre - 26 Mar 2002

I always see both toolbars on the same maximised IE5 window, no scrolling required - although if you have a lot of WebForm stuff, you might need to scroll.

I think the location of the toolbars should be customisable - it probably makes sense if you have a 19 inch screen, but I have a relatively small laptop screen, so I only want one toolbar. This is easily done - how about a variable, IEJS_TOOLBAR = 'top', 'bottom' or 'both'?

Also, in some cases, the toolbar takes up about 100% more vertical space than it needs to, i.e. lots of blank space above and below the actual toolbar elements. This is on IE 5.5 on Win2K.

-- RichardDonkin - 27 Mar 2002

Would it be OK to take out the reminder, when using non-IE browsers with JavaScript, that there is an editor available if you switch to IE? I think there are enough pressures to switch to IE already!

Some interesting URLs

Also, I'll put in the IEJS_TOOLBAR variable since nobody has objected above, and it will be transparent to existing users.

UPDATE: Both changes done, see the CVS link below.

-- RichardDonkin - 29 Mar 2002

Could we have a go at integrating The Midas solution? This ia a solution that nicely works together with Mozilla & IE. Seamlesly. Have a look at:

Don't know where to start, but I'd love to have this verry light solution in.

-- GerkeKok 15 Apr 2003 (this seems to be an old topic, but verry hot for me)

There is also htmlarea which now works in both IE and Mozilla.

-- JamesThompson - 18 Apr 2003

Every javascript editor known to man

-- DanDees - 19 Apr 2003

htmlarea discussion moved to HtmlAreaEditor by MattWilkie on 22 Apr 2003


Latest template is at CVS:templates/edit.iejs.tmpl

  1. The javascript in JavascriptBasedEditor would be best moved to the pub directory of a Plugin so that there is minimal javascript in the template itself. This would allow it to be used from multiple templates. Thusly:
<script language="JavaScript" src="/pub/TWiki/WysiwygHtmlEditor/iejs.js"> ... 
  1. Htmlarea rocks, IMHO.

-- MartinCleaver - 26 May 2003

Has anyone updated the TopicPicker in IEJS to allow the user to pick topics in other webs?

-- MartinCleaver - 20 Oct 2003

Google:phpBB has a similar feature - its code actually works on Mozilla Firebird/Firefox 0.7, so it could be a good way to get this working on Mozilla.

-- RichardDonkin - 15 Feb 2004

"Why not WYSIWYG writing for the Web? We're stuck in 1996." So says Jon Udell regarding the use of TML.

http://udell.roninhouse.com/bytecols/2000-05-03.html

-- MartinCleaver - 07 Jun 2004

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formattmpl edit.iejs.tmpl r5 r4 r3 r2 r1 manage 11.9 K 2001-11-18 - 20:01 MikeBarton Edit skin, corrected TWiki 01 Sep 2001 version
Unknown file formattmpl edit.with.htmlarea.tmpl r1 manage 4.4 K 2003-04-22 - 07:35 GerkeKok This is a edit.tmpl that uses the htmlarea.
HTMLhtml editor.html   manage 7.4 K 2001-06-29 - 21:24 JohnTalintyre Basic Javascript editor (IE)
HTMLhtml editor2.html   manage 9.1 K 2001-07-13 - 07:42 UnknownUser 2nd cut with conditional HTML output
Edit | Attach | Watch | Print version | History: r59 < r58 < r57 < r56 < r55 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r59 - 2004-06-07 - MartinCleaver
 
  • 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.