Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

A method and system to customize eForm display based on rules

IP.com Disclosure Number: IPCOM000187598D
Original Publication Date: 2009-Sep-14
Included in the Prior Art Database: 2009-Sep-14
Document File: 6 page(s) / 38K

Publishing Venue

IBM

Abstract

Disclosed is a client-side solution to extend eForm viewer to highlight users interested eForm elements/sections based on rules without updating the source code of eForm, by extending eForm viewer to fetch the rules from rule repository and change the display of form based on rules.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 6

A method and system to customize eForm display based on rules

Disclosed is a method to customize eForm display based on rules to solve some really existing
problems. With this method, an eForm could display different user interface without changing the
eForm source code and without additional coding.

1. Rules

A kind of rule syntax is provided. Rules here are used to define how eForm display is customized
based on the context and the eForm data. Rules can be edited by designer, administrator, even
end users if a powerful rule editor is provided. Rules can be stored in client side or server
side. A clear address of rule repository is set in form viewer extension. Context can be
composed by any information that form viewer/form viewer extension can collect. The eForm data,
cookies (for html forms), system properties, local files, etc can compose context. Rule actions
can be anything which could be executed by form viewer, for example, highlight elements, turn to
a specific page, etc. An eForm viewer plug-in is provided to fetch the rules from rule
repository based on the context and change the display of eForm based on rules.

For example, a sample rule could be defined as below:

If the eForm is an "insurance policy application" and the user role is "applicant",
Then a) The application part will be highlighted.

When evaluating this rule, the eForm name and the user role can be collected from the context.
If the conditions are true, the rule action - highlighting the application part - will be
executed by eForm viewer plug-in.

If the form is an "insurance policy application" and the user is "Tomas White" (which is a
manager)

Then a) The application form will turn to page 2 b) Monthly salary will be high light if the amount is less than 1000

c) The manager approval part is high light.

1

Page 2 of 6

When evaluating this rule, the eForm name and the user name will be collected from the context.
If the conditions are true, the rule action - turning to page 2, highlighting the manager
approval part, and conditionally highlighting the monthly salary - will be executed by eForm
viewer plug-in.

2. EForm viewer plugin

A typical eForm viewer plugin can have the following modules:

Repository management module: This module is used to fetch rules and save rulesin a repository.
Context composing module: This module is used to create a context.

Rule execution module: This module is used to parse and execute rules based on the context. This
module will dynamically change the eForm content display based on the parsed rules.

2

Page 3 of 6

A typical work flow of eForm viewer plugin looks like the above picture, and is described below:

In step (1), Repository Management Module will fetch rules from repository.

In step (2), Repository Management Module will do arule parsing, collect required variables,
such as the eForm name and a certain element, and send...