Another request required me to make my own plugin for TinyMce. Only, it turned out it's not the simplest thing to do, adding a plugin to TinyMce when it's integrated to Wicket. There is almost no help on how to do this so, after having fiddled with this for some time I thought I should help all other plugin creators out there.

Here we'll make a very redundant BoldMakerPlugin just because it's so easy to se it working. I'm assuming that you've got Wicket and also that you have managed to get TinyMce running, if you haven't it's just a matter of cut and paste from WicketStuffs TinyMce page.

To create a plugin you will need two files. Your plugin java file and an editor_plugin_src.js file. I placed my java file among the other wicket java files under src/main/java and named it BoldMakerPlugin.java. This is what it looks like.

 
import wicket.contrib.tinymce.settings.Plugin;
import wicket.contrib.tinymce.settings.PluginButton;
 
public class BoldMakerPlugin extends Plugin{
 
	private PluginButton boldMakerButton;
 
	public BoldMakerPlugin(){
		super("boldmaker");//decides which plugin folder to look in.
		boldMakerButton = new PluginButton("boldmakerbutton", this);
	}
 
	public PluginButton getBoldMakerButton(){
		return boldMakerButton;
	}
}
 

Next I have to fool the TinyMce main script that my plugins JavaScript file is actually located in the same location as the other scripts. I do this by creating a package structure that is similar to what the TinyMce jar file uses. In this case I create a package called wicket.contrib.tinymce.tiny_mce.plugins.boldmaker and put it in src/main/resources. The last package should be similar to whatever you insert into your superclass from your java file.

In this location I put my editor_plugin_src.js file. Mine looks like this:

 
(function() {
	var DOM = tinymce.DOM;
 
	tinymce.create('tinymce.plugins.BoldMakerPlugin', {
		init : function(ed, url) {
			var t = this, s = {};
 
			t.editor = ed;
 
			// Register commands
			ed.addCommand('mceBoldMaker', function() {
				var win, de = DOM.doc.documentElement;
			});
 
			// Register buttons
			ed.addButton('boldmakerbutton', {title : 'Test', cmd : 'mceBoldMaker', image : url + '/../test/img/example.gif',
         	   onclick: function() {
         	   		ed.selection.setContent("<b>" + ed.selection.getContent() + "</b>");
            	}
            });
		}
	});
 
	// Register plugin
	tinymce.PluginManager.add('boldmaker', tinymce.plugins.BoldMakerPlugin);
})();
 

Don't worry if you don't have a button image just yet, it'll be an invisible button with the plugin functionality.

After having done this you should compress it using some kind of JavaScript compressor. I used the one on http://javascriptcompressor.com/
Create a new file, name it “editor_plugin.js” and paste your newly compressed JavaScript into it.

I'm adding my plugin in a InPlaceEditComponent instead of in a TextArea but the basics are the same. Add your plugin to the TinyMCESettings, add the settings to the component and then add your component to your page.

 
InPlaceEditComponent component = new InPlaceEditComponent("editable", "
<h4 class='headline' style='color: black; font-weight: bold; font-family: sans-serif; font-size: 80%;'>Insert headline here</h4>
 
" +
"<span class='standardText' style='color: black; font-family: sans-serif; font-size: 80%;'>Insert text here</span>");
 
TinyMCESettings settings=component.getSettings();
 
BoldMakerPlugin boldMakerPlugin=new BoldMakerPlugin();
settings.add(boldMakerPlugin.getBoldMakerButton(), Toolbar.first, Position.before);
 
component.add(new InPlaceEditBehavior(settings, component));
item.add(component);
 

If you've done everything correctly you should now be able to run your application and get your very first plugin working.

One area that, in my opinion, could still be improved is the development environment. It may be a heck of a good build system Liferay has come up with, but at the bottom line it takes time to learn it and to just start studying it you easily become a bit uncertain. It consists of homegrown ant scripts. To have a flatter learning curve for newcomers Maven 2 might be suitable.

Anyway, I sat down one evening some time ago and looked into how Maven 2 could be used for creating Jsp Portlets for Liferay. Some hours later the work had resulted in a new archetype for creating Liferay Jsp Portlets.

The structure and content of the standard Liferay Jsp Portlet can be viewed here.

So, what did I do?

1. I followed these instructions to manipulate the Jsp Portlet part of Liferay's plugin SDK into a maven archetype:

http://maven.apache.org/guides/mini/guide-creating-archetypes.html

This involved editing these property and xml files:

liferay-plugin-package.properties
name=${artifactId}
module-group-id=liferay
module-incremental-version=1
tags=
short-description=
change-log=
page-url=http://www.liferay.com
author=Liferay, Inc.
licenses=MIT

portlet.xml
<?xml version="1.0"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd">
<portlet>
<portlet-name>jspPortlet</portlet-name>
		<display-name>${artifactId}</display-name>
<portlet-class>${groupId}.JSPPortlet</portlet-class>
		<init-param>
			<name>view-jsp</name>
			<value>/view.jsp</value>
		</init-param>
		<expiration-cache>0</expiration-cache>
		<supports>
			<mime-type>text/html</mime-type>
		</supports>
<portlet-info>
			<title>${artifactId}</title>
			<short-title>${artifactId}</short-title>
			<keywords>${artifactId}</keywords>
		</portlet-info>
		<security-role-ref>
			<role-name>administrator</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>guest</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>power-user</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>user</role-name>
		</security-role-ref>
	</portlet>
</portlet-app>
 

to insert ${artifactId} and ${groupId} for the portlet name and package structure. These files are part of the file list finally being wrapped up within the archetype and used to generate the resulting portlet from Maven 2.

2. I ran 'mvn install' on that particular archetype to have it installed in my local repository.

3. I used the archetype to create a new Liferay Jsp Portlet artifact:

mvn archetype:create -DarchetypeGroupId=com.liferay.maven.archetypes.portlet.jsp
  -DarchetypeArtifactId=liferay-jsp-portlet
  -DarchetypeVersion=1.0-SNAPSHOT
  -DgroupId=[my.package]
  -DartifactId=[MyFirstLiferayJspPortlet]

4. I stepped into the artifact and ran 'mvn install' on it which generated my MyFirstLiferayJspPortlet-1.0-SNAPSHOT.war.

5. I then uploaded the war file to my portal instance via the Liferay admin GUI Plugin Installer.

6. Et voila. It worked, showing up in the portal.

And of course, worth mentioning, to have a development environment up and running in eclipse in seconds this is all you have to do:

1. mvn eclipse:add-maven-repo -Declipse.workspace=[full-path-to-workspace]

2. mvn eclipse:eclipse

To have the archetype play with the existing build situation of Liferay it would probably need to be generated from some ant target and be based on the portlet template in subversion located at "plugins/tools/portlet_tmpl/" to have it follow updates of Liferay.

Here you can download the final result, as a zipped archetype.

If a generated archetype like this was to be uploaded to a public maven repository, working from above point #3 and down is what would be necessary for a developer to have a project and all the necessary property and xml files (correctly edited with package structures and all) in place for a Liferay Jsp Portlet development environment. It could at least become a complement to the Plugins SDK. And yes, it could for sure still be enhanced. For example, there is no JSPPortletTest class generated for the JSPPortlet class.