Fish4 / FinnTech iAd

Site builder’s toolbox

Version 1.0

FINNtech AS
Written date: 10.12.04
Written by: Henry Chuks & Roar Johansen
Version: 1.1
Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

Revision History
Date Version Description Author
30.01.2004 0.1 Initial document Roar Johansen
02.06.2004 0.2 Added sections on RJ + Henry Chuks
configuration and templates.
Minor layout fixes.
06.08.2004 0.3 Updates on addressing RJ + HC
structures.
10.10.2004 1.0 Renamed to “Site builder’s RJ + HC
toolbox”
Amended according to newly
developed tags.
10.12.2004 1.1 Revised, added an overview HC
chapter plus a mail chapter

FINNtech AS Site builder's toolbox.doc Page 2 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

Contents
1. PURPOSE OF DOCUMENT 4

2. GENERAL 4

3. OVERVIEW - WHAT CAN THE TOOLBOX DO? 4

3.1. THE BASIC SEARCH CRITERIA OF A SITE 4
3.2. THE LOOK AND FEEL OF A SITE 4
3.2.1. The template personality 4
3.2.2. The business personality 5
3.2.3. Graphics profile personality 5
3.3. SEARCHING AND SEARCH CRITERIA 5
3.4. MAIL CONFIGURATION 6
3.5. SUMMARY 6
4. CONFIGURATION OF A LOCAL SITE 7

5. TEMPLATES 7

6. TAG LIBRARIES EXPLAINED 8

6.1. FIELDS 8
6.2. ADDRESSING SCHEME 8
6.2.1. Scope 9
6.2.1.1 ”Parameter” scope 9
6.2.1.2 ”Attribute” scope 9
6.2.1.3 No scope defined 9
6.2.2. Object 9
6.2.3. Field 9
6.3. PROGRAMMER’S SUMMARY OF ADDRESSING SCHEME 9
7. TAGS IN THE AD CONTEXT 10
7.1. THE TAG SPECIFICS 10
7.1.1. Testing (conditional) tags 10
7.1.2. Output tags 11
7.1.3. Input tags 11
7.1.4. Repetition tags 12
7.1.5. Formatting tags 12
7.1.6. Grouping tags 12
7.1.7. Navigational tags. 13
8. EXAMPLES 13
8.1. RESULT LIST PAGE 13
8.2. DETAIL PAGE: 14

FINNtech AS Site builder's toolbox.doc Page 3 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

1. Purpose of document
This document is intended as an aid for creators of “Local sites” in an iAd application.
It describes the concept in general terms, specifies the necessary tags in general, as well as in
the specialized context of an ad or collections of such, and finally gives examples of how to use
the tags. In fact, the term “Local site” is a subset of anything that comprises a full-blown iAd
site. Hence, the name of this document is “Site builder’s toolbox”, since the tags apply also to
building a main site.

2. General
A Local site (and a “Client site”, for that matter), is a subsidiary web site being served off an
iAd based web site’s server(s). It is capable of presenting ads pertinent to a sub-organisation via
a slightly different URL, and possibly presented in a “look and feel” adapted to the Internet
profile of the sub-organisation itself. Local sites will normally be branded according to a
newspaper’s profile, and client sites may (but not necessarily will) be branded according to
organisations that are subordinated to a Local site owner.
For this purpose, an iAd application comes with a comprehensive library of JSP (Java Server
Pages) “Tags”. JSP tags look very much like ordinary HTML tags, but will invoke dedicated
code in the iAd application in order to perform various tasks, i.e. retrieving values of various
fields in an ad, applying formatting, testing for presence of fields, etc. Altogether, the iAd tags
along with regular html tags, provide a set of “tools” (hence the term “toolbox”) for creators of
dedicated JSP pages.
However, some additional knowledge is required in order to utilize the iAd tags to their full
potential. This document sets out to provide this knowledge.

3. Overview - What can the toolbox do?

This chapter provides an overview of the functionality that is available for the site builder.
The following items may be subject to alteration when creating a sub-site to an iAd based main
site:

3.1. The basic search criteria of a site

• The organisation’s catchment area
• Whether searches are confined to the organisation’s own ads
• Whether searches are confined to the organisation’s catchment
These properties are configured using the Admin Tool (AT). Configuration of a site in AT also
gives the site an identifier (site id), as well as the id in association to the owning organisation
(the org id).

3.2. The look and feel of a site

The look and feel of a site is determined by its “personalities”. A site can assume a personality
in 3 different aspects:

3.2.1. The template personality

Templates are JSPs that provide the ”graphical framework” to the business JSPs (see below).
Template JSPs must be created prior to configuring a local site, or an existing set of template
personalities may be referenced.

Templates make up most of the look and feel of a site, in the sense that they will carry banners,
menus, static information, etc. A personality is a folder holding a structure of JSP folders and
files, the folders/files follow the naming convention of that of the “main site”.

Assigning a personality is part of the site configuration, see below.

FINNtech AS Site builder's toolbox.doc Page 4 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

3.2.2. The business personality

Business JSPs are those JSPs that carry ad related information to and from the database using
the “toolbox contents”, i.e. the tags explained later in this document. They “snap” into the
corresponding templates at run-time, thus composing an entire html page for presentation in a
browser.

Business personalities are, as for template personalities, folders of equal structure, but with
contents differing from, the main site. Again, the files must be created first, using the “toolbox”,
or an existing personality folder may be referenced. For instance, the main site’s JSPs may be
referenced, or a “white labelled” personality. The term “white label” suggests what this is: A
copy of the main site’s business JSPs, residing in a separate folder, and stripped of any main site
specific contents, such as names, specific graphics, etc. A fast track to creating a local site may
be to create a template reflecting the “emulated” main site’s look and feel, and referencing this
white labelled set of pages.

Assigning a business personality is part of the site configuration, see below.

3.2.3. Graphics profile personality

A graphic personality consists of two items:
• Graphic files, being part of the user interface (e.g. button face gif’s, coloured bars,
rulers, etc.)
• Style sheets (CSS) which assign values to presentation specifics such as fonts, colours,
etc.
These to together comprise a graphics profile.

A graphics personality is a graphics profile stored in a separate folder, following the naming
convention of the main site.

A sub-site’s CSS is submitted to a browser AFTER the main CSS is presented, thus, it may be
used to override corresponding classes/styles when necessary.

The main site’s graphics may be referenced if it is sufficient for the needs of the sub-site;
otherwise it is necessary to create graphics for the sub-site and storing it in the personality folder
before using it.

Assigning a graphics personality is part of the site configuration, see below.

3.3. Searching and search criteria

The main site’s JSPs contain tags to define input fields/controls for all search criteria for a
specific search. If this is sufficient for a local site, then the main site JSPs (or the white labelled
ones) may be used. Keep in mind that a local site’s basic search criteria have already been
configured in the database (see above), so that any search criteria will apply only to the subset
of stored ads already selected by these basic criteria.

Should one wish to deviate from this pattern, e.g. by searching for only specific car makes, this
is possible, but requires an amount of work in advance to going live with such a site.

1. A full business JSP personality is required, since the main site’s JSPs are no longer
sufficient
2. The database must be examined for the identifiers of the required search criteria.
3. JSPs must be edited to cater for the altered search criteria.

The latter step is carried out by locating the part of the JSP in question which generates the full
search criteria, e.g. a “dropdown list box”, and replacing this with, using the toolbox tags, a
hidden field with the same field name, but with the located identifier from item (2) above as its
“constantValue”. This will act as a static search criteria to submitted searches, thus limiting the

FINNtech AS Site builder's toolbox.doc Page 5 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

searches. If you want to apply multiple ids to the search, simply specify a semicolon separated
string of identifiers as the constantValue.

A similar approach is possible if you want to limit the number of possible selections to a
dropdown (select) box. Locate the desired box in the JSP, remove the automatically generated
body of “option” tags, and manually add option tags instead, with values set to the identifiers
desired.

It is possible to alter the control used for selecting search criteria. For instance, you may utilize
radio buttons or checkboxes instead of dropdown/selects. This is just a matter of changing the
tags that comprise the control, with tags that create the desired control. For example, it is quite
feasible to substitute the following structure:

<input:select field=”somevalue”>
<iteration:repeat>
<input:option />
</iteration:repeat>
</input:select>

with the following:

<input:group field=”somevalue”>
<iteration:repeat>
<input:radio />
</iteration:repeat>
</input:group>

, thus creating an array of radio buttons instead of a dropdown select. The functionality of the
search remains unaltered.
(Please note that the supplied example is only an example, it reflects only the structure of the
tags and not their proper syntaxes.)

3.4. Mail configuration

A number of e-mails are issued by the system on different events. The document “E-mail
services” describes these events. It is possible to create personalities also for this purpose, in
order to “brand” emails as belonging to a different site than the main site. Please refer to the “E-
mail services” document for details on this, but consider the following:
An e-mail’s contents are composed from mail “templates”.
Templates are XML structured files residing in a folder on the web server.
A collection of templates comprise a mail “personality”, stored in a separate folder.
Templates are named consistently across personalities, but are edited with different contents.
“Tags” or “macros” are available to mail templates, as placeholders for dynamic contents, e.g.
prefix to the graphic personality (see above) selected for a site.

With these pointers in mind, it is possible to create and maintain mail templates and organized
them into personalities, for the purpose of sending differently looking mails from the various
sites (“branded” e-mails).

Assigning a mail personality is part of the site configuration, see below.

3.5. Summary
As can be found from the above paragraphs, the creation of a local site is basically a six-tier
operation:
1. Create the site in Admin Tool (AT) and assign the basic search criteria.
2. Create (or select for re-use) a set of templates
3. Create (or select for re-use) a set of business JSPs

FINNtech AS Site builder's toolbox.doc Page 6 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

4. Create (or select for re-use) a set of graphics and CSS files
5. Create (or select for re-use) a set of mail XML templates
6. Configure all the above into the suborg.properties file (see below), specifying
the proper database ids (site id, org id), the personalities assigned in item 2 through 5
above, along with other items to configure, see below.

4. Configuration of a Local Site

Being a Local site is one possible aspect of being a Sub-organisation to an iAd site owner.
Being a Client site is another aspect, but client sites are most likely sub-organisations to sub-
organisations of the main site again, and enjoy less capabilities of adding look and feel to the
site. However, these are the only differences between a local site and a client site.
Setting up for being a Local site or a Client site, is done in the iAd configuration file
suborg.properties which is located in the properties directory of an iAd installation.

The syntax for defining a sub-organisation, call it mysuborg, as a Local Site, is:
mysuborg.suborgType = 1
for a Local site, or
mysuborg.suborgType = 2
for a Client site.

An important part of configuring a local site, is “closing the loop” between the web tier and the
database tier, by specifying the database identifiers (the site id and org id) resulting from the
database configuration, into the suborg.properties file for all sub-sites.

For a complete overview of how to configure a site, please refer to the “iAd configuration
guide” document.

5. Templates

5.1. JSP templates

It is possible to define templates for a Local site which is set up to use its own JSPs. This is
achieved by the setting
special.ownJsps=Yes
in the configuration file. Thereby, a JSP named defaulttemplate.jsp (or a jsp designated
to any url) will be used as a “template” for JSPs presenting the business contents. The JSP tag
<template:includecontents/>
acts as a placeholder for the business contents in the template JSP.

It is possible to create a collection of templates, and refer to this as a “templatePersonality”. A

Template Personality may be assigned to any site, thus re-using templates for multiple sites.

5.2. Business JSPs

Business contents (JSPs for presentation of ads and lists of ads, etc.), may either be created
specially for a suborg site, or they may be shared with the main site, specified by the setting
special.shareBusinessJSPs=true/false
It is possible to create a collection of business JSPs, and refer to this as a “businessPersonality”.
A Business Personality may be assigned to any site, thus re-using business JSPs for multiple
sites.

5.3. Graphics
Likewise, graphic elements (gifs, etc.) may be created specially or shared, specified by the
setting
Special.ownGraphics=true/false

FINNtech AS Site builder's toolbox.doc Page 7 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

Altogether, this gives great flexibility with respect to creating the look and feel of a site.

It is possible to create a collection of graphics and style sheets, and refer to this as a
“graphicsPersonality”. A Graphics Personality may be assigned to any site, thus re-using
graphics and style sheets for multiple sites.

5.4. Mail
As stated above, mails from a site are created using XML-like mail templates. This is handy for
branding e-mail as emerging from different sites.

It is possible to create a collection of mail templates, and refer to this as a “mailPersonality”. A

Template Personality may be assigned to any site, thus re-using templates for multiple sites.

For example, an innovative combination of all these personalities may be used for creating sites
with both common elements and differing sub-elements.

6. Tag libraries explained

The tag libraries in iAd are documented on the FinnTech intranet.
This documentation concerns all tags delivered with an iAd installation.
However, only a subset of the tags is pertinent to the creation and presentation of on-line ads.
These tags are elaborated further in this chapter. First, however, we explain the basic properties
of presenting data entities within iAd.

6.1. Fields
”Fields” in this context refer to single entities of data. A field normally pertains to an attribute to
an ad, but may also stand alone.
Examples of a field:
• The make of a car in a car ad
• The price of a car in a car ad
• The address of a flat in a homes ad
• The salary in a job ad
• Etc…

Any field has a name, determined by the data model. A field may be “composite”, i.e. it may be
a collection of sub-fields, rather than just being a simple string. This scheme might be used on
e.g. an address, which actually is a collection of a street name, a number, a postcode and a city.
The field names might then look something like
address.street
address.number
address.postcode
address.city
The “dot” (i.e. “.”) separates the field and subfield names, and this is the only visible difference
between a basic field and a composite field. Technically speaking, composite fields consist of
members of an object (as for Hashmaps), and not, like basic fields, an object (as for Strings).

6.2. Addressing scheme

All tags address fields by the same scheme.
The addressing scheme sets forth three terms that together make up the necessary information to
address a field and obtain its value:
• Scope
• Object
• Field

FINNtech AS Site builder's toolbox.doc Page 8 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

6.2.1. Scope
The scope is a string with one of the following values:
• parameter
• attribute
• … or may be missing
6.2.1.1 ”Parameter” scope
Fields with scope “request” exist only within the current http request. Their values are not
bound to the iAd ad database, and this scope is not elaborated in this document.
6.2.1.2 ”Attribute” scope
Likewise, “attribute” scoped fields take their value from attributes (J2EE internals) on the
request, and are not elaborated in this document.
6.2.1.3 No scope defined
Missing definition of scope will cause the toolbox to assume that the “Object” is neither of the
above, but one of the following:
• a Map or a Hashtable with members
• a List or an ArrayList with members
• a bean (Java Bean, not EJB) with getter methods.
and will act accordingly.

6.2.2. Object
This comprises the Object part of the addressing. The object says where to look for the field’s
value. As explained in the chapter “Tags in the ad context” the creator of result and detail pages
need not be concerned with this. For those with special interest, please refer to the
“Programmer’s summary of Addressing scheme” below.

6.2.3. Field
Field is a string containing the name of the data entity to be presented. All possible fields in an
iAd ad have their own names (set forth by the “DTD” - the XML Data Type Definition - of the
ad type). Please refer to separate documentation for these names.

6.3. Programmer’s summary of Addressing scheme

• parameter
– object not applicable
– field: request.getParameter(field)
• attribute
– object not applicable
– field: request.getAttribute(field)
• anything else
– if object is a bean:
– field represents a getter: field ”prop”: object.getProp()

– if object is a Hashtable (or, a subclass of Map):

– field is object.get(field)

– if object is an ArrayList (or, a subclass of List):

– field is represented by a number, which is the position within the ArrayList, i.e.
object.get(Integer.parseInt(field))

– field may also be “composite”, i.e. a field name may represent a java Map,
which may again contain members. Thus, a composite field follows the naming
pattern “main.sub”. This means that the field “main” has subfields when a dot
(“.”) is present in the name.

FINNtech AS Site builder's toolbox.doc Page 9 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

7. Tags in the ad context

Did this seem rather complicated? It is. But don’t worry: The iAd tags are tailor-made to
simplify the task of creating result and detail pages, which, at the end of the day, are the main
tasks of an iAd application.
“Anchor” tags are created for this purpose:
• <util:data>
• subclasses of this tag
Given the prerequisite knowledge that JSP tags can ”live inside” other JSP tags, we now set
forth that field addressing tags that live inside these two tags automatically obtain the correct
addressing capabilities. Thus, the only attribute necessary for addressing the correct field, is the
name of the field itself. This name is documented separately, as it may (and probably will) be
subject to changes and amendments during the life-cycle of an iAd based site.
The above reference to “subclasses of this tag” implies that other tags exists, giving access to
other types of data, apart from the ad data themselves. Among such tags are tags giving access
to
• request related data
• vertical related data
• suborganisation related data
For anyone requiring such data, please refer to the tag library documentation, as well as the
configuration guide, for hints as to what items are available for presentation.

7.1. The tag specifics

The subsequent subchapters describe the various tags in terms of general use. For details of the
various tags, please refer to the on-line documentation of the tag libraries on the FinnTech
intranet.

7.1.1. Testing (conditional) tags

Testing tags are provided for the purpose of testing for the presence of fields, or specific
contents in the fields.
Testing tags must live inside the nest of a <cond:if> tag, which again provides the
functionality of the <cond:else> tags. There exists also an optional <cond:then> tag for
legibility, and for use when the body of the condition is already used and cannot contain the
“true” response of the condition. (This is the case e.g. for the <cond:exists> tag, which
evaluates its body and thus cannot contain the “true” body of an <cond:if>)
Testing tags consist of the following tags:
• <cond:hasvalue field=”myfield”> which tests for the presence of a value in
the referenced field.
• <cond:hasmatchingvalue field=”myfield”
match=”matchingvalue”> which tests for a match in the value of a field
• <cond:hasvalues fields=”field1,field2” operator=”and|or” >
which tests for presence of multiple fields whose name is presented as a comma
separated list of names in the “fields” attribute, either one of the fields, or all of
them, depending on the value of the “operator” attribute, which may assume one of
the values “and” or “or”.
• <cond:exists>, which evaluates its body for the presence of any contents. This is
especially handy for checking for the result from other tags present in its body, and may
be used for many testing purposes.
If these tags evaluate to true, their body is evaluated (or the body of an embedded
<cond:then> tag is), else the body of the adjacent <cond:else> tag is evaluated.
The former two testing tags will retain any obtained value, thus making it available for an
input/output tag enclosed within the testing tag, thus relieving the input/output tag of the task of
re-fetching the value. Thus, an input tag living inside one of these testing tags need not specify
the name of the field, as will be evident from the example given at the end of this document.

FINNtech AS Site builder's toolbox.doc Page 10 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

The third testing tag may retrieve several values, and as it is not obvious to this tag which one
will be displayed inside of it, none are retained. Input/output tags inside this testing tag must
specify a field name. Of course, any input/output tag living inside the former two may also
specify a field name, thus creating the capability of testing for the presence of one field, and
then displaying another, should this be necessary. In general, any tag may specify a value where
this is not necessary according to the addressing scheme, in order to override the default
functionality whenever necessary.
The last tag checks for presence of output from within its body. E.g. an
<output:showvalue> tag in the body of a <cond:exists> tag will not produce output
to the user, but its output will be intercepted and tested by the <cond:exists> tag.
Other tags may also assume the behaviour of a conditional tag, please refer to the complete tag
library documentation for details.

7.1.2. Output tags

Output tags are actually only one tag:
• <output:showvalue field=”field”> which inserts the value of the field into
the output stream of the invoking JSP page. Note: any input or output tag may enclose a
format tag, enabling formatting of the field’s value according to rules, before inserting it
into the JSP output stream. Please refer to description of formatting tags below.

7.1.3. Input tags

Input tags consist of the following:
• <input:text field=”field”>
• <input:textarea field=”field”>
• <input:password field=”field”>
• <input:hidden field=”field”>
• <input:select field=”field”> which must enclose tags of this kind:
o <input:option optionName=”Hello” optionValue=”1”>
• <input:group field=”field”> which must enclose tags of one of these
kinds:
o <input:checkbox name=”Hello” value=”1”>
o <input:radio name=”Hello” value=”1”>
All these tags map directly onto their html counterpart, but, of course, they also have the
capability of binding to an iAd field, as well as being able to enclose a format tag, as are output
tags.
Enclosed tags described in this section (option, checkbox and radio), will automatically assume
their correct html SELECTED/CHECKED state based on the value of the enclosing select or
group tag’s current value.
All tags will retain their value from the previous POST, should the page be re-displayed, thus
relieving the creator of the task of “remembering” state from one page to another. Actually, the
values of any of these input/output tags are retained in the same manner:
• If a persistent field value exists (from the iAd database), it will be displayed.
• If not, the value from a previous display of the page will be examined and displayed if
present. This is, provided that conditions for this exist, see note below.
• If not, a default value will be presented, taken from an attribute called
“defaultValue”, which is shared by all these tags.

Note: Regarding “inheritance” of a value from a previous display of a page, it must be noted
that this is only true when a page is displayed accompanied by an error message. This is due to
the fact that an error message usually is issued when storing to a database is not possible.
Therefore, instead of relying on the database to supply a persistent value, the contents of a field
must be preserved from what the user typed on the previous display of a page. When no error
message is present, the defaultValue is displayed directly when a persistent field value is
missing.

FINNtech AS Site builder's toolbox.doc Page 11 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

(Programmer’s note: It is possible for the application code to alter this behaviour, by calling
the API SystemUtils.preserveInputContents(request)).

Several other tags may be subclassing the behaviour of input/output tags, all exploiting the fact
that field values are inherently available. Please refer to the online tag library documentation for
a complete overview.
7.1.3.1 WML
All these above input: tags have their counterpart with the same name in the wml: tag library.
The functionality is that of the above input tags, however, they render wml instead of html. This
is for creating sites with e.g. WAP capability, or iDTV sites that render wml.

7.1.4. Repetition tags

These are the repetition related tags:
• <iteration:repeat object=”<%=theObject%>”>
• <iteration:breakat every=”nnn”>
This tag is intended for applying the same JSP fragment to all members of a collection of data,
in the case of ads; the result list.
Its purpose and usage is, hopefully, obvious from the enclosed example, and needs no further
explanation.
The <iteration:breakat every=”nnn”> causes its body to be evaluated every nnn’th
iteration of the enclosing <iteration:repeat> tag. This is useful for creating e.g. line
breaks, new table rows, etc., for every nnn’th iteration of a result set.

7.1.5. Formatting tags

A formatting tag may be inserted within any input or output tags, in order to format their values
according to certain rules, before the values are displayed. The enclosed example will illustrate
how formatting may be applied. The formatting rules are:
The tag will format the contents of its body if present, any string contained in the attribute
"value" or the value presented by the <output:showvalue> tag (see separate
documentation of this tag).
The formatType and formatString accept (currently) the following values:
• formatType="digit", combined with formatString="decimal",
"number"
• formatType="date" which formats a “long” value (internal representation of a
date/time) into a date/time string, using the pattern defined in application.properties.
(Refer to the iAd configuration guide).
• formatType="newline", formatString is not applicable – substitute html
<br> tags for newlines
• formatType="url", formatString is not applicable - checks and completes
an http url
• formatType="urlEncode", formatString is not applicable - urlEncodes a
string

7.1.6. Grouping tags

It is sometimes desireable to group rows in a list of items together, using a common headline.
Example, in a list of cars sorted by make, rows dealing with the same make may be grouped
under headlines like this:
Audi
1997 A4, £12000
2002 A6, £100000
BMW
1996 316, £10000
1999 520, £20000

FINNtech AS Site builder's toolbox.doc Page 12 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

This is achieved using the grouping tags. They may appear within an
<iteration:repeat/> tag, and consist of the tags
• <util:holdvalue />, which acts as an “anchor” for the part of a JSP which is
concerned with the grouping, and
• <util:rowgrouping />, which tests for change in the value to cause a break in
the grouping and output a new headline (or other action). This tag may live within a
<cond:if /> tag, enabling the use of a <cond:else />, used to define what to
do when a break is not detected, should this be necessary.

7.1.7. Navigational tags.

The understanding of the navigational tags is for the advanced user. It is sufficient to know
about their existence for this purpose. Should they appear in a page, it is for the purpose of
creating the proper flow of events in order to complete any ongoing task, and they should not be
moved. Actually, no single tag is a navigational tag, but many of the tags contain attributes that
affects navigation and the flow of control between pages.
The schemes for navigating an iAd site, are basically three:
1. Regular (“linear”) navigation, where submitting to one page leads to the display of
another.
2. “Ad hoc” navigation, which does not necessarily have one predefined thread through a
set of pages, but the user is more free to choose which page to complete, before
submitting the final page as a final submission. This is the kind of navigation utilized in
e.g. ad order entry and CV registration. This navigation falls into two kinds:
a. useraction/nextstep navigation, where the terms “useraction” and “nextstep”
signal to the Java application what the user has performed, and where to go
next, after having treated the contents of the submitted page.
b. formaction navigation, where the tag itself will point out which formaction to
use, i.e. which action to post to for treating the submitted page.
The terms useraction, nextstep and formaction refer to attributes of those tags that are
used to support the navigational patterns. Please refer, again, to the complete on-line tag
library documentation. The contents of these attributes correspond closely to the
execution of the Action classes assigned to each URL, and should not be altered, which
would break the navigation of the pages.

8. Examples
These examples may serve as an illustration of how to create result list and detail pages. Note:
The field names are fictitious, for illustration purpose only, and do not reflect the actual contents
of an iAd database. Please refer to the data model documentation for a correct overview of
available fields. Refer also to the presentation “Site builder’s toolbox” (whose name coincides
with the name of the present document). There, a more end-user approach to understanding the
task of building a site is outlined.

Please note that no HTML is included in the examples. In a real site, a designer will need to add
the proper HTML to take care of formatting, etc.

Note that these pages look very similar. It is, however, their association (through the config file
actions.properties) to an “Action”, which supplies them with the proper data objects.
This is actually a crucial part of making an iAd site work properly, to keep JSPs and Action
classes in sync via a properly configured property file.

8.1. Result list page

<util:data>
<iteration:repeat>
<util:holdvalue value=”<%=someexpression%>”>
<util:rowgrouping value=”<%= someexpression%>”>

FINNtech AS Site builder's toolbox.doc Page 13 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

Here is a new headline, which is printed

each time the value of “someexpression”
changes.
</util:rowgrouping>
</util:holdvalue>
Make:
<output:showvalue field=”make”/>
Model:
<output:showvalue field=”model”/>
Mileage:
<output:showvalue field=”mileage”>
<util:format formatType=”digit”/>
</output:showvalue>
Price:
<cond:if>
<cond:hasvalue field=”price”>
<output:showvalue>
<util:format formatType=”money”/>
</output:showvalue>
</cond:hasvalue>
<cond:else>
<b>Absolutely FREE!</b>
</cond:else>
</cond:if>
</iteration:repeat>
</util:data>

8.2. Detail page:

<util:data>
Make:
<output:showvalue field=”make”/>
Model:
<output:showvalue field=”model”/>
Mileage:
<output:showvalue field=”mileage”>
<util:format formatType=”digit”/>
</output:showvalue>
Price:
<cond:if>
<cond:hasvalue field=”price”>
<output:showvalue>
<util:format formatType=”money”/>
</output:showvalue>
</cond:hasvalue>
<cond:else>
<b>Absolutely FREE!</b>
</cond:else>
</cond:if>
</util:data>

8.3. Sample mail template

Without further explanation, this paragraph sets forth a sample XML mail template. Note the
use of “macros” (embedded between “hash” (#) characters) that act as placeholders for actual
values being substituded as the mails are generated.

Mail templates contain both <BODY> and <BODYPLAIN> sections, the former being used
when generating a mail to a person having opted in on the “I may receive HTML mail” option
in the “myprofile” profile, the latter for generating mail to a person who has opted out of this
option.

FINNtech AS Site builder's toolbox.doc Page 14 of 15

Site builder’s toolbox Printed date: 12/12/2004 10:35 AM

<SUBJECT>
#subject#
</SUBJECT>
<BODYHTML>
<HTML>
<HEAD>
#stylesheet#
<TITLE>Email from #from#</TITLE>
</HEAD>
<BODY>
#subject#

<br>
<br>

Hi,
<br>
<br>
A friend of yours would like to alert you to a particular advert on
#homepage#: <br>
<a href="#finnurl#advert?adId=#prospectId#">
#finnurl#advert?adId=#prospectId#</a>
<br>
<br>
Comments: <br>
#comments#
<br>
<br>

The friend that has sent you this is: #from#

<br>
<br>
sent from: #mailsendername#
<br>
#bannerad#

</BODY>
</HTML>
</BODYHTML>
<BODYPLAIN>
plain text version of body text
</BODYPLAIN>

FINNtech AS Site builder's toolbox.doc Page 15 of 15