About Webtoolz

WebToolz (previously called FormToolz) makes it quick and easy to add dynamic user-interactive components to iMIS pages. Being an iPart, it works well in conjunction with all other iParts (e.g Content Collection Organiser). It combines drag and drop user-interface design with the ability to process complex business logic in SQL stored procedures.

Important Terms and Definitions

To fully understand the WebToolz iPart, it is helpful to be familiar with some core terms and definitions.


These are a list of components or tools you may use to build your web pages.  Controls are broken into three categories:
  • basic form controls  - these are controls typically found in form builders such as: text boxes, dropdown boxes, combo boxes, and radio buttons. These types of controls can be executable controls which do something, like fire a stored procedure, or what we call smart HTML controls, which are the normal form builder type of controls with some additional data-driven elements (like show or hide business logic), Pre-process (executed before the page loads). 
  • extension controls - allow you to change a password, assign a password, download or upload a file, or perhaps send an email. These are typically termed post-execution controls because they do something special after the execution of the form you are on.Other extension controls include integrations to other pieces of software (e.g Adobe Connect or Canvas LMS), or tools to facilitate integrations (Like single sign on and API wrappers). Some of these extensions controls are charged for separately (indicated by the PLUS icon after their name.
  • Analytic controls -  these controls enable web analytics by allowing you to capture a user’s browser type, browser platform, IP address and the URL they are accessing.
  • Parameters

There are three different types of parameters used with the WebToolZ iPart.  Whether a parameter is seen as an inbound parameter or an outbound parameter is always based from the vantage point of how the parameter works with the object of your focus.  For example, when considering one of your own SQL procedures, the inbound parameters are ones you send to your procedure and the outbound parameters are the ones you send from your procedure.  When considering the WebToolz iPart, the inbound parameters are ones coming from, say, a URL into the iPart or from your custom SQL procedure into the iPart and it has no outbound parameters.  In the case of the iPart, it so happens that the outbound parameters of your procedure are the inbound parameters for the iPart.  This explained, there are three types of parameters: URL, inbound and outbound. 

Inbound Parameters

Inbound parameters are ones captured by a form or page and then sent to your custom SQL procedure where sone business logic is applied and the parameters are written to iMIS.

Outbound Parameters

Outbound or return parameters are ones sent out of your custom SQL procedure, and may appear on a web page, alter a web page or create an action (like a redirect, file download, or sending an email.

URL Parameters

URL parameters are ones located in the URL of the webpage being visited.  In this examplehttp://www.zengage.co/index.asp?Page=Example the URL parameter immediately follows the question mark and ends just before the equal sign—here, the word “Page” is the URL parameter.  It is also possible to have parameters after the question mark and these are delimited by use of the ampersand (&) and the equal sign. In this example http://www.zengage.co/index.asp?Page=Example&paragraph=3&sentence=5 the word “paragraph” is the second parameter and the word “sentence” is the third parameter.  Each of these is assigned the value immediately after the equal sign, making the value of Page = “Example”, the value of paragraph = “3” and the value of sentence = “5” as noted in the example above.
  • These URL parameters may be used as incoming parameters in the iPart and assigned as pre-populated values that display when the control is rendered to screen. 
  • These URL parameters should be entered without a leading @ sign, which makes their use different than the incoming parameters from your SQL procedure which require the use of the @ so that the iPart may recognize the difference between the two.

Foundational Principals

The Zengage WebToolz iPart operates under the following foundational principals:

  1. Each time the iPart is used to interact with the iMIS database, it must be associated with an SQL stored procedure—the iPart only acts upon data it is offered from outbound parameter values returned from your SQL procedure.  As an example of this, consider the ResetPassword control of WebToolz explained in much greater detail later in this manual.  WebToolz can create a username and password for an existing contact when you return the iMIS ID, a username and password to WebToolz via the outbound parameters of your custom procedure.  The workflow to produce this expected result is as follows: drop an instance of the WebToolz iPart on a content page; choose the ResetPassword operation; create a procedure that returns the ID, username and password, associate your procedure to the iPart; build the form; and run the form.
  2. All internal iMIS business rules must be respected when operating the iPart against the iMIS system.  An example of this when using the ResetPassword operation is that the username may not already be in use; the password must meet password restrictive rules established in iMIS; the contact must already be made or must be made in your custom procedure prior to returning the outbound parameters to the iPart; and an email address must already be assigned to the contact record.
  3. iMIS macro variables such as @CurrentUser, @Me, @Now may not be used as incoming parameters or outgoing parameters as these are filled in by the iMIS subsystem and this iPart is external to that.  Further, the @ sign is reserved for use in defining incoming parameters from SQL procedures, which means that all URL parameters are used in the iPart without the leading @ sign.