Skip to main content
Kinetic Community

Building Form Templates

Document Overview

The following document will assist with creating form templates.  Form templates are service items in Kinetic Request that have elements that will get used over and over again in your other forms.  These are useful for analysts to clone to create their own forms.  They will often have empty sections where content would be included, but have many of the more technical areas already in place.   Because of this, it is often useful for a more technical person to create the templates up front, allowing analysts to build the actual forms later, based on the templates created.

Creating a Form Template

A form template is the same as any other form created using Kinetic Request.  However, the idea of the form template is to be cloned, all or in part, to create new forms.  Often templates include elements that will be common in all forms, Cascading Style Sheets (CSS),  JavaScript files and Tasks Trees containing processes common to all Service Items.

To build a good template:

  • Look at the various forms your company would like to build.  Look for consistencies in those forms.  These often are:
    • Page Header Text
    • Section Headers/Titles
    • Requester Section
    • Requested For Section (for ordering on behalf of someone else)
    • Submitter Section 
    • Footer Section
  • Create a section or sections where it is obvious to form builder where to add form specific content.  This section could be called “Your Content Here”.
  • Create Pages or Functionality that will be common, such as "Save as Draft" functionality.
  • Create the tasks that will be common to all forms:  An approval and then a record creation is the most common.
  • Use a customized JSP to handle HTML header, page header and footer and other visual branding (See JSP section later in this document).

Note that an approval template has a very different structure:

  • Approval Questions
  • Review pane/frame that displays the original request

In a typical installation, the templates created could be similar to these:

  • Simple Form Template-No Approvals
  • Simple Form Template-One Approval
  • Standard Form Template-One Approval & Create Incident
  • Standard Form Template-Two Approvals & Create Incident
  • Approval Template

These templates would then include a description about where/when to use them.  It’s also a good idea to add an attribute to the template stating who the author is and the current revision.    As a best practice, we usually set the “Type” of the form to be “Template”, so they are easily recognized when looking at list of forms.

Using a form JSP

Each form created in Kinetic Request uses a JSP page to layout the display of each page.  The JSP page includes static HTML <head> content needed for every form display including references to any JavaScript and CSS elements, other Java initialization code, and placeholders for the form definition configured by the author.  The default form JSP page is: displayPage.jsp.  This JSP file can be found in the root /kinetic/ directory on your web server or in the installation files. 

You could also choose to start with a bundle. Bundles are web-based add ons to Kinetic Request which allow you to quickly create a web interface to your request catalog. Bundles include all of the files that you need to get started and come in different themes for styling and branding. A typical bundle includes a category listing page which allows the user to browse through the catalog, a display page for your service items, a submissions page which lists all the submitted, closed and pending requests for the user and a submission details page which shows all of the details and tasks for each request.

Bundles are based on a web application framework and run in the same tomcat instance as Kinetic Request under the themes directory. Bundles consists of Java Server Pages, HTML, CSS, and JavaScript. Due to the fact that they are based on HTML and JSP pages they are easy to configure for your needs.

Create Your Own JSP

For most situations, it is best to create a copyof this default JSP file so that it can be customized to your own needs, without affecting the samples or simpler forms that use the default.  Call this something similar to myITForm.jsp and keep it in the root of the /kinetic/ directory, unless a Bundle is being used, so the references to other files are still intact.  Typically, only one customized JSP for all of the forms within a catalog, as they often share the same headers, style sheets, etc.

Then, on the “Advanced” tab of the Kinetic Request – Service Catalog Console, change the DisplayPage (JSP) value from the default JSP to the name of your copied JSP.  Now, when the page is rendered, it will use your JSP instead of the default.

The illustration shows the use of JSP in a real-world situation.  Everything outside the red boxes are all HTML in the JSP file.  The center box is created using Kinetic Request.  In this way, the form has a consistent, professional look and feel, while a non-technical person can easily create forms that fit in with the rest of the portal.

In addition to the static HTML in the JSP, it is possible for the developer to insert more dynamic content.  In the example the “Example” is the name of the form.  Different forms would automatically have different titles across the top.   Many form text elements can be included in the static JSP content this way:

  • Form Name
  • Form Description
  • Catalog/Portal Name
  • User’s Login Name

Inserting this content in the JSP is done using the JSP “getProperty” tag <jsp:getProperty>.  The Kinetic Request server bundles up the template information and user information into beans and attaches them to the JSP page for display (via the response object).  All of the properties in these beans can be accessed and included this way.

Of course, these elements and many others can also be embedded into the form itself (content inside the orange box) via dynamic text elements in Kinetic Request.  Making the determination of which strategy to use where is up to the developer, but knowing your options is half the battle.

The additional benefit of using a single JSP for the look/feel of the form is form maintenance.  If the company changes their logo or color scheme, a JSP developer can update the form in a single place and all of the forms that use the JSP get updated, as well.  This makes managing your service portfolio in the long-term less complex.

As you go forward building the JSP, be sure to reference the branding standards defined in the Delivery Model – Branding document.  Often HTML can be cut directory from the pages referenced in that document and placed in your JSP.

CSS

Having your forms published on the web allows other standard technologies do much of the heavy lifting for you.  With a little planning, many of your forms can “draw themselves” letting CSS handle the padding, margins, font, sizing and positioning. 

Defining Your Styles

With CSS, it is best to take a top-down approach.  The developer should style elements as much as possible at the highest possible level and handle unique situations at the element. All of the elements in Kinetic Request have their own CSS classes to make it easier to style in bulk.  You can also create your own classes and apply them to the elements in the form.

A typical CSS setup could include:

  • A style sheet (myCatalog.css) which includes html tag and CSS classes defined.
    • This would be attached to the portal and reference by all of the forms in the portal.  They would automatically inherit these properties.
    • This file would define:
      • Font family, font-size
      • Background color
      • Question padding & margins (questionLayer class)
      • Question Label font-weight (often bold) (questionLabel class)
      • Text padding & margins (dynamicText class)
      • Section padding & margins
      • Section headers (most sections have a title)
        • To do this:  Define your own class called sectionHeader and add this to the appropriate Dynamic Text elements in Kinetic Request
      • TwoUp and ThreeUp styles
        • This can be defined for sections where you want questions to show up in two or three columns rather than in a row.
        • Add this class to questions you want to behave in this way
          • TwoUp: float:left; width 47%;
          • ThreeUp: float:left; width:31%;
  • Then on the form itself, define items that may be specific to the form via the Kinetic Request styling capabilities:
    • Again, use classes wherever possible for styling elements rather than doing them individually.
    • Items that may be defined on the form include:
      • Special fonts, font decoration, bolds, etc.
      • Special indenting, margins

Many of the forms that Kinetic Data creates have no element-specific styling, letting styles set at the HTML tag or class declarations do all of the styling.  This also leads to more cross-browser compatibility for your forms.

Technical Tip:  Tools such as Firebug and Chrome Developer Tools can be of great assistance when styling.