I apologize for the delay in getting this out, but I ended up breaking the ability to post in XBlog. I've actually had this post written for a week or so, but just couldn't get around to fixing my blog. But in the last installment we left off with a configured development environment and a basic definition for our custom component. In this installment we'll build our custom renderer. The theory around all the different parts of a component is that the component class (what we built in the last installment) is an object that Java can work with. It defines all of the properties and methods of our component and if necessary any children this component may have. The renderer defines what the component will look like in the browser.  Any markup you want sent to the browser is defined in the renderer. So, let's start putting together our renderer class.

We now need to create a new class in our com.keithstric.renderkit package. We'll name it CommonContactInfoRenderer and in the Super Class field add javax.faces.render.Renderer. The class name isn't really important, but just for simplicity and maintainablity sake I always name my renderer like ComponentClassNameRenderer. This makes it easy to know which renderers go with which components. Also, our renderer doesn't need a constructor, all we need is encodeBegin, encodeChildren and encodeEnd methods and then any helper methods we may need. So, let's go ahead and define our encodeBegin method.

	@Override
	public void encodeBegin(FacesContext context, UIComponent component) {
		try {
			super.encodeBegin(context, component);
			ResponseWriter writer = context.getResponseWriter();
			writer.startElement("fieldset", component);
			writer.writeAttribute("class", "ContactFieldset", null);
			writer.startElement("legend", component);
			writer.writeAttribute("class", "ContactLegend", null);
			writer.append("Contact Information");
			writer.endElement("legend");		
		} catch (Exception e) {
			e.printStackTrace();
		}
	}

As you can see in this method we're just basically building HTML for a field set. We're using the ResponseWriter to do this. Basically the ResponseWriter is just a fancy String builder but with enough intellect to know what HTML tags to output based on what you tell it you want. I'm not absolutely sure, but I believe if you miss closing something, the response writer will even close it for you, but don't quote me on that. But we start our field set with ResponseWriter.startElement, this will create a <fieldset> tag for us. The writeAttribute method will add html attributes to the previously defined element (i.e. the field set). We then add a legend to the field set and that's it for encode begin.

The next method we need to be concerned with is encodeChildren. This method will encode and render any child components that may be present with our main component. For the most part, you can always leave this as "super.encodeChildren(context,component)" but if you need to touch each child of a component to add a property or perform other logic, this is where you would take over rendering of the children to do that. If you are so inclined, take a look at the FacesUtil class in the extension library and specifically the renderChildren and renderComponent methods. Also of note with encodeChildren, all of the fields associated with this component are children of this component. This is where the table, fields and labels will be rendered. Since they know how to render themselves, we don't have to do anything. Also, the addition of the child components required a change to the original component which we'll get to in a moment.

Lastly is the encodeEnd method. This is where we'll close any tags that we opened in encodeBegin or even encodeChildren. However, defining HTML in encodeChildren is generally bad practice as each child should know how to encode itself. So our encodeEnd will be:

	@Override
	public void encodeEnd(FacesContext context, UIComponent component) {
		try {
			super.encodeEnd(context, component);
			ResponseWriter writer = context.getResponseWriter();
			writer.endElement("fieldset");
		} catch (Exception e) {
			e.printStackTrace();
		}
	}

And that's it for our renderer. We should end up with:

package com.keithstric.renderkit;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
import javax.faces.render.Renderer;

public class CommonContactInfoRenderer extends Renderer {

	/**
	 * Here is the common encodeBegin method. This method is present in almost all renderers
	 * This is where we'll start opening tags and do anything that needs to be done before
	 * we start rendering children of the component.
	 */
	@Override
	public void encodeBegin(FacesContext context, UIComponent component) {
		try {
			super.encodeBegin(context, component);
			ResponseWriter writer = context.getResponseWriter();
			writer.startElement("fieldset", component);
			writer.writeAttribute("class", "ContactFieldset", null);
			writer.startElement("legend", component);
			writer.writeAttribute("class", "ContactLegend", null);
			writer.append("Contact Information");
			writer.endElement("legend");		
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
	
	/**
	 * Here is the encodeChildren method. This method is present in almost all renderers.
	 * This is where you can wrap logic around the rendering of children or completely take
	 * over the rendering of children in order to add additional properties or whatever.
	 */
	@Override
	public void encodeChildren(FacesContext context, UIComponent component) {
		try {
			super.encodeChildren(context, component);		
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
	
	/**
	 * Here is the encodeEnd method. This method is present in almost all renderers.
	 * This is where you close any tags you opened in encodeBegin and perform any
	 * logic that may be necessary after the children are encoded
	 */
	@Override
	public void encodeEnd(FacesContext context, UIComponent component) {
		try {
			super.encodeEnd(context, component);
			ResponseWriter writer = context.getResponseWriter();
			writer.endElement("fieldset");
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
	
}

During the course of writing this blog post, I had to make massive changes to the original component. My initial idea was to have this component store the values for the different fields that will be present within the component. However in practice, this is not practical and just produces more work than necessary. Plus, we've got a data source for that.  So click the "read more" link below to see the changes I made to the component.

Recent Blog Posts

180

Mobile First Development Fri, May 10th 2013 9:06a Keith Strickland At Red Pill Development, Peter Presnell has encouraged our development efforts to use a "Mobile First" approach. The process is that you design your mobile interface first, get everything working properly and then move on from there to Tablet and then Web Browser interfaces re-using as much as possible from the previously working mobile implementation. This approach has several advantages: It forces you to research, gather requirements and only display and write code for the things you [read] Keywords: application development interface mobile properties widgets

452

Announcing redpill Mobile Wed, May 8th 2013 2:48p Keith Strickland Have you ever had a dream that you were so sure was real? Well today is the first step in realizing that dream. A few months ago I made a post about being one of the co-founders for a new company called Red Pill Development. This company was founded on the controversial belief that modernizing Notes applications one at a time by reproducing all of the existing functionality is a loosing strategy. In order to turn a profit modernizing applications, you have to do so en-masse and only include [read] Keywords: lotus notes notes client applications bleedyellow bleedyellow.com development mobile office

152

Dojo Mobile ScrollablePane implementation Sun, Apr 21st 2013 3:06p Keith Strickland At Red Pill Development we're pushing the envelope a bit on XPages Mobile, we're certainly pushing the mobile controls to their limits. Because of this sometimes we need to take matters into our own hands and override the XPages Mobile controls and kind-of take over how they operate or create our own. One of the things you're going to encounter when you delve into XPages Mobile development is trying to put a Tab Bar at the bottom of the screen that actually stays at the bottom of [read] Keywords: domino xpages development dojo javascript mobile properties xml

196

XPages and Dojo Mobile Events Tue, Apr 2nd 2013 12:02p Keith Strickland Here lately, I've been working on getting events to fire within a mobile application in XPages. For example when a page first loads (i.e. is navigated to but not "transitioned" to) or when a transition/navigation to another page within the single page application. No events are published or made available via the domino designer IDE but we still need to be able to do something when a navigation/transition event happens. So, how do we do this and what are the event names? Well the dojo even [read] Keywords: domino xpages application applications dojo java javascript mobile openntf server

178

Add unsupported events to an inputText Mon, Mar 25th 2013 8:42a Keith Strickland So today while looking for a solution to handling an HTML5 event of onSearch I came across this technique, which, probably isn't the best approach but does work. So, if you look at the client side events of an inputText field, you'll notice there isn't an event for onSearch. So, how do you add one? Well, you could of course go pass-thru html and just code the field as you would a Plain Jane HTML field. While this would work, to me it's just not taking advantage of the platform an [read] Keywords: javascript xml

437

JQuery FullCalendar in XPages Sun, Feb 17th 2013 4:18p Keith Strickland As you might or might not have known, I've been striving for a calendar in XPages since XPages were introduced. I created the XPages Calendar project which was a poor attempt at building a calendar. When I built it the extensibility API was not available and neither was the Extension Library. So, while it basically worked, it was not a very elegant implementation, especially the data handling. I recently had a need for a calendar implementation that met a few different criteria: [read] Keywords: xpages interface javascript mobile

460

Wouldn't it be cool if.... Sun, Feb 17th 2013 12:25p Keith Strickland Wouldn't it be cool if we could integrate some off the wall feature into our XPages environment? This is a phrase that gets used quite a bit in the team I work with and I think is a key driver to innovation, discussion and a source of producing excitement about whatever followed that phrase. While the phrase itself isn't very awe inspiring or really doesn't mean that much, I do think it is a key player in driving innovation. Some examples if you please.... Wouldn't it be [read] Keywords: domino notes xpages application applications development java

509

A Request to IBM Tue, Feb 12th 2013 4:36p Keith Strickland I've been doing a lot of development work here lately, I mean a lot. Looking at different technologies and implementing them into XPages or at least attempting to. One of my tasks was trying to learn about OAuth and working with connections. I downloaded and installed the IBM Social Business Toolkit and SDK. I then followed several tutorials out on the web (most of them from IBM) trying to authenticate to GreenHouse with no luck. I ran into issue after issue. I got it all the way to being as [read] Keywords: connections ibm xpages development

106

keithstric.com moved back to Prominic Thu, Jan 3rd 2013 5:54p Keith Strickland I am proud to announce that keithstric.com has been moved back to Prominic. Prominic is an excellent host for all types of domino sites. If you're in the market for a new web host, take a look at Prominic. Their service and support is top notch and second to none. I've learned my lesson and won't be moving this blog again. Now, I've just got to get all the different aggregators looking at keithstric.com instead of xprentice.gbs.com. [read] Keywords: domino

486

D3.js - Data Driven Documents Sat, Dec 15th 2012 10:45a Keith Strickland I've recently started playing with a very powerful Javascript library called D3.js. D3 is for visualizing data either in charts, force layout graphs, data plots or whatever you can imagine. I'm not really sure what the point of this post is as I really can't show you yet what we're using it for. But I can show some of the things that it's capable of. Let's first look at a Force Directed Layout. These are usually used to show hierarchical data and the way D3 handles [read] Keywords: community facebook javascript wiki