How to include a Rich Text Editor for Textareas (e.g. CKEditor, TinyMCE) in WCEM 2.0

[fabianlehmann]

Hi all,

for a project we would like to include a Rich Text Editor for Textareas (e.g. CKEditor, TinyMCE) in WCEM 2.0

Sadly it doesn’t work that easily.

The problem is, that the JavaScript files post-load other JavaScript files (e.g. plugins, language files) and these files will not be served by WCEM – we get a 404-error

If we put the editor folder in the UI-Part of the module in

META-INF/resources/[namespace]/[moduleid]/mimes/ckeditor.

The right path would be

„http://localhost:50000/xxx_main/javax.faces.resource/config.js.jsf?ln=[namespace]/[moduleid]/mimes/ckeditor“

But the editor tries to find these files in

„http://localhost:50000/xxx_main/main/config.js?t=A5AB4B6“

Here we discover 2 problems:

1. The path is wrong

2. The file „config.js“ will not be served. Only if it ends on „.jsf“ or „.xhtml“

Additionally:

3. In .js-Files Variables like #{request.contextPath} will not be interpreted

Even if we put the editor-Sources in

META-INF/resources/ckeditor.

Correct would be

„http://localhost:50000/wcem_main/javax.faces.resource/ext/config.js.jsf?ln=[...]“

But the editor tries to find these files in

„http://localhost:50000/xxx_main/main/config.js?t=A5AB4B6“

Which is the same problem.

The TinyMCE for JSF 2.0 gets the path right, but still misses the “.jsf” ending

„http://localhost:50000/wcem_main/javax.faces.resource/ext/config.js?ln=[...]“.

Instead of

„http://localhost:50000/wcem_main/javax.faces.resource/ext/config.js.jsf?ln=[...]“

WCEM doesn’t serve these files, even if they are found in the rioght folder.

There is also an JSF-Package for CKEditor, but it doesn’t work with MyFaces. There are some Classes missing.

1. Is there a “Best Practice” to include such JavaScript-Libraries

2. Is there a possibility that “.js” will be served without additional „.jsf“ or „.xhtml“?

3. Is there a possibility to make Variables like #{request.contextPath} interpreted in .js-Files like in “.css”-Files

4. Is there possibly already an editor in the system, which we didn’t find?

Thank you in advance for your help,

Fabian

[Former Member · Accepted solution]

Hi,

I personally had not yet the issue, but maybe this helps

the JSF extension is used to determine the responsible servlet. it might be possible, to use beside the extension also the path e.g. like "/javax.faces.resource/*", so that all calls targeting the directory are also directly forwarded. I assume there is a Filter or Servlet implemented, which is parsing the URL. It might be, that you have enhance such logic to handle URLs without the extension - but only if the logic expects a .jsf - if you are lucky, then it would be sufficent to add the sevlet mapping rule.

But if we follow the rule, keep it simple & stupid, then use following options

1) Ignore the JSF resource locator path and point directly to the script / css file using the absolute or relative path as you are used to. Something like http://<server>/main/resources/sap/comp.theme/styles/pebbles/stylesheet.css or "/main/resources/sap/comp.theme/styles/pebbles/stylesheet.css" . In this case the path should resolve itself. But keep in mind, this might not really be nice, because it would knock out the modulized concept and resource allocation. For an implementation project however sufficent if you do not rely on various setups in various name spaces.

2) With WCEM 3.0 you can outsource your stylesheets & images and store them on a external server. I am however not sure, if this also applies for the javascripts.

3) You can simply store your scripts directly on another web-server and manually point to those files, then it would basically the same as 2), but the URL is fully hard-coded. It might be even be better to handle the look & feel changes, because you avoid the constant re-deployments

If I find some time, then I will explore the initial indicated solution and provide you a better answer

[ralf_detzler · Accepted solution]

I have tried it now and got it working by adding the tinymce javascript resources in the WebContent folder of the web application module.

I created a composite component loadTinyMCE.xhtml to load the javascript without jsf resource handler:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"

xmlns:h="http://java.sun.com/jsf/html"

xmlns:cc="http://java.sun.com/jsf/composite"

xmlns:ui="http://java.sun.com/jsf/facelets">

<cc:interface> </cc:interface>

<cc:implementation>

  <script type="text/javascript" src="../resources/tinymce/jscripts/tiny_mce/tiny_mce.js"></script>

</cc:implementation>

</ui:composition>

Another composite component implements the textarea with the tinymce functionality (tinyMCE.xhtml):

<ui:composition xmlns="http://www.w3.org/1999/xhtml"

xmlns:h="http://java.sun.com/jsf/html"

xmlns:cc="http://java.sun.com/jsf/composite"

xmlns:ui="http://java.sun.com/jsf/facelets">

<cc:interface>

   <cc:editableValueHolder name="inputText" />

</cc:interface>

<cc:implementation>

<script type="text/javascript">

            tinyMCE.init({mode : "textareas", theme : "simple" });

</script>

<h:inputTextarea id="inputText" value="#{cc.attrs.value}" />

</cc:implementation>

</ui:composition>

In an arbitrary page, I can use the editor by

1. defining the namespace

    xmlns:rde="http://java.sun.com/jsf/composite/components"

2. and using the two composite components with this namespace:

<h1>TinyMCE in Web Channel Page</h1>

<wec:form id="form">

     <rde:loadTinyMCE />

     <rde:tinyMCE id="tiny1" value="#{helloWorldBean.description}" />

     <wec:commandButton id="send" value="update Text" />

</wec:form>

I hope, that shows, how TinyMCE can be included in Web Channel Experience Management.

Best Regards

Ralf

[fabianlehmann · Accepted solution]

Hi Ralf,

it works thanks a lot.

The only disadvantage of this solution is, that it's not in an own module (DC) and thus cannot be delivered as a whole package.

Do you know the reason, why it doesn't work in a module resource folder?

br,

fabian

[WolfgangSattler · Accepted solution]

Hi Fabian,

The module resource folder is initially only included in a jar file. It will be extracted at runtime by our JSF Resourcehandler extension. Therefore only resources, which are requested by JSF can be located in module resource folder.

There might be an option, which I haven't verified yet: The module DPU for sure can also include an additional war file, which have an own context root. This would lead to absolute URI to use to read the Javascript. But it would be part of your module! As said I haven't test it, but it should work!

Hope that helps.

Regards Wolfgang