eForm v2 - rbdmsonline.orgrbdmsonline.org/files/pdf/eFormGenericAdminHelpv2.pdf · Comments module (see Managing Comments on page 40). Some agencies may opt to allow members of the

eForm v2.0

Administrator’s Manual and Training Guide

A Superset of CO, MS, KY, NY and AL Functionality

First Release: November 2009

Revision 1: December 2009

Revision 2: March 2010

Revision 3: August 2010

Revision 4: August 2012

Revision 5: January 2013

Revision 6: June 2013

Revision 7: March 2015

Revision 8: May 2015

iii

Table of Contents

Summary of Features ................................................................................... 1

About eForm ................................................................................................. 1

eForm HTML (v2) Web Application ................................................................... 2

Forms Designer ............................................................................................. 3

eFormService ................................................................................................ 3

eFormOrchestrator ........................................................................................ 4

eFormWindowsService ................................................................................... 4

RBDMS WinAdmin.NET ................................................................................... 4

Installing eForm on the Server ..................................................................... 7

Preparing the Web Server for a New Installation ................................................ 7

Installing eFormService (ePermitService Visual Basic Project) ............................. 8

Installing the eForm HTML Web Application....................................................... 8

Installing the eForm Silverlight Web Application ................................................ 9

Configuring the eForm Web Applications ......................................................... 10

Edit GetUserNameByUserID Scalar-Valued Functions ....................................... 11

Considerations for Site Visitors for the SL Application ....................................... 11

Installing ePermitWindowsService ................................................................. 12

Creating New Forms ................................................................................... 13

Overview of Creating a New Form Object........................................................ 13

eForm Administrator’s Manual and Training Guide

iv

Generating the LINQ-to-SQL Object ............................................................... 14

Example of Adding a Workflow Grid Process in an Existing Form ........................ 16

Example of GetNewForm Code ...................................................................... 18

Example of SaveObject Code ........................................................................ 18

Updating the Service References in the User Interface ..................................... 20

Creating Rule Sets ....................................................................................... 20

Using the Forms Designer ............................................................................. 23

An Overview of Using the Forms Designer .................................................... 23

Standard Page Layout Practices for Compliance with Section 508 ................... 24

Setting Basic Parameters for a New Layout .................................................. 26

Defining the Page Layout ........................................................................... 27

Tips for Placing Controls in the Workspace ................................................... 28

Using Built-in Controls in a Form Layout ...................................................... 28

Working with the Tab Control ..................................................................... 30

Placing User-Defined Controls in the Layout ................................................. 31

Using Custom Controls .............................................................................. 33

Saving a Form .......................................................................................... 34

Deleting a Form from the Forms Designer .................................................... 35

Importing and Exporting Form Layouts ........................................................ 35

Managing eForm ......................................................................................... 37

Table of Contents

v

Keeping Consistent Naming Conventions ........................................................ 37

Setting the Current Version of a Form ............................................................ 37

Creating a New Lookup ................................................................................ 38

Adding Reports for Printing Forms ................................................................. 39

Managing Comments ................................................................................... 40

Assigning Review Tasks and Sending Notifications ........................................... 41

Tailoring the Display of Review Tasks on the Dashboard ................................... 43

Defining Paths for Form Status Changes ......................................................... 44

ePermitWindowsService Functionality ............................................................. 45

Flagging Changes to Submitted Data in the Workflow Review Process ................ 46

Configuring the Navigation Page .................................................................... 47

Using URL Parameters .................................................................................. 48

Creating Tabs in the Form Renderer Accessible by User Role ............................. 48

Updating an Existing eForm Application ..................................................... 53

Updating an Existing Installation on the Server ............................................... 53

Updating the eForm MVC Web Application ...................................................... 54

Updating the eForm Silverlight Web Application ............................................... 55

Updating an Existing eFormService Application ................................................ 57

Understanding Application Data Flows ....................................................... 59

Understanding ASP.NET MVC ........................................................................ 59


vi

Routing in ASP.NET MVC ............................................................................ 59

Modifying the Default Routing Behavior ....................................................... 61

Understanding Windows Communication Foundation and Its Configuration in eForm

................................................................................................................. 61

Javascript Libraries Used by the Application .................................................... 63

jQuery ..................................................................................................... 63

jQuery UI ................................................................................................ 64

jqGrid ..................................................................................................... 65

Bootstrap Library ...................................................................................... 66

Application Architecture................................................................................ 67

eForm MVC Implementation Details ............................................................... 68

Forms Designer ........................................................................................ 68

Grid Row Details .................................................................................... 68

Validation Changes ................................................................................... 70

Cross Object Validation ........................................................................... 70

Client Side Validation ............................................................................. 70

Controllers in eForm HTML ......................................................................... 70

HomeController ..................................................................................... 71

LoginController ...................................................................................... 71

DashboardController .............................................................................. 71

FormController ...................................................................................... 72

Table of Contents

vii

Preserving the Form State During Form Editing ....................................... 73

Views in eForm HTML ................................................................................ 74

ASP.NET Razor - Markup ......................................................................... 74

Using Layout Pages in ASP.NET MVC ........................................................ 75

Dashboard View ..................................................................................... 75

Edit View .............................................................................................. 76

Login View ............................................................................................ 76

Implementing the HTML Form Renderer ...................................................... 77

Form Elements ...................................................................................... 77

Rendering Labels ................................................................................... 78

Rendering Text Boxes ............................................................................. 78

Rendering Text Areas ............................................................................. 78

Rendering Check Boxes .......................................................................... 79

Rendering Date Pickers ........................................................................... 79

Rendering Combo Boxes ......................................................................... 80

Combo Box Preparation and Lookups ..................................................... 80

Rendering Tab Controls .......................................................................... 80

Tab Role Visibility ................................................................................ 81

Rendering Grids ..................................................................................... 82

Rendering Data Grids ............................................................................. 82


viii

Loading Data for the Grid ..................................................................... 82

Rendering the Grid Cells ...................................................................... 83

Binding Grid Controls to Hidden Grid Cells .............................................. 83

Saving the Grid Data ........................................................................... 83

Grid Paging Support ............................................................................ 84

Rendering Subgrids ............................................................................. 84

Rendering Custom Controls ..................................................................... 86

Adding New Custom Controls ................................................................ 87

Print Preview in eForm HTML ...................................................................... 87

Public Method Calls for eFormService ............................................................. 87

1

Section 1

Summary of Features

About eForm

The eForm application is an electronic permitting Web application that eliminates

duplication of data entry to and storage of hard-copy regulatory forms. It was

conceptualized as a way for industry operators to provide permit information online

only once and then have multiple agencies share access to the data, if desired. As

the eForm project has matured, state agencies have found that the architecture can

also be used to support other types of online forms submission, such as oil and gas

well completion and water quality reporting.

The eForm project is an integrated set of server tools that are based on ASP.NET

MVC and HTML/JavaScript (external client), Silverlight (internal client), a Windows

Communication Foundation (WCF) middle tier, and SQL Server intermediary

databases in a DMZ for submitted forms and for forms under review. The approved

information is replicated to the production database behind a firewall. The server

tools include the following components:

eForm HTML Web application

Forms Designer

eFormService (ePermitService)

eFormOrchestrator

eFormWindowsService

RBDMS WinAdmin.NET

This help file is meant to document only the uses and inner workings of the eForm

applications. Information about the availability, installation, configuration, use, and

maintenance of Microsoft development tools and enterprise software such as SQL

Server, Reporting Services, and Visual Studio is available from the Microsoft Web

site.

The Colorado Oil and Gas Conservation Commission (COGCC) partnered with the

Ground Water Protection Council (http://www.gwpc.org) to develop the original

design of eForm. The GWPC provided technical and financial contributions under the

terms of its Department of Energy grant to help develop the eForm project as a part

http://www.gwpc.org/


2

of the RBDMS eCommerce program initiative. eForm has since been installed at oil

and gas agencies in Kentucky and Alabama.

Programming for the eForm applications was provided by Virtual Engineering

Solutions, Inc. (http://www.VirtualES.com), and Coordinate Solutions, Inc.

(http://www.coordinatesolutions.com).

eForm HTML (v2) Web Application

The eForm HTML Web application is the Web client user interface (based on ASP.NET

MVC) that both industry users of the site and internal agency staff can access. The

application includes a main navigation page (dashboard) that features the ability to

use filtered searches to retrieve, edit, validate, print, and submit permit applications.

The form status is displayed on the main navigation page, so users can track the

progress of the permit application through the agency review process.

Registered industry operators and agents who submit permit applications to the state

oil and gas agency are restricted by secure logon to editing only those forms

associated with their Operator Number that have a status of Draft and that are not

yet Submitted. These users must supply a user name, password, and an operator

number assigned by the database administrator. Internal staff users may set the

Operator No. filter as needed for their tasks at hand and are not required to supply

an operator number at logon. Site permissions are governed through user roles that

are defined in RBDMS WinAdmin.NET.

The 1.0 version of the eForm application also offers the architecture to support a

Comments module (see Managing Comments on page 40). Some agencies may opt

to allow members of the public and other agency users of an eForm site to review

and comment on any form with a status of Submitted, In Process, or On Hold. This

feature hasn't been migrated to the new HTML based Web client yet.

Important Note: The developers strongly recommend maintaining a development

and testing environment that is completely separate from the application running on

the live Web server.

http://www.virtuales.com/

http://www.coordinatesolutions.com/

http://www.rbdmsonline.org/files/pdf/Printed_Documentation.pdf

Summary of Features

3

Forms Designer

The Forms Designer is used to design and publish regulatory forms as simplified Web

pages for industry operators’ online data entry. Users should have system

administrator credentials and some understanding of programming.

The Forms Designer integrates with the Rules Engine and will bind to any object for

which a Creating Rule Sets (see page 20) has been saved to the database. The

Forms Designer provides a graphical user interface that allows users to place controls

onto a workspace and then set properties on each control to define the appearance

of the resulting form. The Forms Designer is a Silverlight application, with the XAML

and binding information for the controls stored in database tables. Controls available

in the Forms Designer include label, text box, text area, date picker, combo boxes,

tab control, check box, and data grid.

eFormService

eFormService (ePermitService) is a Windows Communication Foundation (WCF)

application that forms a middle tier of web service methods used to validate the data

and return the operator information to the client, along with the relevant permission

set and roles. The application uses the Language Integrated Query (LINQ)-to-SQL

(see http://msdn.microsoft.com/en-us/library/bb425822.aspx) to create the objects

for passing to the ASP.NET MVC and Silverlight client. This WCF layer makes it

possible to provide all of the WCF services separately from the ASP.NET MVC and

Silverlight Web hosting.

The ePermitService includes a number of methods. GetFormsEx, the method used to

fill the dashboard, pulls from both the eFormWorkflow (form submittal) and

eFormReview databases. The methods GetForm, GetObject, SaveObject_SS, and

SetStatus write FormStatusQueue and FormDate records on Form.FormStatus

change.

Each of these methods uses the GetDBConnectionFromForm method to ensure that

the correct database is used given the form’s status. This method consults the

vweFormDashboard views in the database to make this determination, allowing

changes to the database views to flow to the application without code modification.

http://msdn.microsoft.com/en-us/library/bb425822.aspx


4

As of the June 2013 release, significant modifications were made to the eForm user

interface to facilitate service changes and the user’s interaction with forms.




eFormOrchestrator

eFormOrchestrator is the application layer that processes FormStatusQueue

records and carries out the actions specified for each change of status that occurs for

each form type. For example, eFormOrchestrator manages the actions that occur

when forms in Draft status become Submitted, actions taken when forms in the

Submitted status change to CompletenessCheck, and actions when Submitted forms

are changed to the Returned status. Likewise, the actions on form status change

from CompletenessCheck to Accepted functionality (e.g., those related to copying

forms from the eFormSubmit database to the eFormReview database to facilitate

review tasks with original values comparison) have been generically coded to

maximize reuse of the code. For more information, please see the topic Defining

Paths for Form Status Changes on page 44).

eFormWindowsService

The eFormWindowsService is a .NET 3.5 Windows Communication Foundation

(WCF) service application that creates eNotify records and sends out e-mail

notifications (see page 41). It also manages the flow of eForm from the DMZ

database to the internal production database and passes status updates from

internal processes to the DMZ database.

RBDMS WinAdmin.NET

RBDMS WinAdmin.NET is a WinForms application that was developed with the .NET

Framework 2.0. It is meant for developers and database administrators to use to

control multiple Internet- and intranet-based applications, such as RBDMS, Data

Mining, eReport, and eForm. RBDMS WinAdmin.NET centralizes site and application

security (users, roles, and permissions) menu control, filtering, error and exception

Summary of Features

5

handling, data validation through the Rules Engine, and the notification module,

which governs user alerts.

The Rules Engine allows the agency to create business rules that can be applied to

controls on the forms created in the Forms Designer, used within the parser, or used

by other applications. The notification module works with the parser to alert users of

the status of XML uploads and includes timing clocks for the participating agencies

and governmental entities to know when a regulatory form that requires their

attention has been received. RBDMS and RBDMS WinAdmin.NET are applications

whose development is sponsored by the Ground Water Protection Council.

For additional information about RBDMS WinAdmin.NET, including installation

instructions, please refer to its user help manual, which is available from

http://www.rbdmsonline.org/files/pdf/Printed_Documentation.pdf and the application

Help menu. The client application for RBDMS WinAdmin.NET is available from

http://virtuales.com/downloads/co/RbdmsWinAdminSetup_V1_10.Net4.zip.

http://virtuales.com/downloads/co/RbdmsWinAdminSetup_V1_10.Net4.zip

7

Section 2

Installing eForm on the Server

Preparing the Web Server for a New Installation

eForm is an integrated set of server tools that are based on ASP.NET MVC and

HTML/JavaScript (external client), Silverlight (internal client), a Windows

Communication Foundation (WCF) middle tier, and several SQL Server 2008 R2

databases:

eFormWorkflow: the DMZ database that holds the collected information

from user data entry and is replicated to the review database.

eFormReview: the DMZ database against which the agency reviews and

edits the forms and which is replicated to the production database behind the

firewall.

eFormArchive: an archival database behind a firewall.

eFormSecurity: the database that governs the users roles and privileges.

eForm: the database that holds the controls and layout controls for the form

objects in the application, as well as the RuleSet table.

The external client is the eForm HTML application, which includes a navigation page,

form editor, and report viewing and printing. The internal user interface includes

similar capabilities with expanded permissions and the Forms Designer.

The eFormService (ePermitService Visual Basic project) is the Windows

Communication Foundation (WCF) middle tier

Prerequisites on the Web server:

IIS

SQL Server

.NET Framework 4 (downloadable from http://www.microsoft.com/en-

us/download/details.aspx?id=17718)

Prerequisites for administrative workstations:

Visual Studio.NET 2013

Microsoft Silverlight 4 Tools for Visual Studio 2010

(http://www.microsoft.com/en-us/download/details.aspx?id=18149)

RBDMS WinAdmin.NET (see page 4)

http://www.microsoft.com/en-us/download/details.aspx?id=17718




8

Access to the database that hold the Controls, LayoutControls, RuleSet,

formVersions, and UserSetting tables (eForm and eFormWorkflow

databases)




Please also see the topic Application Architecture on page 67.

Installing eFormService (ePermitService Visual Basic Project)

Use SQL Server Management Studio to install the eForm, eFormWorkflow and

eFormSecurity databases if they are not already installed.

1. Use the Publish option in the context menu for the ePermitService project in

the Visual Studio Solution Explorer to generate the files to be published. In

the connection tab, select Publish method: File System and specify the

destination folder. On the settings tab, specify Configuration: Release and

check 'Delete all existing files prior to publish.'

2. Copy the generated files from the local publish folder files to a new directory

on the Web server.

3. Use the IIS Manager to create a virtual directory and enable anonymous

access.

4. Ensure that the service (or the account that IIS uses) has Read access to the

folder.

5. Edit the configuration settings (Web.config in the \eFormService root

folder) and enter the correct database connection strings (see page 10).




Installing the eForm HTML Web Application

1. Use the Publish option in the context menu for the eFormMVCGUI project in

the Visual Studio Solution Explorer to generate the files to be published. In

the connection tab, select Publish method: File System and specify the

Creating New Forms

9

destination folder. On the settings tab, specify Configuration: Release and

check 'Delete all existing files prior to publish.'

2. Copy the generated files from the local publish folder files to a new directory

on the Web server.

3. Use the IIS Manager to create a virtual directory and enable anonymous

access.

4. Ensure that the service (or the account that IIS uses) has Read access to the

folder.

5. Edit the configuration settings (see page 10). Configuring the eForm Web

Applications (Web.config in the \eFormHTML root folder) and enter the

correct database connection strings. Set the StateName, StateAbbrev and

ReportPathURLprefix according to the current location.




Installing the eForm Silverlight Web Application

1. Copy the Form2SL_Web directory from the local Visual Studio solution folder

to a new directory on the Web server.

2. Use IIS Manager to create a virtual directory and set it to allow anonymous

access.

3. Perform the following steps on the ePermitGui.xap file in the \ClientBin

folder:

a. Open the .xap file with a .zip file application.*

b. Edit the ServiceReferences.ClientConfig file.

c. Modify the endpoint address to match the location of the

eFormService, e.g.,

“http://RbdmsOnline.org/eFormService/ePermit.svc.”

d. Save the updated .xap file.

4. Ensure that the Silverlight MIME types are registered. In IIS Manager, right

click the ePermit Web/Silverlight application and choose Properties. Choose


10

the HTTP Headers tab and click the MIME Types button. The following

extensions should be listed. If they are not present, then add them:

.xaml —application/xaml+xml

.xap —application/x-silverlight-app

.manifest —application/manifest

.application —application/x-ms-application

.xbap—application/x-ms-xbap

.deploy —application/octet-stream

.xps—application/vnd.ms-xpsdocument

*Tip: .xap files are packaged archive files like .zip files that are used in deploying

Silverlight applications. The developers recommend using a product called 7-Zip to

edit these files. 7-Zip is free from http://www.7-zip.org/.

Configuring the eForm Web Applications

eForm includes three web.config files that must be edited upon installation or

relocation of the application. The files can be found in the following locations:

/eFormService<StateAbbreviation>

/eFormHTML<StateAbbreviation>

/eFormSL<StateAbbreviation>

The web.config file in the /eFormService folder, which holds the WCF service,

holds four connection strings that must be set to specify the data source, initial

catalog, user name, and password:

1. The DMZ connection

2. The security database

3. The rules repository

4. The RBDMS connection string, which points to the eFormWorkflow database

5. RBDMS Input connection string, which points to the eFormWorkflow database

that will accept data input to the Web application

http://www.7-zip.org/

Creating New Forms

11

The web.config file in the /eFormHTML folder, which holds the ASP.NET MVC Web

application, includes following lines that must be edited:

1. The application setting for the report path. The folder designated by this file

path holds the .rdlc templates for report viewing and printing.

2. The RBDMS connection string, which points to the Workflow database that

holds the data to populate the .rdlc report templates.

3. The state name in the applicationSettings section.

4. The state abbreviation in the applicationSettings section.

5. The report path URL prefix in the applicationSettings section.

The web.config file in the /eFormSL folder, which holds the Silverlight Web

application, includes two lines that must be edited:

1. The application setting for the report path. The folder designated by this file

path holds the .rdlc templates for report viewing and printing.

2. The RBDMS connection string, which points to the Workflow database that

holds the data to populate the .rdlc report templates.

Edit GetUserNameByUserID Scalar-Valued Functions

The scalar-valued function GetUserNameByUserID must be edited to set the correct

security database. This function exists in both the eFormReview and eFormWorkflow

databases.

Considerations for Site Visitors for the SL Application

First-time site users who do not have Silverlight installed on their workstations will

be directed to a page containing the following Get Silverlight icon:

Clicking the hyperlinked icon will download the required version of Silverlight.


12

Internal agency users may need to add the URL for the Silverlight site to a trusted

zone. In Internet Explorer, choose Tools | Internet Options, Security tab,

Trusted sites.

Installing ePermitWindowsService

The default location for the installation of the ePermitWindowsService on the

development server in the C:\Program Files\GWPC\ePermitWindowsService

directory. Before starting the service, agency staff will need to edit the

ePermitWindowsService.exe.config file to update the following:

ConnectionStrings

ApplicationSettings

o SmtpHost

o MailFromAddress

o MailFromDisplayName

o SmtpUserName

o SmtpPassword

When the service is started, it writes an entry into the computer event log to indicate

that it started. The service then creates an instance of the ePermitBLL.Notify class.

This service governs the eNotify functionality (see page 41).

.

13

Section 3

Creating New Forms

Overview of Creating a New Form Object

Discussions of the inner workings of the eForm application frequently reference the

concept of a Form and, by extension, the concept of a FormSubType. The difference

between the two bears further definition, as do the related concepts of version and

status.

A Form as used within the eForm application is a Web-based representation of a

piece of paper an agency uses to collect data. It stores such data as the kind of a

piece of paper it is (e.g., a Form 1, 2, etc.) and its eFormVersion, which is the

specific XAML layout file with which the Form is associated. In addition, a Form

stores such other metadata as who submitted it (SubmitterKey), for which industry

operator the form was submitted (EntityKey), and its status within the eForm

workflow process (e.g., Draft, Submitted, In Process, Accepted, Denied, etc.).

FormSubType is any related data (e.g., the actual data associated with a Form2). All

downstream data will have FormSubTypes (see Generating the LINQ-to-SQL Object,

step 5, on page 14).

The Forms Designer, which is a part of the Silverlight Web application that is

available to internal agency staff, would seem to be the first place to go when the

agency needs to develop a new form for use on the external eForm Web site.

However, the form layout created in the Forms Designer must be associated with a

Bound Object that is first created in the data access layer (DAL) as a LINQ-to-SQL

object and then used to define rules in the Rules Editor. Forms can be bound to any

object that has a rule set associated with it.

Therefore, before the Forms Designer can be used, a series of preparatory steps

must be completed to create the bindable object. These steps are performed first in

SQL Server Management Studio, then in Visual Studio 2008, and finally in the Rules

Editor portion of RBDMS WinAdmin.NET. Once these steps are completed, the

bindable object will be displayed and available for selection in the Form Designer

Bound Object list.


14

For each new bindable object, the database administrator must write code in the

WCF layer to create, retrieve, persist, and delete the object. However, adding the

LINQ object in the DAL represents the only point in the process of creating the Web

application in which a database administrator is required to write code. Typically,

fewer than 15 lines of code are required to edit each of the service methods (e.g.,

GetObject and SaveObject).

Important Note: The form name must match the layout name. Likewise, the LINQ

object name must match the form layout name. The comparison is case-sensitive.

The general steps governing this process are described below. Except for step 8,

these steps should be performed in a development environment where the changes

can be tested safely outside of the live Web server application.

1. Create the data table in SQL Server Management Studio to support the new

form object.

2. Generate the LINQ object and associated code (see page 14).

3. Update the ePermitBaseSL (see page 20). Updating the Service References in

the User Interface

4. Create the business rule set (see page 20).

5. Create the form layout in the Forms Designer and test it in the form renderer

and main navigation page (see page 23 ff).

6. Set the current version of the form (see page 37).

7. Add printing capabilities for the new form (see page 39).

8. Update the application on the live server (see page 53 ff).

Important Tip for Editing eForm Code: Always follow the existing design

patterns: copy, paste, and edit!

Generating the LINQ-to-SQL Object

Remember: The LINQ object name must match the form layout name.

1. In Visual Studio 2008, open the ePermitDAL project.

Creating New Forms

15

2. Open the ePermitClasses.dbml file.

3. Drag and drop the table created to support the new form object from the

Server Explorer pane of Visual Studio onto the workspace.

4. For each new BaseApplicationSubType you add (e.g., a Form2, Form3,

FormX), you will need to add a partial class to ePermitClasses.vb. The

partial class must inherit BaseApplicationSubType, which requires override of

two properties: FormSubTypePKey (the primary key of the FormSubType) and

FormSubTypeFormKey (the foreign key to the Form). Both overridden

properties must have the DataMember attribute. An example follows:

Partial Class Form2

Inherits BaseApplicationSubType

<DataMember()> _

Public Overrides Property FormSubTypeFormKey() As Integer

Get

Return FormKey

End Get

Set(ByVal value As Integer)

FormKey = value

End Set

End Property

<DataMember()> _

Public Overrides Property FormSubTypePKey() As Integer

Get

Return PKey

End Get

Set(ByVal value As Integer)

PKey = value

End Set

End Property

End Class


16

5. Within the ePermitService project, two service methods must be edited:

GetObject and SaveObject. (Note: CreateNew and Delete will typically not

need to be changed.) For each of these methods, edit the SELECT statement

to add a case statement for the object being added. For objects on the many

side of a one-to-many relationship with the Form, you must delete all records

associated with the FormKey in the IF block related to INSTANCEZERO (see

eFormAttach for an example) in the SaveObject_SS subroutine.

Note: The Serialization Mode property for the ePermitClasses.vb file is already set

to Unidirectional. If you are creating a new .dbml file, make sure that you set this

property to Unidirectional to convert the database objects to characters.

Note: Several important assumptions have been built in to the coding requirements

for Get and Save data returns. All FormSubType objects used in the application must

have a relationship to the Form object described to the application using the

properties of the BaseApplicationSubType. OnSave, the form renderer, will send all

data each time you make a change. The INSTANCEZERO IF block must remove all

records on the many side of a relationship in the instance that there were records on

Get that were deleted on Save (see step 5 above). There is special handling in

onSave for Saves that occur on the first retrieval after new. Because the primary key

is not yet assigned, the updates will not work. See eFormAttach as an example.

Note: Because the eForm base code could be changed at any time, all changes to

the eForm code base should be done within the StateSpecific folder. Edits made

elsewhere in the solution will compromise compatibility with nationally released

future updates. In all cases, follow established design patterns: Copy, paste, and

edit!

Example of Adding a Workflow Grid Process in an Existing Form

1. Make the DAL modifications for the new object (eFormTask) in the

ePermitDAL project.

a. Open the .dbml file. Make sure the LINQ object inherits

RbdmsDAL.BaseBusiness.

b. Edit the GetObject SELECT statement to add a case statement for

the object being added.

Creating New Forms

17

c. Edit the SaveObject SELECT statement to add a case statement

for the object being added.

2. Update the service reference.

3. Log in to ePermit as Administrator.

4. Select Administration | Design forms.

5. Select New Layout.

6. Click Grid Properties and create a grid with two rows and five columns.

7. Name the layout: WorkflowGrid.

8. Specify the Version number: 1.

9. Specify the BoundObject: ePermitDal.eFormTask.

10. Assign a RulesetInternal: eFormTask.

11. Assign a RulesetExternal: eFormTask.

12. Add labels controls to each cell in top row. Set text to each respective label:

Task

Due

Assigned To

Reviewer

Comments

13. Add text boxes to each cell in bottom row. Set text to each respective label:

Task

Due

Assigned To

Reviewer

Comments

14. Click Save. When given the preview, click Continue.

15. Select New Layout.

16. Name the new layout: WellTask.

17. Specify the Version number: 1.

18. Specify the BoundObject: ePermitDal.form2.

19. Assign the RulesetInternal: form2.

20. Assign the RulesetExternal: form2.

21. Place the user control WorkflowGrid v 1.00000 in the grid cell.


18

22. Set the ParentKey: doc_num.

23. Set Use As DataGrid: True.

24. Click Save to save the layout. When given the preview, click Continue.

25. Test the changes in the form renderer and main navigation page.

Example of GetNewForm Code

Sample GetNewForm Code:

Dim db As New

ePermitClassesDataContext(RbdmsConfig.Config.RbdmsDmzConnectionString)

frm = New form

frm.EntityKey = operatorNo

frm.Type = form_num

frm.ModifyUser = chk.UserName

frm.status = "DRAFT"

frm.ModifyDate = Now()

'//populate current version into form object

Dim edb As New ePermitDAL.ePermitDesignClassesDataContext

Dim query = From fv In edb.formVersions _

Where fv.form_num = form_num And fv.ActiveDate < Now _

Order By fv.ActiveDate Descending _

Select fv.version

If query.Count > 0 Then

frm.version = query.FirstOrDefault

End If

db.Forms.InsertOnSubmit(frm)

db.SubmitChanges()

Example of SaveObject Code

Sample SaveObject Code:

Case "form"

Creating New Forms

19

Dim f As Form = GetObject(dr, GetType(Form))

f.ModifyDate = Now()

formKey = f.PKey

form_status = f.Status.ToLower()

'//get original form so we can attach for update

Dim tmpDB As New ePermitClassesDataContext

Dim tmpData As Form = tmpDB.Forms.Single(Function(d) d.PKey = f.PKey)

If IsNothing(tmpData) Then

Throw New Exception()

End If

db.Forms.Attach(f, tmpData)

Case "form2", "opd"

Dim f2 As Form2 = GetObject(dr, GetType(Form2))

f2.ModifyDate = Now()

f2.FormKey = formKey

If f2.PKey < 1 Then

'//if multiple saves happen on the New then PKey will remain 0

'//have to check for existing records in form2 table with this

formkey

'//delete if any found

Dim q = From d In db.Form2s Where d.FormKey = f2.FormKey Select d

If Not IsNothing(q) AndAlso q.Count > 0 Then

db.Form2s.DeleteAllOnSubmit(q)

db.SubmitChanges()

End If

'//insert

db.Form2s.InsertOnSubmit(f2)

Else

'//attach

Dim tmpDB As New ePermitClassesDataContext

Dim tmpData As Form2 = tmpDB.Form2s.Single(Function(d) d.PKey =

f2.PKey)

If IsNothing(tmpData) Then

Throw New Exception()

End If

db.Form2s.Attach(f2, tmpData)


20

End If

Updating the Service References in the User Interface

The eFormMVCGUI and ePermitBaseSL projects within the eForm Visual Studio

solution is the code that the user interface depends on to access the service layer.

Once you have completed steps 1 and 2 in creating a new form object (see page 13

ff), you must update the service references so that the user interface knows about

the new (or modified) DAL object.

1. Open the eForm solution in Visual Studio 2013.

2. In the Solution Explorer, expand eFormMVCGUI.

3. Expand Service References.

4. Right-click ePermitService and select Update Service Reference.

5. Open the ePermitSL solution in Visual Studio 2013.

6. In the Solution Explorer, expand ePermitBaseSL.

7. Expand Service References.

8. Right-click ePermitService and select Update Service Reference.

Typically, the service references need to be updated when new objects are created

(LINQ or form objects). However, as long as you are adding only variants of a form

type (e.g., the many variants of Form 2 that exist in Mississippi), you do not need to

change the service references.

Creating Rule Sets

Data fields in the online application are governed by rule sets, and the Rules Editor

allows database administrators to select, assign, and chain rules in a point-and-click

environment. Database administrators can create new rules and then link the rules

to either custom classes or references to tables through the Rule Set Browser. The

application will support adding a new rule or having multiple rules against the same

field, setting priorities, and using .NET commands at the administrator’s preference.

The Rules Editor also can be used for extension methods including regular expression

methods, date type checks, range checks, stored procedure checks, and table checks

(e.g., "check for valid key"). Forms may be bound to both internal and external rule

sets, which may define different sets of form behaviors depending on whether the

user is in a Public or Agency role.

Creating New Forms

21

The general procedure for using the Rules Engine is as follows:

1. In the Rules Editor, browse for and select the appropriate object store (.dll or

.exe file). The Rules Editor uses reflection to expose the object properties,

meaning that the Rules Editor “looks” at the selected object and then makes

the fields available as properties.

2. Create the internal and external rule sets with VB.NET code snippets, many of

which are already available in the Rule Set Browser for use as models.

Important Note: You cannot use a DAL object in the Forms Designer until there is a

rule set for that object.

Using the Rules Engine is contingent on the presence of the RuleSet table in the

database specified by the connection string to RbdmsDMZ or RBDMS. The RuleSet

table tracks, by RuleID, the name of the rule, major and minor version numbers, the

definition of the rule set, the status of the rule, the path to the assembly referenced,

the name of the library, and the modify date. The Rule Set Browser includes radio

buttons to select the database location for the RuleSet table (RBDMS or DMZ). If

the RBDMS database does not contain the RuleSet table, WinAdmin.NET

automatically selects the DMZ database. For the eForm application, the DMZ

connection string must be pointed to the eForm database, which holds the controls

and the layout controls for the form objects and the RuleSet table.

The Rules Engine consists of a Rule Set Browser and a Rules Editor. To open the Rule

Set Browser from the RBDMS WinAdmin.NET menu, click Forms | Rule Set

Browser. The first time you open the Rule Set Browser, you will need to make sure

that you set the path to the appropriate directory containing the .dlls for the data

objects by clicking the respective Browse button and navigating to the appropriate

directory location. This sets the Rules Engine to point to the object to which the rules

you create will be bound. The file locations that you enter in the Alternate Library

Path field are stored in the application configuration file for WinAdmin.NET, so each

user can have a different path to the .dll location.

The tree control in the Versions pane on the left shows the rule set names and,

nested below each, the available versions of each rule set. Clicking one of the

version nodes displays in the Members pane the methods and attributes for the

Bound Object that are available to the rule set.


22

The button bar below the Versions pane can be used to create new rules, delete

existing rule sets from the list, copy rules sets, and edit the rules within a selected

rule set. Clicking the Edit Rules button opens the Rule Set Editor as a dialog form.

To create a new rule, click the Add Rule button at the top of the Rule Set Editor.

Then you can use VB.NET code snippets to define (1) the condition you wish to

control with the rule (IF...), (2) the actions that will be taken in response (THEN...),

and (3) other actions that must follow (ELSE).

A method call is then added in the application program to associate the rule set with

the form object.

An example of a simple rule is shown below.

Creating New Forms

23

Using the Forms Designer

An Overview of Using the Forms Designer

The Forms Designer provides a graphical user interface that allows users to define

the appearance of a simplified Web form by placing controls onto a workspace and

setting the properties on each control. The XAML used for the controls is stored in

the database tables Controls and LayoutControls.

The Forms Designer is laid out with a distinct workspace in the center of the page, a

toolbox of controls on the left, and a Properties pane on the right. The built-in

controls available in the Forms Designer include label, text box, text area, date

picker, combo box, tab control, and check box. Each form developed in the Forms

Designer becomes available as a user control. This design approach allows the

development of "form snippets" that can be reused as individual controls nested into

other forms. Examples of user controls include the Casing grid and TRS form

snippets. The tool bar at the top left of the Forms Designer offers the options of New

Layout, Load Layout from XML, Load Layout from Database, Save Layout,

Save Layout to XML, Delete Layout, and Exit the Forms Designer.

Before beginning to use the Forms Designer, please see Standard Page Layout

Practices for Compliance with Section 508.

The general procedure to create a new form is as follows:

1. Open a new form layout in the Forms Designer and define its basic

parameters of name, version, Bound Object, and rule sets (see page 26).

2. Define the form page layout and controls placement (see page 27).

3. If the form that you have created is a new form (and only if the form you

have created is a new form), add the form to the FormVersions table.

4. Set the current version of the form (see page 37).

5. Test the form.

Important Note: The form name must match the layout name. Likewise, the LINQ

object name must match the form layout name. The match is case-sensitive.


24

Standard Page Layout Practices for Compliance with Section 508

Sixteen rules govern access to Web-based applications under Section 508 of the

Amended Rehabilitation Act of 1973 (http://www.section508.gov/). The Forms

Designer is meant for use as an aid in producing simplified Web pages that meet

these requirements, and Silverlight supports Section 508 compliance. However, a

person using the Forms Designer to develop forms for agency use is in a position to

make basic decisions that could result in a product that is less than compliant.

Familiarity with the requirements is essential.

From Section 508 of Amended Rehabilitation Act of 1973 as amended (29 U.S.C.

794d):

§ 1194.22 Web-based intranet and internet information and applications.

(a) A text equivalent for every non-text element shall be provided (e.g., via

"alt", "longdesc", or in element content).

(b) Equivalent alternatives for any multimedia presentation shall be

synchronized with the presentation.

(c) Web pages shall be designed so that all information conveyed with color is

also available without color, for example from context or markup.

(d) Documents shall be organized so they are readable without requiring an

associated style sheet.

(e) Redundant text links shall be provided for each active region of a server-

side image map.

(f) Client-side image maps shall be provided instead of server-side image

maps except where the regions cannot be defined with an available geometric

shape.

(g) Row and column headers shall be identified for data tables.

(h) Markup shall be used to associate data cells and header cells for data

tables that have two or more logical levels of row or column headers.

http://www.section508.gov/

Creating New Forms

25

(i) Frames shall be titled with text that facilitates frame identification and

navigation.

(j) Pages shall be designed to avoid causing the screen to flicker with a

frequency greater than 2 Hz and lower than 55 Hz.

(k) A text-only page, with equivalent information or functionality, shall be

provided to make a web site comply with the provisions of this part, when

compliance cannot be accomplished in any other way. The content of the

text-only page shall be updated whenever the primary page changes.

(l) When pages utilize scripting languages to display content, or to create

interface elements, the information provided by the script shall be identified

with functional text that can be read by assistive technology.

(m) When a web page requires that an applet, plug-in or other application be

present on the client system to interpret page content, the page must provide

a link to a plug-in or applet that complies with §1194.21(a) through (l).

(n) When electronic forms are designed to be completed on-line, the form

shall allow people using assistive technology to access the information, field

elements, and functionality required for completion and submission of the

form, including all directions and cues.

(o) A method shall be provided that permits users to skip repetitive

navigation links.

(p) When a timed response is required, the user shall be alerted and given

sufficient time to indicate more time is required.

The eForm application was developed for a standard screen resolution of 1024 x 768,

and the simplified Web forms created with the Forms Designer must meet this

requirement. Applying the following list of basic practices to any given form layout

definition will help to meet both this goal and Section 508 requirements:

1. Restrict the row count to prevent vertical scrolling. eForm has been designed

to keep the button bar on the bottom of the Form Editor visible without

scrolling.


26

2. Restrict the column count to prevent horizontal scrolling.

3. Reuse the controls that have been accepted as meeting these requirements

as agency standards rather than re-create a complex control (such as a

casing grid).

4. Maintain enough contrast between background and foreground colors for high

readability.

5. Maintain enough spacing between fields for convenient data entry and high

readability.

6. Give every graphic link an alt-text description.

7. Use reasonable field sizes. For example, if the average address is 20

characters, size an Address field for somewhere between 25-35 characters.

8. Use consistent label positioning for clear association with the field.

9. Group related content.

10. Consider the user's tabbing expectations when laying out forms.

Setting Basic Parameters for a New Layout

1. From the navigation page, expand the Administration menu and click the

Design Forms button to open the Forms Designer.

2. Click the New Layout button from the tool bar at the upper left of the

page.

3. In the Property pane, enter a name for the layout in the Name field and

assign a version number in the Version field.

4. Choose the bindable type object that will support the data binding for your

new form from the Bound Object list at the top of the Properties pane.

Remember that defining the Bound Object must be done through a series of

preparatory steps (see page 13 ff).

5. Choose the RulesetInternal and RulesetExternal that will govern the way the

form behaves for users in the Agency and Industry roles, respectively.

Creating New Forms

27

Defining the Page Layout

Once you have named the new form, assigned it a version, specified the source for

the bound fields, and selected the internal and external rule sets for the form

behavior, you are ready to define the page layout.

1. Click Grid Properties to establish the basic page layout grid in the Grid

Properties dialog box. Use the Add buttons to add the desired number

of rows and columns. To delete a row or a column, click on the row or column

you wish to delete in the Grid Properties dialog box and then click the Delete

button. You can define the column and row height and width for the form

grid through three types of specifications:

Fixed (in pixels), which enables incremental rendering.

Proportional (star notation—e.g., 1*, 2*), which refers to the portions

of horizontal space required by a table.

Auto, which is less preferred for use in Silverlight than in HTML.

For more information, see http://msdn.microsoft.com/en-

us/library/system.windows.gridlength(VS.95).aspx.

2. When the layout is adequately defined, click OK. The workspace area of the

Forms Designer will display the grid dimensions specified.

3. Place the desired controls on the form and set their properties. You can

choose from controls that are installed with the Forms Designer (see page

28), user-defined controls (see page 31), and custom controls (see page 33).

Tip: The Add and Remove buttons on the Grid Properties dialog work as follows:

With a selected row or column, the Add button will insert a new row or

column above the current selection.

With no row or column selected, the Add button will add a new row or

column to the bottom of the list.

With a row or column selected, the Delete button will delete that row

or column and all contained controls.

http://msdn.microsoft.com/en-us/library/system.windows.gridlength(VS.95).aspx

http://msdn.microsoft.com/en-us/library/system.windows.gridlength(VS.95).aspx


28

Tips for Placing Controls in the Workspace

To place a control on a form:

1. Select the cell in the form grid where you want to place a control by clicking

on it.

2. Then select the type of control you want to place in that cell by clicking the

radio button for that control type in the toolbox.

3. Click Place in Selected Cell.

To move a control that you have already placed in the layout to a different cell:

1. Click on the cell containing the control you want to move to select it. (Note:

do not click on the control itself.)

2. Drag and drop it to another empty cell.

To delete a control:

1. Click on the cell that contains the control to select it.

2. Click Clear Selected Cell.

To remove a row or a column from the form layout, use the Add and Remove

buttons on the Grid Properties dialog:

With a selected row or column, the Add button will insert a new row or

column above the current selection.

With no row or column selected, the Add button will add a new row or column

to the bottom of the list.

With a row or column selected, the Delete button will delete that row or

column and all contained controls.

Using Built-in Controls in a Form Layout

Database administrators will need to understand the relationship of the Bound

Properties of each control to the top-level forms data object specified in the Bound

Object property for the form (see page 26). With the exceptions of the combo box

Creating New Forms

29

and label controls, each of the built-in controls has one bound property, which the

user can select from the list of bindable properties shown at the top of the

Properties pane in the Forms Designer.

1. The Bound Property list for the Text Box and Text Area controls is labeled

Text. Choose the data fields that will be bound to the control from this list.

2. The Bound Property list for the Date Picker is labeled Date. Choose the date

field that will be bound to the Date Picker control from this list.

3. The Label control does not have a bound property. Replace the default value

for the label text in the Text property.

4. The Combo Box control has both a Lookup and a Bound Property. The Lookup

list is populated from the lookups.xml file (see page 38) in the

ePermitService application, which defines the code and code description

being called. The connection string referenced should be one of the

connection strings in the ePermitService application .config file. A sample:

<?xml version="1.0" encoding="utf-8" ?>

<Lookups>

<Lookup Name="WellType" CodeType="String"

ConnectionString="RbdmsDMZConnectionString">

Select Code, Description from RefCodes where fld='WellType'

</Lookup>

</Lookups>

5. The Check Box control is available for data formatted as bit fields. The Bound

Property list for the Check Box is labeled IsChecked. Some agencies have

typically preferred the use of char(1) fields instead of bit fields, and char(1)

fields do not accept true/false values. Therefore, the developers recommend

the use of combo (yes/no choice) rather than check boxes where char(1) field

formatting is used.

6. The IsReadOnly property is available for Text Box controls. The content of

Text Boxes where this property is enabled will not be editable in the form

renderer.


30

7. The Tab control (see below) is an example of how pre-defined user controls

can be dropped into place within a standard control to create a nested form.

Working with the Tab Control

The Tab control is an example of how pre-defined user controls can be dropped into

place within a standard control to create a nested form. Therefore, skilled use of the

Tab control will involve a planning step to make sure that the user controls for the

subpages are available in the database and that the relationship of the Bound Object

for the sub form to the parent form is understood.

The Tab control is placed the same way the other controls are placed into the cells,

but with the additional specification of the appropriate column and row spans. Once

you have placed the control in the form layout, click the More Properties button to

open the Tab Control Properties dialog box.

From the toolbar at the top of the Tab Control Properties dialog box, you can

perform the following actions:

Add and name tabbed subpages.

Order the sequence of the tabbed subpages.

Rename the subpages.

Delete subpages.

Assign the controls you want to display on each tabbed sub form by selecting the tab

from the Tabs column, selecting the desired control for assignment to the tab from

the Controls column on the right, and then clicking the Assign button. Likewise,

control assignment to a particular tabbed sub form can be cleared by selecting the

tab in the Tabs column and then clicking the Clear button.

Once the tab control is defined satisfactorily, click OK to close the Tab Control

Properties dialog box. The form designer will display the control assignments for

each tabbed subpage as a label until you save your work by clicking the Save

button, at which point you will be able to preview the form. To edit the actual page

Creating New Forms

31

layout for a tabbed subpage, you will need to save your work and then open the user

control you placed on the tab and perform the edits desired in this source layout.

The visibility of a tabbed page can be restricted to only the Administrator and Agency

roles by prefixing the tabitem name with [*]. Users in other roles such as Public and

Industry will not have access to these tabbed pages in the deployed application.

Placing User-Defined Controls in the Layout

Each form produced and saved in the Forms Designer is made available from the

Open Layout button and as a user control in the toolbox on the left side of the

workspace. These user controls can be reused as needed and nested inside other

forms. The following special-case rules govern user controls:

1. Know the ParentKey: The data object for a user control, such as a data

grid, may be different than the data object for the parent form. Therefore,

users need to know the relationship between BaseApplicationSubType and the

BaseApplication (ParentKey). The method to retrieve data for the

BaseApplicationSubType takes two parameters: (1) the object type (e.g.,

Casing) and (2) the Casings value. The ParentKey is often the document

number. For example, if there is a 1:1 relationship from Form 2 to Form 2

Extended (Casing), the data that fills Casing receives the value of ParentKey

where Casing is the FormID from the incoming form. In other words, the

ParentKey will always be the database value underlying the

BaseApplicationSubType.FormSubTypeFormKey property.

2. Use as DataGrid: You can use a user control, such as the Casing control, as

a data grid in a form layout by clicking the Use as DataGrid check box in the

Properties pane after placing the control in the layout. Layouts used as data

grids must consist of two rows: (1) a heading row of label controls and (2) a

row of appropriate data entry controls. When a data grid control is rendered

within an eForm application, users will be able to select a row or column and

click the Add button to insert a new row or column above the selection and

shift all currently placed controls down or over to accommodate the insert. If

the Add button is clicked without a row or column selection, the row or

column is added to the bottom of the grid. To delete a particular row or


32

column, select it and then click the Delete button. The selected row or

column and any controls in the selected row or column will be deleted.

3. Know your options: As mentioned above, a data grid consists of two rows,

a header and a row of bound controls. You have the option of adding an

embedded form as a grid details row. To do this, a third data grid row must

be created with an item in the 3,1 position, as shown below.

This third row will be rendered as the embedded form (see below).

Result of form rendering:

Creating New Forms

33

4. Manage row details in a flat form: The row details cannot be a data grid,

or a tab control, or any other user control. It must be a flat form for data

entry and must be bound to the same object as the data grid in top row. The

grid row detail is essentially a one-level-deep data entry for that row.

Important Note: User controls always use the rule set created specifically for that

control. You cannot place a user control on a form layout and specify it to use the

parent rule set. For example, the Casing control will always use the Casing rule set.

It cannot use the Form2 external rule set.

Using Custom Controls

Administrative users of the Forms Designer need to understand the following rules

governing the behaviors of custom controls:

1. Custom controls must be located in the LayoutCustomControls project.

2. Custom controls must not be named anything that converts to an integer

because they are differentiated by Integer.TryParse(.Tag) (e.g., “1a” is fine,

but “1” is not).

3. Custom controls must inherit LayoutCustomControlBase.

LayoutCustomControlBase implements BoundField (a DependencyProperty)


34

and is used when determining which types in the LayoutCustomControls

project are to be visible in the layout editor.

4. In the layout editor, custom controls follow the same path as user controls

(used as CustomControlPlaceHolders) until GetLayoutForSave. They are

differentiated by MyControlType (either Custom or Layout from enum

ControlType in the CustomControlPlaceholder class).

5. Custom controls are notified of Renderer actions (such as Save or Validate)

via the overridable function OnRendererAction.

6. Custom controls should call the OnDataChanged subroutine when data

changes so that the FormRenderer is notified that data has changed.

Rules for using custom controls are as follows:

1. Association of one (and only one) field from the parent (e.g., Layout in which

the control is contained) is allowed by the LayoutEditor.

2. A custom control will share DataContext with the parent layout. This means

the data will be retrieved and validated by the Rendering Engine only if all

bound fields from the custom control are from that DataContext.

3. The custom control must return a list of DataReturn objects from the

OnRendererAction function if the FormRenderer is to Save or Validate the

custom control's data. (Review the eFormAttach custom control for an

example implementation.)

Saving a Form

Once you have completed a form layout, click the Save button to save your

form. The Forms Designer will preview your form in the Editor and offer you the

opportunity to either Continue with the save action or Cancel the save action to

return to the designer for further work. Each form that you create and save with the

designer will be available as a user control in subsequent sessions.

Creating New Forms

35

Deleting a Form from the Forms Designer

To delete a form from the Forms Designer, open the form and then click the Delete

Layout button from the tool bar. You will be prompted to confirm the

permanent form deletion.

Importing and Exporting Form Layouts

For many reasons, you may wish to export your layouts to a file external to the

database: as a backup, as a means of exchanging layouts between installations, etc.

Functionality has been added to the Forms Designer so that form layouts can be

saved as XML files to a location external to the eForm database.

To save an existing form layout to XML, follow these steps:

1. Use the Forms Designer to finalize a form layout.

2. Click the Save Layout to XML button on the Forms Designer toolbar.

The File | Save As dialog box will open.

3. Specify the file path and file name of the form layout you are exporting as

XML.

4. Click the Save button.

Note: If the layout you wish to export to XML includes user-defined or custom

controls, those controls will NOT be saved in the XML file. This functionality works to

save only the top-level form. At this time, the Save action includes only the

references to the user and custom controls. Therefore, a complete form restoration

will need to be done from the bottom up, i.e., the base layout for each of these

container controls must be saved as separate XML files.

To load an XML-formatted form layout from disk into the Forms Designer, follow

these steps:

1. In the Forms Designer, click the Load Layout from XML button. The

File | Open dialog box will open.


36

2. Navigate to the location where the layout files are stored, select it, and click

Open.

Note: If a form layout with the same name as the XML file exists in the database,

you will receive a prompt asking whether to overwrite the existing file.

37

Section 4

Managing eForm

Keeping Consistent Naming Conventions

An important consideration in maintaining an eForm application is rigid adherence to

a consistent naming convention for objects within the application. For example,

1. The name of a form must match the name of the layout associated with that

form.

2. The name of a LINQ object must match the name of the form layout.

3. The name of a report (e.g., "Form02.rdlc") must match the name of the form

object (e.g., "Form02").

Setting the Current Version of a Form

As the business rules governing the use of the regulatory forms change over time,

you, as the administrator, will need to assign which, of the possibly many, layout

versions of each form in the database is assigned as the current version available to

users of the application. The only requirement for making forms from the Forms

Designer available to the application is for the name of the form. You must save the

forms you create in the designer with a name that matches the form number shown

in the form table. Be sure to increment the version number of the form each time

you create a new one.

1. From the Administration menu, click the button labeled Set Active Form

Versions to open the page that manages the current form version

assignment. The Set Current Form Versions form opens to show a list of

forms available to the application in the left pane and the available versions of

that form on the right. This list now shows each form name listed in the

formVersions table.

2. Click to select the name of the form you want to assign to a version.

3. Click the form version that you want to assign as the current version of that

form number.

4. Click the Assign button.


38

5. To clear a form name from the pane, click the form name to activate the

selection and then click the Clear button. Form names with no associated

version are not available for creation in the eForm dashboard.

6. Click Exit to return to the main navigation page.

The formVersions table is used to determine the state of a form in the system. To

add a new form type in the application, add the form name to the formVersions

table.

If the Version field is set to a value of -1, the form will not be available to users.

The default for the Version field is -1. Using the Clear button assigns that form a

Version field value of -1.

Remember: The form name must match the layout name. Likewise, the LINQ object

name must match the form layout name.

Creating a New Lookup

At times, you will find that you need to create a new lookup within the eForm

application, for example to list API numbers by Operator. The general steps to create

this example lookup in the code follow:

1. In SQL Server Management Studio, create the query:

SELECT PKey,WellID FROM Well WHERE Operator = |0| ORDER BY WellID

2. Edit the query to cast the PKey as varchar:

SELECT cast (Key as VARCHAR(50)) as Code) PKey,WellID FROM Well as

Description WHERE Operator = |0| ORDER BY WellID

3. Copy the query to the clipboard, and go to code. Stop the debugger if it is

running.

4. In the ePermitService project, StateSpecific folder, open lookups.xml.

5. Scroll to state-specific section and paste the query somewhere you can easily

pick it up and re-paste it again later.

6. Copy an existing lookup in lookups.xml and paste it.

7. Edit the newly pasted lookup to change the lookup name to one that matches

your intent (in this case, perhaps, “LookupAPI”).

Managing eForm

39

8. Then pick up the query you dropped in step 5 and paste it into the new

lookup you created.

9. Copy the connectionString attribute and paste it to your new lookup.

10. Run the application and, in the Forms Designer, bind the combo box to the

WellKey for the new lookup name.

The following steps will display a lookup in the form designer:

1. On the eForms server in the directory

C:\WebApps\ePermitService\StateSpecific, edit the lookups.xml file to

include the new lookup and save the file. Note that the file may be read only.

You will need to change that in file properties before you edit it or you will not

be able to save.

2. Refresh the eFormService virtual directory in IIS in one of three ways:

a. Option 1: In IIS Management, click the server (EFORMS) and click the

Refresh button on the right. This option is fine for development, but

no good once the application is in production.

b. Option 2: In IIS Management, click the website (Default Web Site)

and click the Refresh button on the right. This option is somewhat

better than Option 1, but is still not ideal.

c. Option 3: This change will cause IIS to recompile ONLY the

eFormService, leaving other portions of the website alone. However,

anyone using the website will lose their session with the service, so

you should probably schedule any updates to the production system

after hours.

i. Open C:\WebApps\ePermitService\web.config.

ii. Add or remove a space on some blank line (such as line 11).

iii. Save the file.

Adding Reports for Printing Forms

As additional forms are added to the eForm Silverlight Web application through the

Forms Designer, the agency also will need to provide the ability for site users to

preview the forms in a printable format. SQL Server Reporting Services report

definition language--client (.rdlc) templates are used for this purpose. These


40

templates are stored in the \Reports folder of the eForm Web application. The

hyperlink from the Silverlight application automatically opens the referenced .rdlc file

and exports the result to .pdf for viewing in the browser.

As in other aspects of managing an eForm application, the process of adding new

reports is fairly straightforward, and the process is dependent on the consistent use

of standard naming conventions. In this case, the name of the report (e.g.,

"Form02.rdlc") must match the name of the database form object (e.g., "Form02").

To test, open a browser for eFormMS/WebReportPDF.aspx. This URL accepts the

command line parameters of

DocNum=<specifyDocNum>&report=<FormName>.rdlc.

Creating the .rdlc itself can be the most challenging step in this process. A chapter in

the RBDMS WinAdmin.NET user help manual is devoted to the procedure for

developing reports, including tips for creating and editing .rdlc files within Visual

Studio (http://www.rbdmsonline.org/files/pdf/Printed_Documentation.pdf).

Managing Comments

In the Colorado implementation of eForm v1.0, users who log in with rights

associated with the Public, LGD (local government designee), and Industry roles can

comment on any form that has been marked with a status of Submitted, In Process,

or On Hold. Rules for the Comments form are based on roles. The comments

created by public and industry users are sent to system administrator moderation

before they are posted to the Comments section of the Navigation page. LGD

comments are considered recommended conditions of approval (RCOAs) and are

therefore posted without moderation. The comments and information about their

source and review status are stored in the eFormComment table in the workflow

database.

To moderate the comments, on the Navigation page, click Administration | View

New Comments. The page that opens will display the unreviewed comments in the

queue by CommentDate, Doc ID, User, and Subject. Click the column headers to sort

the comments (ascending-descending) by any of these criteria. Approve and Delete

buttons are provided for comment disposition. Clicking either button sets the


Managing eForm

41

ReviewedDate field. Approved comments are posted to the Web for general viewing.

Deleted comments are set to Approved=False and retained in the table.

Note: The Comments option is implemented in eForm v1.0 only and hasn't been

migrated to the new HTML based Web client (eForm v2) yet.

Assigning Review Tasks and Sending Notifications

The eForm application offers the flexibility to have agency staff review online

submissions through a workflow capability. However, where agencies that use eForm

also use RBDMS.NET, permit information that passes validation and status checks

will flow into the internal RBDMS.NET Permit module for review, if desired.

If the agency opts to use the eForm workflow module, the database administrator

can add the Review Task form to the Review tab when it is appropriate. A LINQ

query that runs when documents are submitted populates the Review tab. This

query reads the template to see which tasks are associated with the form type and it

populates the names of those staff members assigned for each task. Review

assignments are manual. As long as the Assigned to field is in the template record,

the data can be populated.

The table structure created for managing task data is shown below. The basic flow is

as follows:

1. Create eNotify objects. A variety of methods can be used to develop these

eNotify objects: SQL Server stored procedures, scheduled jobs, or .NET

procedures forged in the Creating Rule Sets (see page 20). Each notify record

has a user key, task name, and message.

2. The application will read the eNotify table on a scheduled request cycle and

select records with NotifyComplete = False. An email notification will be

sent to the email address associated with each UserID. The email address is

specified when the users' login security information is set up in the RBDMS

WinAdmin.NET program. After an email is sent, the NotifyComplete field will

be set to True. The notice will be emailed only once.

3. Notifications are not deleted, so users can run a report of notifications at any

time.


42

4. For an agency user to subscribe to the eForm submitted notifications, the

user should be included in the eForm role. The simplest technique for

subscribing to notifications is by associating notifications with specific roles.

Other techniques may be developed in the future to allow users to opt in and

out of specific notifications.

Managing eForm

43

eNotify: Creating a record in the eNotify table will prompt the windows

service (in the Colorado application, called ePermitWindowsService) to

create the e-mail notification. Within this table, the NotifyFrequency is in

days, the UserID is the subscriber (from asp_users or asp_membership),

and the NotifyComplete field is filled in when the notification is sent.

eTask: A table that contains a list of all tasks (short name, description) and

associated roles.

eTaskList: Can be thought of as a “template table” that associates a list of

tasks with each distinct form version: eTaskList.TaskDocument="Form 2." For

example, this table would contain all of the tasks needed to review a Form 2

version 1. Each permutation of TaskDocument (i.e., “Form 2”) and

TaskVersion can have a unique set of tasks assigned.

eFormTask: When a user creates a form (an object assigned a FormID), the

application looks through the table structure to derive a task list from the

template table for the specific form and version number represented by the

object with the FormID. In other words, the eFormTask table contains one

record for each task associated with that specific form.

The grid on the Review tab in the application was created as a user control in the

Forms Designer and the fields mapped appropriately. A LINQ query runs onSubmit of

documents to populate the Review tab. The onSubmit query reads the template to

see which tasks are associated with the form type. When the Review tab reads the

task table, it populates the names of those staff members assigned for each task.

Review assignments are manual. As long as Assigned to is in the template record,

the data can be populated.

Tailoring the Display of Review Tasks on the Dashboard

A lookup called TaskCriteria is used by the dashboard to color the review tasks

subgrid according to the status and due date of the eFormTask. The code for the

Alabama version of the lookup follows.

<Lookup Name="TaskCriteria" CodeType="String" ConnectionString="RbdmsDMZ

ConnectionString">


44

<![CDATA[

--TODO - get from database

--Days as Code, Color (a,r,g,b) as Description

Select '1' Code, '100,255,0,0' Description

UNION


UNION


UNION

Select 'pass' Code, '100,100,100' Description

]]>

</Lookup>

Defining Paths for Form Status Changes

AllowableStatuses is a dictionary defined in ePermitDAL (StateSpecific folder) that

contains the current form status and then the allowable future statuses, along with

messages to be sent to the user when each status change is carried out.

AllowableStatuses is used heavily by eFormOrchestrator. For example, when a form

is in Draft status, its path in the workflow process is restricted to moving only to the

Submitted status. When notification of this status change occurs, the user receives a

message that says “Form %FORMKEY% now requires payment.” where

%FORMKEY% is replaced with the Form.PKey.

For example, in the Alabama installation of eForm, the allowable form statuses move

in the paths shown below:

Public Shared StatusDictionary As New Dictionary(Of FormStatus, Dictionary

(Of FormStatus, String)) From {

{FormStatus.DRAFT, New Dictionary(Of FormStatus, String) From {

{FormStatus.SUBMITTED, "Form %FORMKEY% now requires paymen

t."}

}

},

{FormStatus.SUBMITTED, New Dictionary(Of FormStatus, String) From

{

Managing eForm

45

{FormStatus.RETURNED, "Form %FORMKEY% has been returned fo

r correction. See Form comments for required actions."},

{FormStatus.COMPLETENESSCHECK, "Payment received for Form

%FORMKEY%. Completeness check beginning."}

}

},

{FormStatus.COMPLETENESSCHECK, New Dictionary(Of FormStatus, Strin

g) From {



{FormStatus.ACCEPTED, "Form %FORMKEY% has been accepted fo

r review."}

}

},

{FormStatus.ACCEPTED, New Dictionary(Of FormStatus, String) From {



{FormStatus.HOLD, "Form %FORMKEY% has been placed on hold.

"},

{FormStatus.DENIED, "Form %FORMKEY% has been denied."},

{FormStatus.APPROVED, "Form %FORMKEY% has been approved."}

}

},

{FormStatus.HOLD, New Dictionary(Of FormStatus, String) From {

{FormStatus.ACCEPTED, "Hold on Form %FORMKEY% has been rem

oved."}

}

}

}

ePermitWindowsService Functionality

When the Notify StartTimer function is called, the NotifyFrequency setting is read

from the .config file. The NotifyFrequency includes multiple date intervals (in

decimal day units). The initial setting is for “0.0034722,0.041667,1.” This setting


46

represents 5 minutes, 1 hour, and 1 day, respectively. A list of NotifyInterval objects

is created for each value.

The application .config file also includes a NotifyInterval setting (Minutes). The

NotifyInterval specifies the interval in minutes between triggering the timer elapsed

event.

Each time the timer elapsed event occurs, the NotifyElapsed property of each

NotifyInterval object is incremented with the elapsed time from the timer. If the

NotifyInterval object’s NotifyElapsed value is equal to or greater than the

NotifyFrequency, then it selects eNotify records that have a NotifyComplete of

“False” and have an eNotify.NotifyFrequency less than or equal to the current loop’s

NotifyFrequency.

The eNotify object’s timer is set to use an interval (in fractional days) for querying

the eNotify table. The 1-day interval starts at 12:00AM, the 1-hour intervals start

on the hour, and the 5-minute intervals start at the 5-minute interval immediately

less than the current time (i.e., if the current time is 1:37AM, then the interval will

begin at 1:35AM).

The query will order the results by UserID, DueDate, and FormKey (e.g., Doc_Num).

The program loops through the query results and creates a single e-mail for each

user with a table containing the eNotify records for that user ordered by DueDate

and FormKey. Each loop is wrapped in a transaction and, once the transaction is

complete, the NotifyComplete value for the records in each e-mail is set to “True.”

Agencies may choose to delete eNotify records with NotifyComplete = “True” after a

month or so.

Please see the RBDMS WinAdmin.NET user manual for additional information about

the Notification module.

Flagging Changes to Submitted Data in the Workflow Review Process

Where agencies opt to use the Review Task tab and workflow process features of

eForm, staff may choose to edit data that operators submit in support of a permit

application or completion report. Often agency business processes require tracking

any such edits and revisions to originally submitted data for purposes of noting


Managing eForm

47

special conditions or circumstances. eForm provides the ability to flag such changes

made during the review process. Changes are flagged with a concatenation of the

tool tip message with the original value input to the changed field. These values are

displayed against a colored background. See graphic below:

ePermitGUI App.xaml contains code that controls style setting. The renderer

compares the changed data with the data provided by the web service. Storing and

retrieving the data for this comparison is a state-specific issue. An example is located

in the ePermitService in the StateSpecific folder in the ePermit_SS.vb file in the

GetObjectOriginalState subroutine.

Configuring the Navigation Page

The eForm Silverlight application is sized as a standard 1024 x 768 “skinnable”

window. Content for the page can now be filtered by document status, document

number (FormID), date range, and operator. Users can sort the columns (ascending-

descending).

Changing the columns of metadata displayed for the returned document set is a

fairly straightforward matter of editing the Dashboard.xaml file. The displayed grid

on the main Navigation page is defined by the <local:DataGrid

x:Name="grdForms" ...> tag on this page. However, changing the filter criteria

on the navigation search is a much more complex coding process. This task involves

detailed changes to both the web service and the service definition, which will be

specific to the desired outcome.

The dashboard grid uses the vweFormDashBoard LINQ object rather than a Form

object. This design change allows for including additional fields for navigation (e.g.,

location columns). Although form objects may exist in both the eFormWorkflow and

eFormReview databases simultaneously, vweFormDashboard ensures that forms

are pulled once. Form records are always created in the Submit (Workflow) database

and copied to the Review database. This concept of using both a Workflow (Submit)


48

and a Review database also facilitates the convenience offered by the ability to flag

changes to submitted data in the review process (see page 46).

Using URL Parameters

Using URL parameters can be a convenient means of setting up automated logins,

such as for access of publicly available information, or targeted searches from other

Web pages. The following URL parameters are currently being used in eForm:

Parameter

Name

Description Example

LoginName Default login name LoginName=joe6

Password Default password Password=secret

Operator Operator number if LoginName is in the

Industry role.

Operator=123

Auto If = 1 then automatically attempt login with

default name and password.

Auto=1

FormID

(DocNum)

The document number to lookup immediately

without waiting for user to add filter criteria.

(BaseApplication.FormPKey)

DocNum=10315

Creating Tabs in the Form Renderer Accessible by User Role

Sometimes a need arises to control the visibility and accessibility of a tab in the form

renderer by user role assignment, such as where the agency wants to compile

conditions of approval or other regulatory comments. The method

SetTabMenuPermission can be added to FormRender_Layout.vb and called in

DoTheLastThingBeforeShow() to ensure that when the tab names contain the [*]

keyword, access and use of the tab will be controlled according to rules for the user

roles. This is particularly useful if multiple roles are allowed to see or use the tab, but

it must be hidden for others. For example, this method will allow the use of two tabs,

one named “COA / Comment [Administrator,Agency]” and the other named “COA /

Comment [Industry,IndustryAdmin].” The Agency tab is editable; the Industry one is

Managing eForm

49

read only; and users in the Public role never see either. Note that the “[“ character

is disallowed in the tab name unless you are using it this way.

Sub SetTabMenuPermission()

'//20120606 - DL - Expand on Yihsin's function.

'//[Role1,Role2,...,RoleN] - allowed to view tab

Dim userRoles As List(Of String) = ePermitBaseSL.CurrentUser.instance.

loginInfo.Roles.ToList()

For Each tabcrtl As TabControl In ePermitBaseSL.VisualHelper.GetChildr

en(Of TabControl)(mainGrid)

For Each item In tabcrtl.Items

Dim headerString As String = CType(item, TabItem).Header.ToStr

ing()

If headerString.Contains("[") Then

'//IF USER IS NOT IN AN APPROPRIATE ROLE HIDE THE TAB

Dim sIndex As Integer = headerString.IndexOf("[")

Dim eIndex As Integer = headerString.IndexOf("]")

Dim roleString As String = headerString.Substring(sIndex +

1, eIndex - sIndex - 1)

Dim allowRoles As List(Of String) = roleString.Split(",").

ToList()

Dim bShow As Boolean = False

For Each userRole In userRoles

If allowRoles.Contains(userRole) Then

bShow = True

Exit For

End If

Next

If Not bShow Then

CType(item, TabItem).Visibility = Windows.Visibility.C

ollapsed


50

End If

'//Remove the [Role1,Role2,...,RoleN] from the tab name

CType(item, TabItem).Header = CType(item, TabItem).Header.

ToString.Replace("[" & roleString & "]", "")

Else

'//SHOW THE TAB (do nothing)

End If

Next

Next

''[*] TabItem is visible only for Administrator and Agency

'For Each tabcrtl As TabControl In ePermitBaseSL.VisualHelper.GetChild

ren(Of TabControl)(mainGrid)

' For Each item In tabcrtl.Items

' If CType(item, TabItem).Header.ToString().ToLower().Contains(

"[*]") Then

' Dim roleNames As List(Of String) = ePermitBaseSL.CurrentU

ser.instance.loginInfo.Roles.ToList()

' If roleNames.Contains("Administrator") OrElse roleNames.C

ontains("Agency") Then

' CType(item, TabItem).Visibility = Windows.Visibility.

Visible

' Else

' CType(item, TabItem).Visibility = Windows.Visibility.

Collapsed

' End If

' CType(item, TabItem).Header = CType(item, TabItem).Header

.ToString().Replace("[*]", "")

' End If

' CType(item, TabItem).Header = CType(item, TabItem).Header.ToS

tring().Replace("|", vbCrLf)

' Next

'Next

End Sub

Managing eForm

51

All tabs are visible by default. By using mutually exclusive lists of roles in the two

tabs, only one tab will ever be visible if the user is in one of the role lists. Since

Public is not in either role list, neither tab will ever be visible to Public.

Here are the forms (one set for _Admin, one set for others):

The main form tab setup is shown below (The COA/Comment tab uses

eFormCommentContainer_Admin. The Agency Comments uses

eFormCommentContainer):

Here is the Admin/Agency view:


52

Here is the Industry/IndustryAdmin view:

Understanding Application Data Flows

53

Section 5

Updating an Existing eForm Application

Updating an Existing Installation on the Server

Once you have (1) created a new DAL object and its associated rule set and form objects,

(2) compiled the application, and (3) tested it in the development environment, the next

step is to copy the files to the live Web server.

Successfully updating an existing eForm Web application is contingent on understanding the

folder structure of the application and the nature of the changes that you have made in

Visual Studio. The update process basically consists of copying any updated components

from the local ePermit solution folder to the Web server folder of the same name. Be sure to

test the application thoroughly before releasing it to the public.

You will need to update the eForm database from the development server to the live server

if objects have been added or to script the creation of such objects (e.g., ConstructCasing

and other tables). Be sure that the identity of primary key is present.

To identify which files are to be uploaded to the server, use the Publish option in the context

menu of the project within the solution explorer. When configuring the publish profile, select

the File System publish method and specify a /publish subfolder within the corresponding

project. For ePermitService, see the example below:

On the Settings tab, Configuration field, select Release. Under File Publish Options,

select Delete all existing files prior to publish:


54

Updating the application is a matter of opening two Windows Explorer panes: one to

eFormService(State Abbreviation) location and the other to the publish folder in the

development environment and choosing ePermitService.

Compare date stamps on both folders to know which files to copy. Do not copy the

Web.config from the development environment. If you have added a new setting in the

Web.config file, you will need to edit the Web.config for the production server and add the

setting manually.

Please see the following topics for additional information:

Updating the eForm Silverlight Web Application (see page 55)

Updating an Existing eFormService Application (see page 57)

Configuring the Navigation Page (see page 47)

Updating the eForm MVC Web Application

In the solution explorer of the development environment, right click on the eFormMVCGUI

project and select the Publish option. Specify a publish folder within the project directory.

The directory structure of the publish folder is shown on the figure below:


55

\bin folder: contains the required dll-s and images supporting the MVC application.

\Content folder: contains a set of css/map for the bootstrap library used by the

application.

\CSS folder: contains a set of css files and images for the MVC application.

\JS folder: contains a set of javascript library files used by the MVC application.

\Reports folder: contains .rdlc files that support the View/Print capabilities (see

page 39).

\Scripts folder: contains the bootstrap javascript library files.

\Service References folder: contains the configured service reference file to

ePermitService.

\Views folder: contains views of the MVC application in a hierarchical structure. For

more information about the Views see: Views in eForm HTML (see page 74).

When recompiling the application, remember to copy changes to the affected views of the

changes as well as copy the modified binary files from the /bin directory.

Updating the eForm Silverlight Web Application

In the development environment, navigate to the form2SL_ \ClientBin. The

ePermitGUI.xap file is the only one you need to copy.


56

The folder structure for the eForm Silverlight Web application [eForm(State

Abbreviation)] on the application server is shown below. Areas of note:

\ClientBin folder: contains the Silverlight client and .xap files. As of the November

2009 release, the three .xap files included in this folder are RenderingEngine.xap,

ePermitGUI.xap, and LayoutEditor.xap. As the eForm application matures, the

number of files in this folder will grow. Once you have copied the updated .xap files,

you will need to edit the ePermitGUI.xap on the server as follows:

a. Open the ePermitGUI.xap file with a .zip file application.*

b. Edit the ServiceReferences.ClientConfig file.

c. Modify the endpoint address to match the location of the eFormService. Follow

this pattern: "http://RbdmsOnline.org/eFormService/ePermit.svc."

d. Save the updated .xap file.

\Bin folder: contains the .aspx Web supporting the Silverlight application.

\Reports folder: contains .rdlc files that support the View/Print capabilities (see

page 39).


57

*Tip: .xap files are packaged archive files like .zip files that are used in deploying Silverlight

applications. The developers recommend using a product called 7-Zip to edit these files. 7-

Zip is free from http://www.7-zip.org/.

Please also see Configuring the Navigation Page (see page 47).

Updating an Existing eFormService Application

The folder structure for the eFormService WCF middle-tier application is shown below. Areas

of note:

\ePermit root folder: contains the Silverlight files (.svc.vb, .xml, vbproj,

vbproj.user, and .vb).

\Bin folder: contains the .dll, .pdb, and .xml files used by the application.

http://www.7-zip.org/


58

Please also see Configuring the Navigation Page (see page 47).


59

Section 6


Understanding ASP.NET MVC

To implement eForm HTML (v2), we use the ASP.NET MVC (model-view-controller) design

pattern. The application implementation can be found in the eFormMVCGUI project within

the eForm solution.

In the ASP.NET MVC framework, the application logic is implemented by a set of controllers

that are used to manipulate the data encapsulated by model classes. The controllers are also

responsible for handling user interactions and choosing the view to display on the client side.

The controller is like the glue that holds the model and views together according to the

figure below.

Note: In the Visual Studio solution explorer, the controllers are stored in the Controllers

folder, while the models are stored in the Models folder, and the views, in the Views folder.

Routing in ASP.NET MVC

Routing is the process for binding URLs to specific controller actions. Before ASP.NET MVC,

URLs in Web application mapped to physical files at a disk location. For example, to

implement Print Preview in eForm HTML, we used the following pattern:

http://localhost/WebReportPDF.aspx?doc_num=1439&report=FormOGB1.rdlc


60

which maps to a physical file (WebReportPDF.aspx) location on the Web server.

However, when the framework receives a request in ASP.NET MVC, it now routes the request

to an action method of the controller.

The URL patterns that we define are known as routes. In a route, we specify placeholders

that are mapped to values that are parsed from the URL request. We can also specify

constant values that are used for matching URL requests.

The following table shows valid route patterns and examples of URL requests that match the

patterns.

Route definition Example of matching URL

{controller}/{action}/{id} /Products/show/beverages

{table}/Details.aspx /Products/Details.aspx

blog/{action}/{entry} /blog/show/123

{reporttype}/{year}/{month}/{day} /sales/2008/1/5

{locale}/{action} /en-US/show

{language}-{country}/{action} /en-US/show

To determine which action to invoke, the framework uses a route table. Typically, we add

routes in a method that is called from the handler for the Application_Start event in the

Global.asax file, according to the following example:

Sub Application_Start()

RouteConfig.RegisterRoutes(RouteTable.Routes)

End Sub

Public Class RouteConfig

Public Shared Sub RegisterRoutes(ByVal routes As RouteCollection)

routes.MapRoute( _

name:="Default", _

url:="{controller}/{action}/{id}", _

defaults:=New With {.controller = "Home", .action = "Index", .id =

UrlParameter.Optional} _

)

End Sub


61

End Class

Modifying the Default Routing Behavior

In eForm HTML, the default routing behavior is slightly modified by implementing

HttpApplication.AcquireRequestState in (Global.asax.vb). For each URL request, the

application checks whether the user is logged in or not. The logged in state is stored in a

session variable (SessionUtils.SessionVariables.LoginInfo), and if it is not set, the user

should be redirected to the login page (Response.Redirect("~/Login", True)). Another

requirement is that if the URL request refers to a specific form, we must return to the

requested form right after the user provides the login credentials. For this reason, the URL is

stored in another session variable for further use (SessionUtils.SessionVariables.VisitPage).

Understanding Windows Communication Foundation and Its Configuration in

eForm

Windows Communication Foundation (WCF), a core component of .NET Framework, provides

a service-oriented programming model, run-time engine, and tools for building connected

applications. WCF unifies and extends the functionality of existing Microsoft connecting

technologies by providing a single programming model independent of underlying

communications protocols. WCF applications use open standards and protocols to

interoperate with existing Microsoft and non-Microsoft technologies.

WCF models network communication that consists of message exchanges between a client

and a service. When a client sends a message, it travels through multiple layers of software,

each performing some operation on the message, before being transported across the

network to the server. At the server, the message again travels through multiple layers of

software before being delivered to the service. These multiple layers of software are known

as the communication stack. Each layer is governed by one or more standards or protocols,

which specify the end result of the operation on the message at that layer.

In WCF, the communication stack is represented as a binding. A binding consists of a set of

binding elements, each of which represents a layer in the stack. The implementation of a

binding element is known as a channel. At run time, WCF assembles the stack of channels

specified by the binding. When data is sent, WCF translates the data into a message and


62

passes the message through the stack of channels, so that the message is sent in

accordance with the protocols identified by the binding. This process is reversed on the

receiving end.

The core concept behind WCF is the service, which is a .NET type that implements one or

more service contracts with each contract exposed through an endpoint.

The endpoint expresses all the information needed by a client to communicate with a

service. An endpoint consists of an address, a binding, a contract, and optional behaviors.

The address specifies where the service is located for a specific service contract. The binding

declares the set of protocols that are used to send and receive messages. The contract

defines the kind of messages that can be sent and received. Behaviors control optional

service and client functionality.

For more details of the WCF technologies, refer to https://msdn.microsoft.com/en-

us/library/cc179585.aspx.

Endpoints can be defined programmatically or in an XML configuration file. For

ePermitService, we configure a single endpoint in web.config according to the following

example:

<system.serviceModel>

<client>

<endpoint

address="http://csweb.coordinatesolutions.com/ALePermitService/ePermit.svc"

binding="basicHttpBinding" bindingConfiguration="basic"

contract="ePermitService.IePermit" name="basic"/>

</client>

</system.serviceModel>

The http binding is configured as follows:

<bindings>

<basicHttpBinding>

<binding name="basicBinding" sendTimeout="00:05:00"

bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"

https://msdn.microsoft.com/en-us/library/cc179585.aspx

https://msdn.microsoft.com/en-us/library/cc179585.aspx


63

maxBufferSize="10000000" maxBufferPoolSize="10000000"

maxReceivedMessageSize="10000000" messageEncoding="Text"

transferMode="Buffered" useDefaultWebProxy="true">

<readerQuotas maxDepth="1024" maxStringContentLength="16777216"

maxArrayLength="16777216" maxBytesPerRead="16777216"

maxNameTableCharCount="16777216"/>

<security mode="None">

<transport clientCredentialType="None" proxyCredentialType="None"

realm="">

<extendedProtectionPolicy policyEnforcement="Never"/>

</transport>

<message clientCredentialType="UserName"

algorithmSuite="Default"/>

</security>

</binding>

</basicHttpBinding>

</bindings>

Javascript Libraries Used by the Application

The eForm HTML (v2) application utilizes a set of javascript libraries to provide extended

functionality on the client side.

jQuery

jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML

document traversal and manipulation, event handling, animation, and Ajax much simpler

with an easy-to-use API that works across a multitude of browsers. With a combination of

versatility and extensibility, jQuery has changed the way that millions of people write

JavaScript.

To get an element from the document object model (DOM), we use a jQuery selector like

this:

$("#newwellmodaldiv").modal('hide');


64

To register an event in jQuery, we use the following syntax:

var hiddenBox = $( "#banner-message" );

$( "#button-container button" ).on( "click", function( event ) {

hiddenBox.show();

});

We can also invoke asynchronous (AJAX) calls to the server to query data according to the

following example:

$.ajax({

url: "/api/getWeather",

data: {

zipcode: 97201

},

success: function( data ) {

$( "#weather-temp" ).html( "<strong>" + data + "</strong> degrees" );

}

});

For more details about the jQuery library, please refer to the API documentation

(http://api.jquery.com/).

jQuery UI

jQuery UI is an extension built on top of the jQuery JavaScript Library that provides a set of

user interface interactions, effects, widgets, and themes. Whether we're building highly

interactive Web applications or you just need to add a date picker to a form control, jQuery

UI is the perfect choice. Both jQuery and jQuery UI are free and open-source software

distributed by the jQuery Foundation under the MIT License.

As an example of how we used library we implemented the autocomplete option by using

the jQuery UI autocomplete widget:

this.input = $("<input>")

.appendTo(this.wrapper)

http://api.jquery.com/

http://en.wikipedia.org/wiki/Free_and_open-source_software

http://en.wikipedia.org/wiki/MIT_License


65

.val(value)

.attr("title", "")

.addClass("custom-combobox-input ui-widget ui-widget-content ui-state-default

ui-corner-left")

.autocomplete({

delay: 0,

minLength: 1,

source: $.proxy(this, "_source"),

})

.tooltip({

tooltipClass: "ui-state-highlight"

});

For more information about the jQuery UI library, please refer to the API documentation at

http://api.jqueryui.com/

jqGrid

jqGrid is an Ajax-enabled JavaScript control that provides solutions for representing and

manipulating tabular data on the Web. Since the grid is a client-side solution loading data

dynamically through Ajax callbacks, it can be integrated with any server-side technology,

including PHP, ASP, ASP.NET, Java Servlets, JSP, ColdFusion, and Perl. jqGrid uses the

jQuery Java Script Library and is written as a plugin for that package.

jqGrid supports the following features:

Displays the grid equally well in most common browsers, including IE, Firefox,

Chrome, Safari, Opera

CSS customizable with full Themeroller support

The UI comes in 20+ languages

Paging and sorting

Search and filtering

In-place cell editing or on-the-fly form creation to edit a record

Supports subgrids and tree grids for displaying hierarchical data

AJAX enabled

Accepts XML/JSON/local array data sources

http://api.jqueryui.com/


66

In eForm MVC, both the dashboard and the form renderer utilizes jqGrid to display the

tabular data on the page. The data displayed in the grid can be loaded automatically from

the JSON return data or the grid can also be filled programmatically using javascript code.

For more information about the jqGrid library, refer to the documentation page at:

http://www.trirand.com/jqgridwiki/doku.php?id=wiki:jqgriddocs.

Bootstrap Library

Bootstrap is the most popular HTML, CSS, and JS framework for developing responsive,

mobile first projects on the Web. The bootstrap library supports responsive web design

(RWD), which means that the layout of Web pages adjusts dynamically, taking into account

the characteristics of the device used (desktop, tablet, mobile phone).

Bootstrap provides a set of stylesheets that provide basic style definitions for all key HTML

components. These provide a uniform, modern appearance for formatting text, tables and

form elements.

In addition to the regular HTML elements, Bootstrap contains other commonly used interface

elements. These include buttons with advanced features (e.g. grouping of buttons or buttons

with drop-down option, make and navigation lists, horizontal and vertical tabs, navigation,

breadcrumb navigation, pagination, etc.), labels, advanced typographic capabilities,

thumbnails, warning messages and a progress bar. The components are implemented as

CSS classes, which must be applied to certain HTML elements in a page.

Bootstrap comes with several JavaScript components in the form of jQuery plugins. They

provide additional user interface elements, such as dialog boxes, tooltips, and carousels.

They also extend the functionality of some existing interface elements, including, for

example, an auto-complete function for input fields. In version 2.0, the following JavaScript

plugins are supported: Modal, Dropdown, Scrollspy, Tab, Tooltip, Popover, Alert, Button,

Collapse, Carousel and Typeahead.

For more information about the bootstrap library, see: http://getbootstrap.com/.

http://www.trirand.com/jqgridwiki/doku.php?id=wiki:jqgriddocs

http://en.wikipedia.org/wiki/Responsive_web_design

http://en.wikipedia.org/wiki/JQuery

http://getbootstrap.com/


67

Application Architecture

eForm is an integrated set of server tools that are based on ASP.NET MVC and

HTML/JavaScript (external client), Silverlight (internal client), a Windows Communication

Foundation (WCF) middle tier, and a SQL Server intermediary database in a DMZ used to

submit forms and another used to review forms. These databases are replicated behind a

firewall and flow information to the primary database.

The main structure of the application is shown on the figure below:


68

On the client side of the application, the functionality is provided in the browser using

HTML/javascript/MVC (form renderer v2) or Silverlight (form designer or renderer v1) for

the Public, Industry or Agency users. Both architectures are provided by an ASP.NET

backend running on the configured IIS server.

The MVC or the Silverlight clients utilize the services provided by ePemitService to access

the databases through ePermitDAL (data access layer). ePermitService is an ASP.NET web

service providing a set of Web methods like getForms or getLookupBy... in a WCF

application. For more information about the WCF technologies, see: Understanding Windows

Communication Foundation (page 61).

eForm MVC Implementation Details

Forms Designer

The Forms Designer has not changed significantly. We use the same Silverlight application to

design eForms for eForm MVC, too. The designed forms will continue to be saved in the

database in XAML format. The MVC form renderer is responsible to convert the XAML

representation to a sufficient HTML format extended with the required javascript

functionality on the client side.

Grid Row Details

The most significant change in the design interpretation is related to the grid row details

functionality. The grid row details functionality is, in fact, a subgrid in each row of a grid,

which provides additional functionality for any given row.


69

The definition of a grid in Forms Designer includes up to three rows, with two being

required.

Row 1: Grid header text.

Row 2: Data entry controls.

Row 3 (optional): The first column includes the control to be used as grid row details

for the row. The control specified for grid row details can be complex and include any

non-custom, non-grid control in the system.

The grid definition, including grid row details, of the example above looks like this:

Definition of the Well_GridDetails control specified above:


70

Validation Changes

The validation provides the option to check the compliance of the entered data before

submitting a form. The validation errors are shown on the left side of the form in a floating

div section.

During the validation operation, each object is converted to serialized DataReturn objects

and passed to ePermit service and has its own type rules validated.

Cross Object Validation

Formerly eForm validated each object individually, and there was no context. This approach

has now been extended to support the cross object validation. For this purpose, we added

the Validation method for BaseApplication and BaseApplicationSubtype that returns nothing,

but could be overridden to validate in .Net code, so each derived classes could implement

validation in a consistent way. With this approach, ePermit.ValidateRules would hit the

ValidateRule method with the RuleSet and also hit the Validate method, which is custom

code that can be used to add to the errors and warnings collections.

From the perspective of the form renderer, when the renderer passes the DataReturns to

the service, the BaseApplication object must include all children/associations in the

ValidateRules service method.

Client Side Validation

In addition to the cross object validation, we added an option to do some validation checks

in the MVC application that do not require calling ePermitService. For this reason, the

Validation method in FormController.vb also calls eReportUtils.Validate, which can execute

validation rules on the provided data sources. The client side validation provides the result

as a list of warnings in a collection, which are then added to the warnings coming from the

ePermitService validation.

Controllers in eForm HTML

The controller is, in fact, a custom class that inherits from the Controller class (which in turn

inherits from the System.Web.Mvc.IController interface). A typically implemented controller

contains one or more action methods. The actions in the controller operate on model classes


71

to provide access to the data and to enforce validation rules, check constraints, and provide

an object-oriented representation of the data and methods for binding to the views. Thus,

the controller serves as a mapping layer that creates a relationship between the models and

views.

In eForm HTML, we implement the following controllers to serve user requests through

action methods.

HomeController

HomeController is the default controller that is called when no controllers or actions are

specified in the URL request. In this case, the default (Index) action is called, which redirects

to the Index action of LoginContoller.

LoginController

LoginController implements only the default Index action. The GET action returns the view

for the login page (Views/Login/Index.vbhtml) to display the form with the

username/password and operator text boxes. When the Login button is pressed, the POST

action of the login controller is called with the specified values in the POST data. To obtain

the login information, the controller calls the Login service method of ePermitService. If the

login was successful, the login information is stored in a session variable for further use.

DashboardController

As soon as the login is successful, the LoginController redirects to the (state specific)

dashboard page by using the /Dashboard/[state abbrev] URL pattern. The default routing

maps this request to the corresponding method in DashboardController.vb. The controller

returns the state specific version of the dashboard view. For example, the AL controller

action returns Views/Dashboard/Alabama.vbhtml.

Before returning the view, the controller action returns the possible values of the filter

combo boxes to be displayed through a set of GetLookupBy... calls to ePermitService. We

also should modify the view according to the logged in user. For example, the user should be

able to select only from the assigned operator list.


72

The DashboardContoller operates on DashBoardDataModel (implemented in Models/

DashBoardDataModel.vb). This model has no direct data access support, but it provides to

serialize/deserialize the parameters to be used on the dashboard view.

FormController

FormController is an essential part of the eForm MVC application that handles the actions

related to the form editing submitting saving and validation.

When a form is selected for editing on the dashboard, the Edit action of FormController is

called, which returns Views/Form/Edit.vbhtml to render the specified form. The Edit action

receives the FormKey and the optional well API number parameters. For the specified form,

the controller does some checks first to determine whether the specified form is editable and

redirect to the dashboard if the user is not allowed to edit that form. If the form is editable,

the following operations are executed:

1. Get the form associated with the specified form key (IePermit.GetForm).

2. Get the object(s) specified by the form type or subtype (IePermit.GetObject).

3. Get the form layout for rendering (IePermit.GetLayoutForRendering).

4. For new forms, create a data source from the layout information.

5. Start form rendering (FormRenderer.RenderingHelperHTML.RenderLayout), which

prepares the HTML/JS code to be returned to the client. For more information about

the rendering details, please refer to this chapter: Implementing the HTML Form

Renderer (page 77).

6. Prepare view by setting ViewData. The rendered dynamic HTML data is added to the

MSG parameter, which is included in a <form> section of the edit view.

7. Return the view to the browser.

When the Validate, Save or Submit button is pressed on the form, the validation is

executed through a POST action to the Validation method of FormController. The entered

data is automatically added to the POST data by the browser. The current action type to be

executed is stored in a session variable (by calling SetActionJson from the javascript client).

The Validation action method prepares the form data in a collection of DataReturn classes of

FormController and calls IePermit.ValidateRules for each DataReturn class. The returned

validation messages are added to the Errors and Warnings collections.


73

After the validation is executed, the action method behaves differently according to the

action type set previously.

1. If the action type is "Save" and no errors returned from the validation, the

IePermit.SaveObject is called with the prepared form data.

2. If the action type is "Submit" and no errors or warnings returned from the validation,

the IePermit.SetStatus is called with the status "Uploaded". This modifies the form

status in the database and eFormOrchestrator will be responsible to take the

necessary further actions.

3. If the action type is "Exit" the controller redirects to the dashboard.

The default Index action of the form controller is executed basically if a new form is added.

In this case, the new form is prepared in the database first (IePermit.GetNewForm) and then

the Edit action is called for the newly created form.

Preserving the Form State During Form Editing

When editing a form, the FormController stores the form state (including the actual form

data) in a session variable (of type FormUtils.FormStateStruct). The definition of the

structure looks like this:

Public Class FormStateStruct

Public HTMLFormElement As FormRenderer.FormElement = Nothing

Public WasChange As Boolean = False

Public ActionType As String = "Validation"

Public Form As ePermitService.Form

Public Layout As ePermitService.Layout

Public Mode As String

Public DataSources As Dictionary(Of String, FormUtils.DataBinding) = New

Dictionary(Of String, FormUtils.DataBinding)

Public fromMainDsKeys As List(Of String) = New List(Of String)

Public fromGridDsKeys As List(Of String) = New List(Of String)

Public FormSubType As String

Public errors As Dictionary(Of Object, Object)

Public warnings As Dictionary(Of Object, Object)

Public validationfunctionerror As String = Nothing

Public EntityKey As String

Public RealTimeFieldValues As New Dictionary(Of String, Object)

End Class


74

In this structure, we store the generic parameters of the form, the layout, the HTML form

element, the EntityKey, as well as the current form data, the modified flag, and the result of

the recent validation operation.

Regarding the data grids rendered by eForm HTML, the current approach ensures that the

form data in the session variable reflects the actual state of the edited grid on the user

interface.

Views in eForm HTML

In ASP.NET MVC, the views are implemented by a set of html script files. For eForm HTML,

we have divided the views into different parts located in the different folders. The views are

returned by the corresponding controllers, which are rendered by the browser as an HTML

page.

ASP.NET Razor - Markup

To define the view pages, we use the razor syntax. Razor is a markup syntax that lets you

embed server-based code (i.e., Visual Basic) into web pages.

Server-based code can create dynamic web content on the fly, while a web page is written

to the browser. When a web page is called, the server executes the server-based code inside

the page before it returns the page to the browser. By running on the server, the code can

perform complex tasks, like accessing databases.

Razor is based on ASP.NET, and it is designed to create Web applications. It has the power

of traditional ASP.NET markup, but it is easier to use and easier to learn.

Razor uses a syntax that is similar to PHP and Classic ASP.

Razor:

<ul>

@for (int i = 0; i < 10; i++) {

<li>@i</li>

}

</ul>

PHP:

<ul>

<?php

for ($i = 0; $i < 10; $i++) {

echo("<li>$i</li>");

}


75

?>

</ul>

Web Forms (and Classic ASP):

<ul>

<% for (int i = 0; i < 10; i++) { %>

<li><% =i %></li>

<% } %>

</ul>

Using Layout Pages in ASP.NET MVC

Layout pages help to maintain a consistent look and feel across the pages within the Web

application. ASP.NET 2.0 introduced the concept of “master pages,” which helps enable

consistency when using .aspx based pages or templates. Razor also supports this concept

with a feature called “layouts” that allow us to define a common site template and then

inherit its look and feel across all the views/pages on the site.

Razor makes it easy to start from an existing page and refactor it to use a layout. We need

to add a Razor layout page to the Views section by selecting the Add -> New Item in the

context menu of the Solution Explorer. Then we need to modify the existing view by adding

a reference to the layout page like this:

@Code

ViewData("Title") = "Alabama eForm"

Layout = "~/Views/Dashboard/_Dashboard_LayoutPage.vbhtml"

End Code

Within the layout page, we call the @RenderBody() method to indicate where we want the

views based on this layout to “fill in” their core content at that location in the HTML. We are

outputting the Viewdata("Title") property within the <title> element of our <head>

section.

Layout pages may also provide a sufficient location to include common javascript or css files,

which should be used across multiple pages.

Dashboard View

The dashboard view page (Dashboard/[state].vbhtml) is divided to various sections with

accordion panels for example the "New Application" section to create new forms and the


76

"Reports" section to query for the exiting forms and display the results in a grid. The grid on

the dashboard is implemented by using the jqGrid javascript library (see page 65).

On the dashboard page, we also host a couple of modal divs (payment dialog, new well

dialog), which are displayed for the user when invoking the corresponding operation.

Edit View

The edit view (Form/Edit.vbhtml) is used to render the form in edit mode. The view is

returned by FormController from the Edit action method.

The edit view shares a common layout page with the dashboard

(Views/Dashboard/_Dashboard_LayoutPage.vbhtml), which provides the same header

(containing the logo image and the logged in user as well as the logout button). The layout

page includes the common stylesheet and javascript files for the attached views. The

common layout page also contains the loading div, which is used by both the dashboard and

the form renderer.

The edit view is divided to the following sections:

1. In the FormData section we display the common information related to the form

(operator name, form id, form type, form status, modified date, submitted status)

2. In the Errors and Warnings section, we display error or warning messages related to

the user actions (like validation).

3. In the script section, we added a set of JavaScript functions to implement the client

side code of the form editing. We also have some sections like

ViewData("SendFunctions") where dynamic JavaScript code is generated by the

form renderer. For more information about the rendering internals, see:

Implementing the HTML Form Renderer (page 77).

4. In the <form> section of the edit view, we place the static and dynamic HTML

content, including the edit controls and grids. When executing Validate/Save/Submit

action types, the contents of the HTML controls are being sent to the Validation action

of the form controller including the actual values of the controls in the POST data.

Login View


77

The login view (Login/Index.vbhtml) is used to display the login page for the application.

The login view has a specific layout page (/Views/Login/_LayoutPage.vbhtml)

assigned, which includes the common stylesheets and JavaScript files used and also contains

the loading div displayed during the login operation. This layout page is somewhat different

from the dashboard layout page in that it does not contain the same logo image or logout

button.

The login page contains separate sections for the title and the state logo. Both sections are

filled dynamically by the login controller with the state specific information.

The most essential part of the login page is the <form> section, which contains the HTML

controls to get the login credentials and the optional operator code. When pressing the

Login button, the values are sent to the login controller as a POST request.

Implementing the HTML Form Renderer

The core functionality of the HTML form renderer is implemented in the RenderLayout

method of (Utils/FormRenderer.vb). The layout to be rendered is contained by the first

parameter (ePermitService.Layout), and the result of the rendering operation is placed

into the second (FormElement) parameter.

The layout may also contain multiple child controls (in the LayoutChilds collection). For each

layout child, the RenderLayout method is called recursively, which renders the entire

hierarchy in a consistent way.

When rendering an individual control, the RenderControl operation is called by the form

renderer. When rendering the controls, we rely heavily upon a set of predefined styles

defined in CSS/FormRenderer.css. The implementation of the rendering operation depends

on the type of form element (ElementType enumeration), which is described in more detail

in the following chapters.

Form Elements

The FormElement is a custom class in the renderer that stores all information related to a

single element. The FormElements are created dynamically for each control, and the internal

state is prepared according to the control type. For example, when preparing the form


78

element of a combo box, we call the corresponding GetLookup method of ePermitService to

retrieve all the possible values to be added to the HTML combo box.

Rendering Labels

The label elements are translated directly to HTML <label> fragments. The font size of the

labels is set by using a corresponding CSS class with the "fs" prefix in the class name. If the

align parameter is set for the label, the HTML needhalign parameter is also included in the

result.

Rendering Text Boxes

Text boxes are translated to HTML <input type="Text" ..> elements. The renderer fills the

ID, Name and Value parameters according to the specified control ID and value. If the text

box is read only, then the HTML readonly parameter is also set by the renderer.

If the text box has an original value, we assign the "originalvalue" CSS class to the HTML

element, which displays the element with a red outline and adds the original value to the

tooltip section.

We register a change function (ChangeValue) for each text box control that is implemented

in (Views/Form/Edit.vbhtml) and executes the OriginalValueJson action method of the form

controller to check whether the original value should be displayed in addition to the actual

value.

Rendering Text Areas

Text areas are translated to HTML <textarea> elements. The renderer fills the ID, Name

and parameters according to the specified control ID, and the inner text is set to the actual

value. If the text box is read only, then the HTML readonly parameter is also set by the

renderer.

If the text area has an original value, we assign the "originalvalue" CSS class to the HTML

element, which displays the element with a red outline and addsthe original value to the

tooltip section.


79

We register a change function (ChangeValue) for each text box control that is implemented



value.

Rendering Check Boxes

Check boxes are translated to HTML <input type="checkbox" ..> elements. The renderer

fills the ID and Name parameters according to the specified control ID. The checked style of

the check box is set according to the value of the form element. If the check box is read

only, then the HTML readonly parameter is also set by the renderer.

If the check box has an "original value", we assign the "originalvalue" CSS class to the HTML

element, which displays the element with red outline and adds the original value to the

tooltip section.

We register a change function (ChangeValue) for each check box control that is implemented



value.

Rendering Date Pickers

Date pickers are translated to jQuery UI date picker elements, which renders the control as

HTML <input type="Text" ..> element and calls the datepicker javascript function on

that element to extend its behavior. For more information about the jQuery UI date picker,

see: http://jqueryui.com/datepicker/.

The renderer fills the ID, Name and Value parameters according to the specified control ID

and value. If the control is read only, then the HTML readonly parameter is also set by the

renderer.

If the date picker has an "original value", we assign the "originalvalue" CSS class to the

HTML element, which displays the element with a red outline and adds the original value to

the tooltip section.

http://jqueryui.com/datepicker/


80

We register a change function (ChangeValue) for each date picker control that is

implemented in (Views/Form/Edit.vbhtml) and executes the OriginalValueJson action method

of the form controller to check whether the original value should be displayed in addition to

the actual value.

Rendering Combo Boxes

Combo boxes are translated to HTML <select> elements. The renderer fills the ID and

Name parameters according to the specified control ID. By default, only one option item is

added to the combo box with the name "Select One". If the combo box is read only, then the

HTML readonly parameter is also set by the renderer.

If the combo box has an "original value", we assign the "originalvalue" CSS class to the

HTML element which provides to display the element with red outline and the original value

is added to the tooltip section.

We register a change function (ChangeValue) for each check box control that is implemented



value.

Combo Box Preparation and Lookups

When preparing the form element of a combo box, the SetTypeCombobox helper function is

called. This method creates a ComboItems collection for the form element and calls the

proper version of a GetLookupBy... method of ePermitService to fill the collection with the

possible items.

Rendering Tab Controls

The tab control is translated to jQuery UI tabs element, which is required to prepare the

HTML in the following structure:

<div id="tabs">

<ul>

<li><a href="#tabs-1">Tab title 1</a></li>



</ul>

<div id="tabs-1">


81

<p>Tab content 1</p>

<div id="tabs-2">


</div>

<div id="tabs-3">


</div>

</div>

On the client side, the tabs JavaScript function is called to extend its behavior according to

the following example:

<script type="text/jscript" >

$(function() {

$( "#tabs" ).tabs({

collapsible: true

});

});

For more information about the jQuery UI tabs widget, see: http://jqueryui.com/tabs/.

The renderer fills the ID, Name and Value parameters according to the specified control ID

and value. If the control is read only, then the HTML readonly parameter is also set by the

renderer.

During the preparation phase of the form element (implemented in SetTypeTabControl), the

TabPages collection is filled by the parameters of each tab page to be added. When the

HTML fragment of the tab page is rendered, the tab header is filled according to the

m_TabHeader values, and the tab contents are filled according to the m_HTMLOut values of

the corresponding tab page collection item.

Tab Role Visibility

When rendering the tabs, one or more tab pages may be hidden depending upon the user’s

current role. The allowed roles are enumerated in square brackets within the tab header

string, which is extracted when the form element is prepared (in SetTypeTabControl). If the

tab page is not allowed to be displayed, the form renderer fills a disabled tab list, which is

passed to the client side through the "DisableTab" ViewData parameter. The tab page is then

disabled by the javascript code invoked from the document.ready function.

http://jqueryui.com/tabs/


82

The form renderer is also capable of the initial selection of a specific tab, which is set

according to the "ActiveTab" ViewData parameter invoked from the document.ready

function.

Rendering Grids

In eForm HTML, we support two types of grids: ElementType.Grid and

ElementType.DataGrid. ElementType.Grid is used to provide a tabular layout for child

controls (of arbitrary type), while ElementType.DataGrid provides tabular layout with data.

In this chapter we describe the details of rendering ElementType.Grid. For more information

about rendering data grids rendering, see: Rendering data grids later in this document.

Data grids are translated to HTML <table> elements. When preparing the grid (in

FormRenderer.SetTypeGrid), we read the XAML definition of the grid and store the width of

each column and the height of each row in a separate collection for further use. Then we

enumerate each cell in the grid definition to create a new form element and store the results

in the two-dimensional array.

When the grid layout is rendered, we call the rendering operation recursively for each grid

cell and place the HTML content into the corresponding cell of the HTML table. When

rendering the grid cells, we also set the rowspan, colspan and cell alignment according to

how it was specified in the XAML definition.

Rendering Data Grids

Data grid controls are rendered by utilizing the jqGrid javascript library. jqGrid is an Ajax-

enabled JavaScript control that provides solutions for representing and manipulating tabular

data on the Web. For more information about the jqGrid library, refer to the jqGrid (see

page 65).

Loading Data for the Grid

For eForm HTML, the form renderer creates the HTML <table> section and the necessary

javascript code for the grid elements, but the data is retrieved asynchronously by using an

AJAX call to the GetGridDataJson method of FormController.


83

When editing a form, the state of the grid (including the actual form data) in a session

variable (of type FormUtils.FormStateStruct) and the current approach ensure that the form

data in the session variable reflects the actual state of the edited grid on the user interface.

Rendering the Grid Cells

Each grid can contain arbitrary types of control elements. Therefore, we call the generic

RenderLayout method for each part. For this reason, in the column definition of the grid, we

set custom formatters for each editable cell type. Each formatter returns an HTML fragment

which is rendered by the grid for the corresponding cell. These formatters also include the

option values for the combo box elements.

Binding Grid Controls to Hidden Grid Cells

When we render the grid cells, we use custom formatters to render the controls. When the

value of a control changes we need to ensure that the data is preserved in the grid

automatically. For this reason, we maintain hidden cells in the grid to hold the modified

data.

When loading the data for the grid, the addition of each row invokes the afterInsertRow

function, which is used to register the change/keyup/click events of the controls to the

gridControlChanged and gridControlClick functions.

In the gridControlChanged function, we retrieve the modified value, the grid ID, the row ID,

and the field name and then call setMainGridCellValue, which in turn calls setCell to modify

the hidden grid cell value accordingly. When any of the cells are modified, the

setModifiedFlag calls the controller action SetModifiedFlag, which updates the WasChange

parameter of the form state session variable. This flag is used to identify whether to display

a warning when the user is about to navigate to the dashboard before saving the pending

modifications.

Saving the Grid Data

In eForm HTML, the controls are rendered within a <form> section assigned to the

Validation controller action, and the content of the controls are prepared by the browser

automatically in the POST data when pressing the Save/Validate and Submit buttons.


84

However, this is not the case with the grid content because it contains special data

structures that cannot be serialized automatically. As such, we dynamically implement

custom save functions for each grid with the sendalldata_ prefix in the function name. This

function retrieves the data from the hidden cells for each grid row, and the content is

converted to JSON format and sent to the SetGridDataJson controller action, which stores

the modified data in the form state session variable. When saving the form, the grid data is

read from the session variable and included in the structure being sent to ePermitService,

which saves the content to the database.

Grid Paging Support

To support the display of a large number of rows within the grid, we can enable the client

side grid paging. To enable paging, we need to add a <div> section at the bottom of the

grid table for hosting the paging controls.

<body>

...

<table id="grid_id"></table>

<div id="gridpager"></div>

...

</body>

Then set the "pager" parameter to the HTML ID of the paging div when initializing the grid

control:

jQuery("#grid_id").jqGrid({

...

pager : '#gridpager',

...

});

Rendering Subgrids

To implement "grid row details" in eForm HTML, we use the subgrid option provided by the

jqGrid control. To enable the subgrid option in jqGrid, we must set the subGrid parameter

when initializing the grid.


...

subGrid : 'true',


85

...

});

In this case, a plus sign is displayed for each row, which provides the option of expanding

the row to show the subgrid contents. See below:

When expanding the row, the subGridRowExpanded function is called by jqGrid to provide

the HTML identifiers with the subgrid and the row. This provides the option to create the

subgrid contents dynamically (the <table> section and the pager <div>) and to specify the

colmodel according to the following example:


...

subGrid : 'true',

subGridRowExpanded: function (subgrid_id, row_id) {

var dataxsub = jQuery("#grid_id").getRowData(row_id);

var subactcont = [{ }];

var subgrid_col_m = [{ name: 'colfor_63117', index: 'colfor_63117' ,

sortable:false, editable:false, fixed: false, formatter: formatterfor_63117 ,

title: false }];

var subgrid_table_id, pager_id;

subgrid_table_id = subgrid_id + "_subt";

pager_id = subgrid_id + "_subp";

jQuery("#" + subgrid_id).html("<table id='" + subgrid_table_id + "'

class='scroll'></table><div id='" + pager_id + "_subp'

class='scroll'></div>");

jQuery("#" + subgrid_table_id).jqGrid({

hidegrid: false,

data: subactcont,

autowidth: true,

datatype: "local",

colModel: subgrid_col_m,

rowNum: 99999999,

pager: pager_id,

height: '100%',

hidegrid:true


86

}

...

});

The colmodel for the subgrid is specified in the third row of the XAML definition of the main

grid (see Grid Row Details on page 68). The subgrid is initialized in the same way as the

main grid. We use the same formatter approach when specifying the HTML content and

register the change/keyup/click events of the controls to the gridControlChanged and

gridControlClick functions in the afterInsertRow event of the subgrid to provide the data

binding between the controls and the hidden grid cells. The modified data from the hidden

grid cells are sent automatically by calling the sendalldata function of the main grid. For

more information, see Saving the Grid Data (page 83).

Rendering Custom Controls

In form renderer v1, the custom controls have been added to the LayoutCustomControls

project. The custom controls contain a specific XAML layout and a corresponding

implementation that can be used as a design element in the form designer. For more

information about the custom controls in v1, refer to the chapter: Using Custom Controls

(page 33).

In the HTML form renderer, we implement custom controls as specific HTML/javascript code

fragments. In the code fragments, we use the following placeholders, which are filled

dynamically by the form renderer at run time:

1. $$CID$$ - This item is replaced by the form renderer according to the actual control

ID.

2. $$ATTOPTIONS$$ - This item is the placeholder for the combo box option values

retrieved from ePermitService by using the corresponding GetLookupBy... call.

3. $$fieldname$$ - This item is replaced with the actual field name of the custom

control on the parent control.

4. $$text$$ - This item is replaced with the actual description of the custom control.

5. $$value$$ - This item is replaced with the actual value of the custom control.

The preparation of a custom control form element takes place in the corresponding

SetCustom... function of the form renderer, which replaces some of the placeholders with


87

the actual values and stores the name and result HTML in the customcontrolSubType and

customcontrolHTML parameters.

During the rendering phase, all remaining placeholders are replaced with the actual values,

and the resulting HTML of the custom control is added to <div> section of the output HTML.

Adding New Custom Controls

Currently, we use the custom controls already added to the LayoutCustomControl project,

which means that we should implement the Silverlight version first as it is required for the

form designer support of the control.

When the Silverlight version was added, we suggested implementing the HTML version in a

separate class and file starting with the CC_ prefix within the /Utils subdirectory. The class

should be derived from the CC_Base class and implement the GetName, GetContent and

GetInitialValue functions.

Print Preview in eForm HTML

In eForm HTML (v2), we use the same approach to display the print preview as in the earlier

version. The print preview can be invoked from the dashboard and the form edit page by

pressing the Print Preview button. In eForm HTML, we navigate to the WebReportPDF.aspx

page by adding the form number as an URL parameter.

The .pdf reports are located in the /Reports subdirectory of the application. They are .rdlc

reports that can be displayed with the ASP.NET ReportViewer control. For more information

about the eForm reporting solution, see: Adding Reports for Printing Forms (page 39).

To redirect to the correct URL for the print preview option, the ReportPathURLprefix

parameter should be set in the web.config file according to the current location of the Web

application.

Public Method Calls for eFormService

Imports System.ServiceModel

Imports ePermitDAL


88

' NOTE: If you change the class name "IePermit" here, you must also update the

reference to "IePermit" in Web.config.

<ServiceContract(Namespace:="http://RbdmsOnline/ePermit/2008/04")> _

Public Interface IePermit

<OperationContract()> _

Function Version() As String


Function ClearServiceCache(ByVal tokenID As Guid) As WsStatus


Function GetCurrentVersionByFormName(ByVal formName As String) As Decimal


Function SaveLayoutDeepCopy(ByVal TokenID As Guid, ByVal lyOut As Layout,

ByVal newVersion As Decimal) As Layout

'<OperationContract()> _

'Function SaveLayoutAs(ByVal TokenID As Guid, ByVal lyOut As Layout, ByVal

newVersion As Decimal) As Layout


Function GetCurrentVersion(ByVal tokenID As Guid, ByVal formName As

String, ByVal isForRendering As Boolean) As Layout


Function SetCurrentVersion(ByVal tokenID As Guid, ByVal formName As

String, ByVal ver As Decimal) As Boolean


Function GetBindableTypes() As List(Of String)


Function GetNewForm(ByVal tokenID As Guid, ByVal operatorNo As Int32,

ByVal form_num As String) As form


89


Function GetObject(ByVal TokenID As Guid, ByVal dataReq() As

ePermitBLL.DataRequest) As ePermitBLL.DataReturn()


Function SaveObject(ByVal TokenID As Guid, ByVal dataReq() As

ePermitBLL.DataReturn) As WsStatus


Function SaveDataTemplate(ByVal TokenID As Guid, ByVal dataReq() As

ePermitBLL.DataReturn) As WsStatus


Function SetStatus(ByVal tokenid As Guid, ByVal doc_num As Int32, ByVal

status As String) As WsStatus


Function GetForm(ByVal TokenID As Guid, ByVal doc_num As Int32) As form


Function GetFormVersions(ByVal TokenID As Guid) As List(Of

ePermitDAL.FormVersions)


Function GetAllowableStatuses() As Dictionary(Of String, Dictionary(Of

String, Dictionary(Of String, String)))


'Function GetNewForm2(ByVal TokenID As Guid, ByVal doc_num As Int32?) As

ePermitDAL.form2


'Function GetForm2(ByVal TokenID As Guid, ByVal doc_num As Int32) As

ePermitDAL.form2


90


'Function SaveForm2(ByVal TokenID As Guid, ByVal frm As form2) As

ePermitDAL.form2


'Function GetForm2a(ByVal TokenID As Guid, ByVal doc_num As Int32) As

form2a


'Function GetNewCasing(ByVal TokenID As Guid, ByVal doc_num As Int32) As

Casing


'Function GetCasing(ByVal TokenID As Guid, ByVal doc_num As Int32) As

List(Of Casing)


'Function SaveCasing(ByVal TokenID As Guid, ByVal csg As List(Of Casing))

As ePermitDAL.WsStatus


Function GeteFormComment(ByVal TokenID As Guid, ByVal doc_num As Integer)

As System.Collections.Generic.List(Of ePermitDAL.eFormComment)


Function GeteFormAllComments(ByVal TokenID As Guid) As

System.Collections.Generic.List(Of ePermitDAL.eFormComment)


Function GeteFormCommentReview(ByVal TokenID As Guid) As

System.Collections.Generic.List(Of ePermitDAL.eFormComment)


Function SaveeFormComment(ByVal TokenID As Guid, ByVal comments As

System.Collections.Generic.List(Of ePermitDAL.eFormComment)) As WsStatus


91


Function DeleteeFormComment(ByVal TokenID As Guid, ByVal comments As



Function ReviewedeFormComment(ByVal TokenID As Guid, ByVal comments As



Function SaveeFormAttachment(ByVal tokenID As Guid, ByVal doc_num As

Integer, ByVal fileName As String) As WsStatus


Function AppendeFormAttachment(ByVal tokenID As Guid, ByVal doc_num As

Integer, ByVal fileName As String, ByVal aByte As Byte(), ByVal len As Int32)

As WsStatus


'Function DeleteeFormAttachment(ByVal tokenID As Guid, ByVal attachDoc_num

As Integer) As WsStatus


Function GetFormAttachmentUrlPath(ByVal tokenID As Guid, ByVal doc_num As

Integer, ByVal fileName As String) As String

'Layout editor methods

'Gets all Layouts records


Function GetControls(ByVal TokenID As Guid) As List(Of ePermitDAL.Control)


Function GetRight(ByVal TokenID As Guid, ByVal RightID As Int32) As

ePermitDAL.wsStatus


92

'Gets the LayoutControls record plus related Controls and LayoutControls


Function GetLayoutByKey(ByVal TokenID As Guid, ByVal Key As Int32, ByVal

version As Decimal) As ePermitDAL.Layout

'Gets the LayoutControls record plus related Controls and LayoutControls


Function GetLayout(ByVal TokenID As Guid, ByVal Name As String, ByVal

version As Decimal) As ePermitDAL.Layout

'Gets a deep copy of Controls and LayoutControls


Function GetLayoutForRendering(ByVal TokenID As Guid, ByVal name As

String, ByVal version As Decimal) As ePermitDAL.Layout


Function SaveLayout(ByVal TokenID As Guid, ByVal lyt As ePermitDAL.Layout)

As ePermitDAL.Layout


Function DeleteLayout(ByVal TokenID As Guid, ByVal lyt As

ePermitDAL.Layout) As ePermitDAL.WsStatus


Function GetLookupNames() As String()


Function GetLookupByNameInt(ByVal lookupName As String) As List(Of

ePermitDAL.LookupCodeInt)


Function GetLookupByNameString(ByVal lookupName As String) As List(Of

ePermitDAL.LookupCodeString)



93

Function GetLookupByNameStringParam(ByVal lookupName As String, ByVal

value As Object) As List(Of ePermitDAL.LookupCodeString)


Function GetLookupByNameIntParam(ByVal lookupName As String, ByVal value

As Object) As List(Of ePermitDAL.LookupCodeInt)


Function GetLookupByNameGuid(ByVal lookupName As String) As List(Of

ePermitDAL.LookupCodeGuid)


Function GetAttachType(ByVal strFormNum As String) As List(Of String)


Function IsValidRuleSet(ByVal strRuleNetName As String) As Boolean


Function ValidateRules(ByVal TokenID As Guid, ByVal dr As

ePermitBLL.DataReturn) As ePermitBLL.DataReturn


Function ValidateRule(ByVal TokenID As Guid, ByVal dr As

ePermitBLL.DataReturn, ByVal ruleName As String) As ePermitDAL.BaseBusiness

#Region "State Specific"


Function GetAutocompleteValues(ByVal tokenID As Guid, autocompleteID As

String, filter As String) As List(Of LookupCodeString)


'Function UpdateeFormAttachment(ByVal tokenID As Guid, ByVal fAttach As

ePermitDAL.eFormAttach) As WsStatus



94

Function GetForm_Attach(ByVal TokenID As Guid, ByVal doc_num As Integer)

As List(Of ePermitDAL.eFormAttach)


Function SaveForm_Attach(ByVal tokenID As Guid, ByVal frmAttach As List(Of

ePermitDAL.eFormAttach)) As WsStatus

''add as ServiceKnownType as needed ie form2a, casing, etc

'<OperationContract() _

' , ServiceKnownType(GetType(Form2)) _

' , ServiceKnownType(GetType(eFormTask)) _

' , ServiceKnownType(GetType(Form))> _

'Function ValidateRules(ByVal TokenID As Guid, ByVal frm As

ePermitDAL.BaseBusiness, ByVal ruleSetName As String) As

ePermitDAL.BaseBusiness

''add as ServiceKnownType as needed ie form2a, casing, etc

'<OperationContract() _

' , ServiceKnownType(GetType(Form2)) _

' , ServiceKnownType(GetType(eFormTask)) _

' , ServiceKnownType(GetType(Form)) > _

'Function ValidateRule(ByVal TokenID As Guid, ByVal frm As

ePermitDAL.BaseBusiness, ByVal ruleSetName As String, ByVal ruleName As

String) As ePermitDAL.BaseBusiness

#End Region

#Region "Security related functions for reading and maintaining security and

user settings"


Function Login(ByVal LoginName As String, ByVal Password As String, ByVal

OperatorNo As Int32) As ePermitBLL.LoginInfo


Function GetLoginName(ByVal TokenID As Guid) As String



95

Function CreateUser(ByVal TokenID As System.Guid, ByVal UserName As

String, ByVal Password As String,

ByVal eMail As String, ByVal PasswordQuestion As

String, ByVal PasswordAnswer As String,

ByVal IsApproved As Boolean, ByVal OperatorNumber As

Integer) As WsStatus


Function DeleteUser(ByVal TokenID As Guid, ByVal UserName As String) As

WsStatus


Function ResetUserPasssword(ByVal TokenID As Guid, ByVal UserName As

String, ByVal Password As String) As WsStatus


Function SetUserStatus(ByVal TokenID As Guid, ByVal UserName As String,

ByVal isInactive As Boolean) As WsStatus


Function GetUserNames(ByVal TokenID As Guid) As List(Of String)


Function GetUserCompanies(ByVal TokenID As Guid, ByVal UserName As String)

As List(Of Int32)


Function AddAgent(ByVal TokenID As Guid, ByVal CompanyID As Int32, ByVal

username As String) As WsStatus


Function RemoveAgent(ByVal TokenID As Guid, ByVal CompanyID As Int32,

ByVal userName As String) As WsStatus



96

Function GetAgents(ByVal TokenID As Guid, ByVal CompanyID As Int32) As

List(Of String)


Function GetMembersForOperator(ByVal TokenID As Guid, ByVal CompanyID As

Int32) As List(Of ePermitDAL.Users)


Function GetMemberExists(ByVal TokenID As Guid, ByVal UserName As String)

As Boolean


Function SaveMembers(ByVal TokenID As Guid, ByVal members As List(Of

ePermitDAL.Users), ByVal OperatorNumber As Integer) As WsStatus


Function ValidateCaptcha(ByVal TokenID As System.Guid, ByVal CaptchaText

As String) As Boolean


Function GetUserSettings(ByVal TokenID As System.Guid) As Dictionary(Of

String, ePermitDAL.UserSetting) ' List(Of ePermitDAL.UserSetting)


Function GetUserSetting(ByVal TokenID As System.Guid, ByVal settingKey As

String) As ePermitDAL.UserSetting


Function SaveUserSettings(ByVal TokenID As System.Guid, ByVal lstSettings

As Dictionary(Of String, ePermitDAL.UserSetting)) As WsStatus

#End Region

#Region "Rule specific functions. VB.net does not allow Partial interfaces so

putting code in #region"


97


Function GetRuleSets(ByVal TokenID As Guid) As List(Of String)

<OperationContract(Name:="GetRuleSetsByTypeName")> _

Function GetRuleSets(ByVal TokenID As Guid, ByVal entityTypeName As String)

As List(Of String)

<OperationContract(Name:="GetRuleSetsByVersion")> _

Function GetRuleSets(ByVal TokenID As Guid, ByVal majorVersion As Integer,

ByVal minorVersion As Integer) As List(Of String)

<OperationContract(Name:="GetRuleSetsByTypeNameAndVersion")> _

Function GetRuleSets(ByVal TokenID As Guid, ByVal entityTypeName As String,

ByVal majorVersion As Integer, ByVal minorVersion As Integer) As List(Of

String)

<OperationContract(Name:="GetRuleSetsEx")> _

Function GetRuleSetsEx(ByVal TokenID As Guid) As List(Of

Gwpc.Rules.Engine.RuleSetDto)


Function GetRules(ByVal TokenID As Guid, ByVal resultSetName As String) As

List(Of String)

#End Region

#Region "Dashboard"


Function GetForms(ByVal TokenID As Guid, ByVal doc_num As Int32, ByVal

status As String, ByVal opNum As Int32?, ByVal formNum As String, _

ByVal companyName As String, ByVal fromDate As

DateTime?, ByVal toDate As DateTime?, ByVal taskName As String, ByVal size As

Int32) As ePermitDAL.vweFormDashboard()


98


Function GetFormsEx(ByVal TokenID As Guid, ByVal crit As List(Of

ePermitDAL.WhereCriteria)) As ePermitDAL.vweFormDashboard()


Function Upload(ByVal TokenID As Guid, ByVal mode As String, ByVal path As

String, ByVal name As String, ByVal filedata As String, ByVal overwrite As

Boolean) As String

#End Region

#Region "Review Tasks"


Function GeteFormTask(ByVal TokenID As Guid, ByVal frmKey As Int32, ByVal

tskName As String) As eFormTask


Function GeteFormTasks(ByVal TokenID As Guid, ByVal frmKey As Int32) As

List(Of eFormTask)


Function SaveeFormTask(ByVal TokenID As Guid, ByVal frmTask As eFormTask)

As WsStatus


'Function SeteFormTaskStatus(ByVal TokenID As Guid, ByVal FormKey As

Int32, ByVal taskname As String, ByVal status As String) As WsStatus

#End Region

#Region "Final Approval"


Function GetUnApprovalForms(ByVal tokenID As Guid, ByVal doc_num As

Integer, ByVal form_num As String) As ePermitDAL.form()

#End Region


99

#Region "PaymentInfo"


Function GetPaymentInfo(ByVal TokenID As Guid, FormKey As Integer) As

PaymentInfo


Function SavePaymentInfo(ByVal TokenID As Guid, Payment As PaymentInfo) As

Boolean

#End Region

End Interface