Composite pattern

InfoGlue implements the composite pattern which means that a page can be built up of small fragments. The composite pattern is implemented so that a component can have so called “Slots” in it. It can have any number of slots and in each slot you can then put 0..n other components. You can have any number of compositions which means there is no limits to what you may do.

Creating a component

You create a new component just by creating a new content in the content tool with the content type “HTMLTemplate”. The old templates from the old way of building are actually just as good components as new ones except that they don’t operate on component-bindings but only on page-bindings if you don’t modify their logic.

When you have created a component and added the HTML to the language version you want you should also create any slots needed, categorize it and set up its properties if needed.


A slot is as previously stated a place holder for other components. You don’t need to do much to create a slot. Just add the tag <ig:slot id=”slotname”></ig:slot> to the component html at the position you choose. There are a couple of optional attributes to the slot-tag: inherit, disableAccessControl, addComponentText, addComponentLinkHTML, allowedNumberOfComponents,  disallowedComponentNames and allowedComponentNames. Inherit is used to state if the slot should be inherited to pages below (if not overridden) or not. The allowedComponentNames and disallowedComponentNames attribute allows you to specify a list of component names that are allowed not allowed in this slot. Here is a full example:

<ig:slot id="rightColumn" inherit="false" allowedComponentNames="PuffImage,Related Info,Searchform"></ig:slot>

Special tags

There is a tag for printing out the last modified date of a page. The date is the last modified date of all content on the page. Here is the syntax:

<ig:lastModifiedDateTime format="yyyy-MM-dd HH:ss"></ig:lastModifiedDateTime>

Properties & bindings

One of the main benefits of components compared to other systems where you are limited to jsp-files on disk or similar is that they can have properties which controls their behaviour. This means that an instance of the component on one page can have different settings than the same component located on another page or on the same page for that matter. This enables developers to write very dynamic and reusable components if needed. The users can configure their sites rather than having developers helping them all the time.

You define properties in the attribute field “ComponentProperties” in the HTMLTemplate-content you create for each component and the format is XML. Don’t worry – there is a property editor built in so you don’t have to hack away but it has to be turned on.

Below is an example of the dialog of one property when you use the property editor. Let us go through the fields:

Here is an example of a component property dialog in edit on sight for reference (not the same component as above):

Note: Under advanced properties some standard properties can always be found. They are not defined here.

Description of fields in component editor:

Name: Represents the internal name you want to use in the template to get the property. Also what the user in edit on sight sees if Display name is left empty.

Display name:This is the name the user see.

Description:This is a text which is shown if you mouse over the question mark icon.

Default value (only applicable for non-bindings):Let’s you set a default value if not set by user.

Property type:Most important – defines what kind of field should appear. The available are:

  • Binding – used to bind 1..n content(s) or page(s).
  • Textfield – simple textfield.
  • Textarea – simple textarea – with or without WYSIWYG.
  • Select – select / drop box field.
  • Checkbox – 1..n number of checkboxes.
  • Datefield – let’s you allow users to select a date.
  • Customfield – this allows you to insert you own HTML markup which means you can add anything including javascript logic. 
  • Enable WYSIWYG (only applicable if textarea is shown): Enables the.

Toolbar (only applicable if textarea is shown and Enable WYSIWYG is true):  Let’s you select which toolbar to show.

Entity (only applicable for binding-type property):State if it’s a binding to a content or a page/sitenode.

Multiple (only applicable for binding-type property):State if it’s a binding to one or many of choosen entity type.

AssetBinding (only applicable for binding-type binding and entity=content): State if the property is a digital asset. Shows a different dialog.

Puff for page (only applicable for binding-type binding and entity=content):  This is a little special. It was developed for users who want for example to reuse an article bound on a subpage for a startpage or similar and want a link in that component to automatically find the subpage where the contents main location is and link there. Having this set to true the property will handle if the bound content exists on several pages with dialog options.

Allowed content type(s) (only applicable for binding-type binding and entity=content):  Let’s you limit what kind of contents can be bound.

Auto create content (only applicable for binding-type binding and entity=content):  If set to Yes the component will automatically create and bind a content to the property. This is very useful if you want to simplify for your users. With this they will not have to know much about the content tool or content structure.

Auto create content method (only applicable if Auto create content=true):  State where automatical content should be placed. We recommend Mimic site structure.

Auto create content base path (only applicable if Auto create content=true):  Let’s you state a base path before the site structure mimic kicks in. Example /Autoarticles

“Data provider class” and “Data provider parameters”(only visible for select-box and checkbox):

These fields let you provide a custom class (and parameters if needed) for fetching the option for the dropdown or checkbox. This is great for example if you have made a nice integration component and want the user to be able to configure the component with options fetched from the external system.

One standard class has been included in InfoGlue so far and it works with simple xml over http so it’s very easy to expose your configuration options that way:

  • org.infoglue.deliver.integration.dataproviders.RemoteXMLPropertyOptionsDataProvider

and it takes these parameters in the Data provider parameters”-field

  • serviceUrl=;charset=iso8859-1

The return of your service should be a simple xml structure like this:

  <property name="Open Lecture" value="openLecture"/>
  <property name="Performance" value="performance"/>
  <property name="Concert" value="concert"/>
  <property name="Exhibition" value="exhibition"/>
  <property name="Lecture" value="lecture"/>
  <property name="Conference" value="conference"/>

Allow multiple selections (only visible for select-box):

Let’s you state if the user should be able to select more than one option in the selectbox.

Custom markup (only visible if you choose type customfield): As said before you can set any markup you want including javascript. The only worry you have is to set the correct name for save and fetch of the values you set. To make it persistent your value has to be able to serialize as a string in an field of some type. The field should be defined with the name propertyName which will be automatically translated by infoglue to correct id. To get the previous saved value you just use “propertyValue” which will be replaced by the saved value by infoglue. Look at a simple example below of custom markup:

<div style="border: 1px solid red; width: 200px; height: 100px;">Example<br/><a href="javascript:alert('Test')">Test</a>  <input type="text" class="propertytextfield" name="propertyName" value="propertyValue" onkeydown="setDirty();"> </div>

Component caching

When it comes to component caching it's not all that hard. The reason for the mechanism is of course to be able to boast performance on partly dynamic pages. First you have to turn off the page caching on the page or the pages you wish to keep partly dynamic. Then you add a few properties to the components you wish to cache.

If you have a menu component which you want to cache you enter the advanced properties on that component. The cache-related properties are:



Possible values:"true" / "false"

Description:If you set this to "true" the component will be cached until either it expires or a new publication is made. Subcomponents will also be cached with it.



Possible values:-1 and up.

Description:If you have the CacheResult property set to true and you set this to a positive number the components result will be cached for as many milliseconds. 



Possible values:Works like the page cache key and defaults to the same key. Use this with caution. It's optional.

Component tasks

In InfoGlue’s structure tool we have shown that there is a context sensitive environment which we call “Edit On Sight”. The right-click menu is not limited to the items in it actually but can be extended with component-specific tasks.

To use this you define an attribute field called “ComponentTasks” in the HTMLTemplate-content-type and for each component you wish to add context menu items for you set an xml in that field:

<?xml version="1.0" encoding="UTF-8"?>
<task name="Create subpage" openInPopup="false" view="$componentEditorUrl/CreateSiteNodeWizardFinish.action?repositoryId=$repositoryId&amp;parentSiteNodeId=$siteNodeId&amp;languageId=$languageId&amp;componentId=$componentId&amp;propertyName=dummy&amp;refreshAddress=$originalFullURL"/>

The example above is taken from a menu component and the task let’s the user rightclick on the menu and select an menu item called “Create subpage” which with this configuration will start a wizard which creates a new subpage to the page the user is currently watching and then returns to the page again. Very nice if you want to empower the users without letting them into the main tools.

Intercomponent communication / data sharing

There is a need on most advanced sites to be able to share data between different components. As a simple example one might for example want a related info component pick up information that the main area component has knowledge of or affect the page title with some subcomponent data.

There are some possibilities already in InfoGlue but they are either that you can read other components properties or if subcomponents wants to read a parent components shared data. Before 2.9 anything else was impossible.

Since 2.9 there is a new solution. The solution is based on that every component can have a preprocess phase if wanted. If a component has a PreTemplate it (and all other components PreTemplates) will run first in the preprocessing phase where they will be free to put data into the page context for the normal presentation templates to read. Before the preprocessing all components on the page with a PreTemplate is ordered in any sortorder defined in advanced properties on each component. The PreTemplate can do anything the normal Template can except print to the browser so you should consider it the dataprocessing part and not a presentation part.

After the PreTemplate-phase the normal rendering is run just like earlier but now you can use the shared data now.

How it looks

Here is an example of how it looks at the different states when you create a simple component: Create a new content with the content type HTMLTemplate.

The form for this content type looks like this:

The lowest field “ComponentProperties” is important and the editor for properties can be launched by clicking the “Edit properties”-link. If you wish to see the XML press the Plain-link. If you open the editor you will see this:

Hopefully the editor is rather self explanatory although it has some usability flaws.

Component description and thumbnail

Since InfoGlue 2.6.0 we have added a possibility to add a description and a thumbnail for components. It’s all optional of course but could be nice for end users. The info is shown like this when adding components to a page (compare the AK Article Box component which is supplied with another thumbnail and a description with the other components):

To add a description just add a content type attribute called “Description” on the HTMLTemplate content type. Then enter a description for those components you want to have a description for in the gui above.

To add a thumbnail just attach a normal image with the asset key called “thumbnail” to the component content.

Custom logic

Since 3.0 we have added a new possibility on each component. It consists of a field called ModelClass which allows you to state a custom java-class which can be used to handle requests and prepare data for the component rendering. Read more on this in the integration section.


The component example shown above is JSP-based. You can develop components in JSP, Velocity or Freemarker in InfoGlue 2.3. The system recognizes JSP-templates on its own and let’s tomcat compile them. You can of course write scriptlets which uses the BasicTemplateController as you do in velocity but an even more elegant solution is to use the many taglibs supplied with InfoGlue. Last in this document is a full reference documentation to the tags including examples of how to use them. This is from 2.1 the preferred way to build templates / components in InfoGlue although the other techniques will be supported and developed as well.

When it comes to Velocity and its close relative Freemarker there are two API:s to be aware of when it comes to components. You will want to use the $templateLogic-object a lot probably as it contains many good utility methods. Also you want to look into the new $templateLogic.componentLogic-object as that contains most of the methods you need for the component specific stuff.

comments powered by Disqus