• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

If a user creates a new topic there is no way for that user to switch to rich-edit (compose) mode without saving and re-editing. This will confuse many manager types.

Also it should be possible to make the traditional Edit button less prominent.


Agreed, this would be nice

CC


less prominent - than what? Should look like what? -- AC
  • Than the compose button - MC

How about only one button, that takes you to your default editor (Plain/Rich) and from either editor there you can switch to another without losing your edits.

MC

Really, it should not be too hard:

  • WysiwygPlugin already has a <> button that puts the editor into HTML mode
    • i.e. there is front end logic that can be extended
  • Our edit already has the ability to swap from topic edit to form change
    • i.e. there is back end logic that can be reused.

MC

Or, a preference for when edits that don't specify a skin are forced to e.g. kupu. On the face of it this would ensure clicking on Nonexistinglinks, and webtopiccreator creates empty topics in kupu.

Ugh. Its bad though, because it means we'd need another skin for when we want Raw Edit.

And, edits (e.g. TWiki:Codev.IejsIsNotASkin) should not be using the skin mechanism.

MC

Hack for Nonexistinglinks for Dakar:

Index: Render.pm
===================================================================
--- Render.pm   (revision 7254)
+++ Render.pm   (working copy)
@@ -559,6 +559,7 @@
                   CGI::a(
                       { href => $this->{session}->getScriptUrl
                           ($theWeb, $t, 'edit',
+                          skin => 'kupu',
                            topicparent => $this->{session}->{webName}.'.'.
                              $this->{session}->{topicName} ),
                         rel => 'nofollow',

And for the webtopiccreator:

--- WebTopicCreator.txt (revision 7254)
+++ WebTopicCreator.txt (working copy)
@@ -1,4 +1,4 @@
-%META:TOPICINFO{author="TWikiContributor" date="1098812697" format="1.0" version="$Rev$"}%
+%META:TOPICINFO{author="TWikiContributor" date="1130901487" format="1.1" version="$Rev$"}%
 %META:TOPICPARENT{name="WebHome"}%
 <form name="new" action="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%INTURLENCODE{"%BASEWEB%"}%/">
 <!-- TODO: do we still need INTURLENCODE nastyness? -->
@@ -13,6 +13,7 @@
 <input type="hidden" name="topicparent" value="%TOPICPARENT%" />
 <input type="hidden" name="onlywikiname" value="on" />
 <input type="hidden" name="onlynewtopic" value="on" />
+<input type="hidden" name="skin" value="kupu" />
 </form>

And for this odd-ball page:

Index: data/TWiki/WebTopicViewTemplate.txt
===================================================================
--- data/TWiki/WebTopicViewTemplate.txt (revision 7254)
+++ data/TWiki/WebTopicViewTemplate.txt (working copy)
@@ -19,5 +19,5 @@

 ---+++ %MAKETEXT{"If you would like to create this page:"}%

-   * %MAKETEXT{"Continue to *[[[_1]][Create the new page]]*" args="%SCRIPTURL%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%"}%
+   * %MAKETEXT{"Continue to *[[[_1]][Create the new page]]*" args="%SCRIPTURL%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%?skin=kupu"}%

-- MC

I changed this to "Engine" because it's not really a plugin problem, but a problem with the default templates/topics. CC


I don't think it is right to start plastering pattern skin with all kinds of special cases for this plugin. For one, this means that similar should be done with every skin. Then the same could go for many other plugins. I realize this is a dilemma in that sometimes a plugin should be intimately connected with the appearance of the pages, beyond just formatting a tag as is usually the case with plugins.

In a sense, this points out that the wysiwyg plugin is not really a plugin, but an extension. Requiring all kinds of hooks in code and template is also a way of bypassing the func API, isn't it? -- TW


Argh, it's really a question of the whole architecture. One way to address it is to ensure that templates have "hooks" in the same way as the code has for calling plugins. For example, a plugin could register a handler for the "%EDIT{...}%" tag that would plug in an alternate editor for edit operations such as edit and create. It is impossible to second-guess all the different functions a plugin may want to subsume, but you can make a pretty good guess - after all, that's what we do with the plugin API. So think about this as a requirement to extend the plugin API into the templates to allow common functions to be overridden by plugins.

I deliberately made WysiwygPlugin a plugin, because we didn't want to "take out" the default edit behaviour. The fact that I was able to make it a plugin speaks volumes for the power of the plugins API!

CC

SVN 7765 - added EDIT_SKIN, which allows us to override the default skin for editing ONLY. This lets you set kupu as the default editor for the entire site, or just a single user.

This lets us remove the horribles in PatternSkin, where it programmatically adds the Compose button.

CC

Related: Item1125

MC

ItemTemplate
Summary Need link from Edit to Compose (WysiwygPlugin)
ReportedBy MartinCleaver
SVN Range

AppliesTo Extension
Component PatternSkin
Priority Normal
CurrentState Closed
WaitingFor

Checkins 7764 7765
Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r20 - 2005-12-05 - MartinCleaver
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback