How does Formspider work?

The PL/SQL Irony
PL/SQL has never run on client machines and never will. This unchangeable, indisputable fact that seems like the most obvious disadvantage of PL/SQL is in an ironic way its biggest advantage. This very fact is the reason Oracle Forms was a platform independent application development framework. Software engineers at Oracle had to move heaven and earth to get your code run on Windows and in the browser.

Since the target platform of the application was never obvious to the people behind Forms, it was never a desktop application framework or a Web application framework. Its working principles and application architecture could not be based on a specific kind of platform. During the 90’s PL/SQL developers were building applications while everybody was building desktop applications. In the first years of the 21st Century PL/SQL developers continued to build applications while everybody was building web applications.

This principle must be protected stubbornly if we want to have a sustainable framework.

The Big Picture
To achieve this, Formspider is split into two parts, server and client. (In reality the server itself consists of two parts; the middle tier and the database. However, the middle tier does not play a huge role in the way Formspider works. Therefore, I will ignore it for the purpose of this article.) At the server side, the core framework code, the sessions, the application data, transactions management capabilities etc… reside. This is also the place that the custom code written by the PL/SQL developer lives. At the client side, there is a code library that is called the Renderer, which draws the screens, applies the UI changes received from the server and listens to the user’s interaction with the application UI.

The implementation of the Renderer changes depending on the client platform the application needs to be executed. The picture below shows how this set up works if the application is to be delivered as a web application that runs in a browser.

Formspider In Action
The working principles of the Formspider are best explained with an example: When a user starts an application based on Formspider the very first time, the Renderer (a JavaScript library for Web applications) is loaded to the browser along with the first screen of the application. The server also keeps a logical copy of the screen for itself. The Renderer is cached prior to the subsequent calls, so it is only loaded once from the server. Its first task is to draw the first screen of the application to the browser and wait for user input.

Now it is the user’s turn. The user may interact with the application in many ways. She may resize windows, scroll up or down, and edit values in text fields. The Formspider Renderer takes no action if none of these have a corresponding PL/SQL procedure associated with it. It informs the server (database) only if the user does something that requires processing in the server. For example, pressing a button is one of the most common ways to initiate a process in a web application. In this case, the Renderer sends all the changes the user has done in the application since the last time it communicated with the server ((let’s call this the delta) ) and the event the user triggered that requires a PL/SQL procedure to execute. The communication between the browser and the server is an AJAX call.

When the server side of the framework (The Formspider Engine) receives the information from the Renderer, it first applies the delta to the logical copy of the application it keeps. This step is necessary so that the custom code written by the developer has complete access to the current state of the application as seen by the user.

As the next step, the Engine executes the PL/SQL procedure associated with the event the user triggered. In this procedure the PL/SQL developer interacts with her application’s UI and data elements through a set of Formspider API’s which are just PL/SQL procedures themselves.

For example, after evaluating a user’s interaction with her application (say the user pressed a button) she may want to hide a text field. To achieve this, she calls:


In order for these calls to the API’s to actually do what they are supposed to, Formspider Engine records the changes the developer makes to the application using the API’s and sends this information to the client browser to achieve the desired effect on the screen. For example, to hide a text field the server sends the following XML to the client browser:

<set_visible type=”text_field” name=”myTextField” value=”false”/>

At the client side, the Formspider Renderer receives the information in XML format and executes the actions described by it. In the particular example discussed here, it does actually perform the necessary DOM operations to hide the text field named mytextField.

After executing every action described in the XML, the Renderer goes into the listening mode again and the cycle continues.

Meet ECA
This communication model provides a simple and intuitive Event Condition Action (ECA) architecture to the PL/SQL developer in which she can build her application. The complexities of the Web are all hidden behind the communication model and handled by Formspider.

Wikipedia explains ECA architecture in the following way:

“Event Condition Action (ECA) is a short-cut for referring to the structure of active rules in event driven architecture and active database systems.
Such a rule traditionally consisted of three parts:

  • The event part specifies the signal that triggers the invocation of the rule
  • The condition part is a logical test that, if satisfied or evaluates to true, causes the action to be carried out
  • The action part consists of updates or invocations on the local data

In Formspider, the event corresponds to an interaction of the user with the application.

The action is the PL/SQL code that modifies the data and the user interface based on the input received from the user.

The condition is divided into two parts in the framework. The first part is the conditional logic developers place into the PL/SQL code. The second part is handled by the framework. The framework filters user’s interactions with the application at the client side and only delegates the events that require some processing to the server.

The ECA architecture enables PL/SQL developers to develop applications not Web applications. Be it on an iPhone, iPad, laptop or a desktop computer, users interact with applications, and expect them to respond to their inputs. The principles of ECA hold true regardless of the platform the application is running.

ECA is ridiculously simple compared to other framework architectures. Below is the life cycle of a web application in the JSF framework.

The following represents the internal flow of a Struts application:

Web developers spend significant amount of time studying these flows that drive the inner workings of the framework they are using. They keep these diagrams in their minds and write every single line of code to the appropriate place in the flow. These frameworks are also built to generate web pages and therefore completely fail to deliver in platforms other than the browser.

However, Formspider has a simple flow that feels natural. There is hardly anything to learn or keep in mind.

The ECA architecture solves many of the challenges developers face in developing modern applications in Web 2.0 and mobile technologies.

The principles we built Formspider on are certainly not exclusive to PL/SQL. A framework based on ECA principles can be implemented in any programing language such as Java and Javascript. Moreover, these different frameworks can share the same renderers, multiplying the benefits for developers from different schools.

PL/SQL has a particular advantage because it is designed to process data, is closest programming language to data and the furthest away from the client platforms. Unlike other programming languages it must adhere to ECA principles without any chance of breaking its laws. Its worst limitation is its most powerful stronghold.

You can see Formspider in action, by trying our IDE online. The IDE itself is entirely built with Formspider.

Yalim K. Gerger

  • Gary Myers

    “PL/SQL has never run on client machines and never will.”
    Not true. Forms 4 through to 6 were PC-based client software which ran PL/SQL locally. I was working at a place a few months back which is still running a large Forms application as client/server (not web app).
    I do accept those products are no longer supported by Oracle and I don’t expect things to move in that direction in future.

  • Yalim K. Gerger

    Hi Gary,

    Thanks for your input. I guess what I meant was that Oracle had to write a piece of software themselves to make it all work. No OS natively ran PL/SQL.