Forum OpenACS Improvement Proposals (TIPs): Re: TIP #134: Change default value for RichTextEditor param in acs-templating

I only referred to xowiki since originally you had to have xowiki installed and mounted at xowiki for it to work and it was the first place I saw it in use.

I don't really have a preference, from my perspective this has never been comprehensively addressed, only locally used customizations have been added to the toolkit to provide access to the features.

You are correct that tinymce support does not allow customizing the editor on a per form basis. Its not clear this actually is a good idea. It allows xowiki to do things that are not supported generally in the toolkit by other packages. I don't have a good idea of the use cases for this, but to support flexibility it probably should be fixed. I don't think the existing confifg support in the richtext widget makes sense for TinyMCE, perhaps a way to override individual attributes of the config, instead of just allowing changing some of them or requiring the entire config in javascript. I'd have to think about it.

I believe regarding bugs, all the bugs are fixed on oacs-5-5 branch and not on HEAD yet.

There is an oacsimage plugin for TinyMCE I don't think it was ported to work on Xinha though.

Regarding the parameter value, the description on HEAD says "xinha" or "tinymce" listing the valid values.

Dave wrote:
You are correct that tinymce support does not allow customizing the editor on a per form basis. Its not clear this actually is a good idea. It allows xowiki to do things that are not supported generally in the toolkit by other packages. I don't have a good idea of the use cases for this, but to support flexibility it probably should be fixed
If I understand it correctly, the situation of the tinymce integration is actually much worse: in the current openacs integration there is one global customization of tinymce that applies to all textareas in all forms in all packages instances of all package types. Over the rich-text API (over three years in OpenACS) one can configure every single textarea. This has nothing to do with xowiki.

The single global configuration file is a severe limitation. For example, in our learn system, we use different configurations of xhinha in the forums for admins and ordinary users (admins have more functionality). Similarly, we have several custom plugins for xinha, which make sense only for certain applications. Nima has developed some xinha-plugins for assessment. Rocael has developed some plugins for their packages. Do you really think that allowing attachments for every rich-text occurrence is a good thing? Actually, i have trouble to understand, why one has to argue for it.

Dave wrote:

Regarding the parameter value, the description on HEAD says "xinha" or "tinymce" listing the valid values.
It is neither in HEAD nor on oacs-5-5.

The whole discussion boils down to the question: Are the people arguing for making tinymce default are capable/willing to address the various issues and are they capable/willing to take responsibility for tinymce support in a similar way as there is support for xinha, or not. Supporting an additional editor will increase the maintenance work, especially, when it is made the default. For me, it is simply to early to make the decision. My current vote is against making it default.

We use special widgets for the content tool, and for assessment as well, more will come.
Based on arguments exposed here, I do not approve the change, until the remaining issues are cleared, and I would prefer to ask first the community about whether they use xinha, or they want to change to something else, and listen the pros / cons of changing to a new editor, which is a very important part of any system that produce content like OpenACS/.LRN.
Based on arguments exposed here, I do not approve the change, until the remaining issues are cleared, and I would prefer to ask first the community about whether they use xinha, or they want to change to something else, and listen the pros / cons of changing to a new editor, which is a very important part of any system that produce content like OpenACS/.LRN.
You (and to some extent Gustaf) are arguing against a strawman, in other words rather than arguing against the TIP, you are arguing against something else of your own invention which is not the TIP.

The TIP is NOT to "switch to a new editor" or "to change to something else".

OpenACS/.LRN has supported *both* TinyMCE and xinha for some time, this TIP does not change that.

This TIP is only to change the *default* editor selected if you change from the default configuration which is NO WYSIWIG AT ALL.

Adoption of this TIP in no way prevents you or Gustaf or others from using xinha.

So please stop arguing that it does. It pisses me off.

The argument for changing the *default*, because out-of-the-box it gives you more accessible and valid HTML without the use of external apps like "tidy", and we claim to support that (I realize that traditionally neither you nor Gustaf consider accessibility to be particularly important, but honchos and the board have decided otherwise).

So we are simply suggesting that we provide a cleaner editor *by default*, not that you stop using xinha.

The whole discussion boils down to the question: Are the people arguing for making tinymce default are capable/willing to address the various issues and are they capable/willing to take responsibility for tinymce support in a similar way as there is support for xinha, or not. Supporting an additional editor will increase the maintenance work...
TinyMCE has been supported for some time now, Gustaf.

This TIP doesn't change that.

Please stop arguing against something that isn't part of the TIP to justify voting against the TIP.

Maybe we don't share the same definition of "support". Yes, it is included since a while in OpenACS, but is it supported? If something is default, it should work out of the box and it should be documented how to use it (check the issues above). If people vote for making it default, they either don't care or they don't know about these issues. I would not have brought up maintenance, if there would have been any posting that someone address these.

Just another example, where this impression comes from: the default browser should work with ie8. I tried to figure out, what version of tinymce is in the 5-5 branch. Your posting in the release notes of OpenACS 5.5a1 says 3.1.1, the changelog in the version in the oacs-5-5 branch says 2.13, the .js source file there says 3.2.2.3, while the currently released version is 3.2.4.1 (a few weeks old, why we do not use this one?). Now, try to figure out, whether IE8 works with the included version.

Anyhow, i have spent already too much time on these issues. These are not part of the tip, but necessary to make the decision.

Maybe we don't share the same definition of "support". Yes, it is included since a while in OpenACS, but is it supported?
Maybe you should go to more OCT meetings and take your membership seriously.

Yes, it's supported.

As far as problems go, Daveb is supporting TinyMCE, he's following the thread, and I'm sure he'll fix whatever issues come up.

As far as the version number goes, I got that from Daveb, he can correct it, if it's wrong.

As far as the issue of support goes, we've been discussing TinyMCE and the possibility of making it the default for what seems like forever at our weekly OCT meetings. Really, for OCT members to drop in at the last minute asking "do we support TinyMCE", ignorant of such a basic decision made long ago and discussed often, is just wrong. To veto something at the end while not playing a role in the ongoing decision-making process, is just wrong. To argue that the TIP should be voted down because of a false notion that it will require one to stop using xinha is just wrong.

Roceal,

I think the existing of local custom plugins does not affect what editor is available in the core as a default. Of course if something is actually broken, we should fix it. It is not difficult to make plugins for TinyMCE or Xinha either.

I personally don't have a preference for TinyMCE or Xinha as the default. I have not evaluated which one is better for a certain purpose. I did the original work for MGH and added the newer TinyMCE because it supports translations of the TinyMCE interface.

Ok I added per widget config options. You can override any of the tinymce config elements using the same syntax.

Setting {options {editor xinha}} will override the default editor for tinymce or xinha, this already worked as it was built into the richtext widget origianlly when we still supported RTE.

I'll see if I have time to get the OacsFS plugin to work on TinyMCE.

It probably will take 2-3 hours. One good thing of these editors is the plugin architecture. Both editors are very easy to add new plugins.

Thanks Dave. I'll fix the version numbers.
Yes, the default won't affect local install preference (you can change it at any time), this boils down that the online editor it's a matter of preference. The major problem we still face with online editor is the copy/paste from word :p

Hi all,

I've updated the release notes in acs-core-docs including the right version number. (thks Dave for the upgrade)

I've added the missing message in tinymce (oacslink.desc etc.).

I've updated the doc of template::widget::richtext for tinymce. It was a bit out-of-date. It says that oacsfs scripts live at xowiki, is that still true?

Caveat: the three adp-files needed for the OpenACS file selector (insert-image, insert-ilink and file-selector) are currently part of the xowiki package, since acs-templating is per default not mounted. This is hopefully only a temporal situation and we find a better place.

I don't know if it has been moved to acs-templating but in any case, it means that to use it with xinha it needs xowiki installed or acs-templating mounted.