In order to create a link to a file or image component in the WCM repository, there is a 4 step process.

1. Create a renderer
2. Set the default context on the renderer to a site area.
3. Render out a link tag that references the component.
4. Get the actual desired url using a regex

The code which you can use as a starting point for doing this is included below:

//create a renderer
workspace.createRenderingContext(
    portletRequest, portletResponse, Collections.EMPTY_MAP);
//set the rendered content to a site area
renderingContext.setRenderedContent(siteArea);

//render the component (which will create an a tag)
String linkToComponent = workspace.render(
    renderingContext, fileOrImageComponent);

//get the url for the component (using the below code)
result = getUrl(linkToComponent));

//regular expression that can be used to refer to the rendered link
public static final Pattern IMG_SRC_PATTERN =
        Pattern.compile(
        "<\\s*img\\s[^>]*src\\s*=\\s*\"([^\\\"]*)(\")[^>]*>");

//used a regex to get the url for the component
String getUrl(String url) {
	String result = "";
	Matcher matcher = IMG_SRC_PATTERN.matcher(url);
	boolean found = matcher.find();

	if (found) {
		result = matcher.group(1);
	}
	return result;
}

Editor’s Note: From time to time while developing with IWWCM, we discover useful gems of knowledge that we think everyone working with IWWCM should know, even if they don’t relate directly to our products. This is one of those nuggets of wisdom that we’d like to share.

IBM Workplace Web Content Management (IWWCM) Version 6 provides a variety of different searching options. These are discussed in the Best practices for using IBM Workplace Web Content Management V6 document, and from a high level are: 

• Workplace Web Content Management API
• WebSphere Portal Search, and 
• Third-party search product

Workplace Web Content Management API

The IWWCM APIs do provide a limited search API. Before investing time in building a search using the APIs, the following points should be considered:

• there is some degree of reinventing the wheel, as the WebSphere Portal Search, and third party search products already provide search.
• the APIs do not provide full content search, instead searches are performed using the Document Ids of meta data (siteAreaIds, categoryIds and keyword ids).

WebSphere Portal Search

Publishing IWWCM Content to the portal search system and integrating this with your WCM system is not immediately obvious, but is explained in the WCM Infocenter.

To make this work you will need to follow steps outlined in the infocenter. Your content will then be regularly crawled by the portal search service, and included in the collections that you have set up. This allows fine grained control on search, including web content in which ever search collections are relevant.

A potential advantage of using this approach is the availability of the content through the Search and Indexing API (SIAPI). This may not work in all portal configurations, and may require troubleshooting to enable.

Third Party Search

A number of third party search options are also available, including IBMs OmniFind, and LuciFind.  These will provide rich search functionality, but require additional purchases, and may have some integration overheads.

Conclusion

There are three main different search options available with IWWCM. The WCM API option is not recommended to be used as it provides limited search options, and requires development of a custom search engine.

The Portal search API will often provide enough search functionality, but it is somewhat limited in the options available, and so a third party search may be required (as noted on this Developer Works forum thread).  While the WCM API provides some search functionality it is not recommended.  The Portal search API is worth considering as a starting point, as it is straight forward to integrate and deploy.  If it does not produce the desired results, a third party search should be used.

Editor's Note: From time to time while developing with IWWCM, we discover useful gems of knowledge that we think everyone working with IWWCM should know, even if they don't relate directly to our products. This is one of those nuggets of wisdom that we'd like to share.

IBM Workplace Web Content Management (IWWCM) Version 6 is a true enterprise content management system. It integrates with WebSphere Portal 6, leveraging many of the features provided by portal, providing a huge number of configuration options, and different ways to set up your system.

IBM has produced the useful document Best practices for using IBM Workplace Web Content Management V6. This document has provided useful guidance when working through the next generation of Ephox software that will interact with IWWCM. We have found it to be a useful resource that provides helpful information for working with IWWCM (not just because they recommend using EditLive! for IWWCM).

EditLive! does an excellent job of producing standards compliant XHTML, and HTML.  The output can be configured using a large range of configuration options, however from time to time you may want to control the HTML that is generated by EditLive!  There can be many reasons for wanting to do this, from the simple cases of wanting to have control over formatting, to cases where custom HTML tags are used (like in some CMS).

It is possible to step outside the constraints of the configuration file, and take advantage of the Advanced APIs to write a custom source filter to be used with EditLive!.  A source filter makes it possible to change the HTML that works with EditLive!, either when the HTML is coming out of the design view, or when the code is going into the the design view.

The SourceFilter is a simple Java interface, with two methods:

filterIn (filter html going into the design mode of EditLive!)

filterOut (filter html going out of the design mode).

These methods both have a single string parameter (the html text) and return a string (the output html).

The Simple Source Filter java class contains a simple source filter implementation that minimizes the amount of space that list items take in the output.  This is done with a regular expression.

The code in this filter changes:
<li>
    hello
</li>
to:
<li>hello</li>

This example (and others) can be installed and run using the Ephox Plug-in architecture (described in this liveworks article).  As source filters work early in the documents lifecyle they should be loaded using the early loading option.

The source filter plugin.xml would look something like this:

<?xml version="1.0" encoding="US-ASCII" ?>
<plugin load="early">
  <advancedapis
    jar="SimpleSourceFilter.jar"
    class="com.ephox.example.SimpleSourceFilter" />
</plugin>

It assumes that the SimpleSourceFilter class has been compiled and put into the SimpleSourceFilter jar file.

Ephox EditLive! can be integrated seamlessly into ASP.Net applications with the use of the ASP.Net server control. This control was designed for use with ASP.Net 1.0 and 1.1, and with the release of version 6.1 of EditLive! this control supports ASP.Net 2.0. This has now been thoroughly tested, with some constraints identified. The constraints are listed below. 

As EditLive! is an HTML editor, it will need to be able to edit HTML, and send HTML text back to the server. This means that the .net request validation functionality will need to be disabled through setting the property validateRequest="false" in the page (through the Page directive: <%@ Page validateRequest="false" …%>). 

The server side code behind view exposes the EditLive! content through properties on the control. It is possible to access content at any stage in the life cycle through these attributes. Updates to content will only be visible in the control when they are made before rendering the applet. This means that content updated in the Page_Load event will be correctly reflected, but changes made in the event handlers for form events will not be reflected in the client control. In order to update content on a form event, the JavaScript APIs for EditLive! will need to be used. 

In order to use multiple instances of EditLive! the "AppletName" of each control will need to be initialised in the Page_Load event. Each applet name should be set to a unique value, which can then be used to access content in the postbacks. A useful value for the applet name is the name of the control.

This article briefly takes you through how to rapidly integrate EditLive! into your application. A textarea in a page is replaced with EditLive! (source for the starting page available here — right click and save as in IE to view the source). The name of the text field we are replacing in this example is "web_content".  The form in the page submits to a basic debugging page (source available here). To skip straight to the ending, you can see the resulting html.  To see the simple four steps, start now.

Step 1) Register and Download the EditLive! (http://www.ephox.com/products/editlive/download.html).

Step 2) Copy the editlivejava redistributables to your server to a folder called editlivejava (if you downloaded the zip package you will find this in editliveforjava/webfolder/redistributables/editlivejava)

Step 3) include the EditLive! javascript source in your html page:
<script type="JavaScript" src="editlivejava/editlivejava.js"></script>

Step 4) Create a script block to create and setup an instance of EditLive!, a simple construction would consist of:

• create an instance of edit live called web_content with a height of 600 and a width of 550 pixels:
  var editliveInstance = new EditLiveJava("web_content", 600, 550);
• set the download directory (the location where the jar file containing the applet lives)
  editliveInstance.setDownloadDirectory("editlivejava");
• set the content for the editor (encoding it so any html will carry across happily):
  editliveInstance.setBody(encodeURIComponent("text for the content"));
• set the configuration file (start with the sample one).
  editliveInstance.setConfigurationFile("editlivejava/sample_eljconfig.xml");
• display the applet
  editliveInstance.show();

This will produce a simple integration of the EditLive! editor into your web page. The contents of the body will be available in the field web_content.  It is then possible to update the configuration file to take advantage of the large number of customisation options available.