Yalim K. Gerger

Share/Bookmark

With the demise of Oracle Forms as a credible development environment, PL/SQL developers are deprived of their ability to build modern applications that meet the current needs of their organizations. Unfortunately, the available alternatives are hard to learn, less productive, less capable, and require far more hardware than Oracle Forms. None of them empower PL/SQL developers the way Oracle Forms did. All of the available solutions presented as alternatives to Oracle Forms suffered from one or more of the following shortcomings:

1. Different programming languages for different layers of development
2. Different notations for user interface design for different platforms
3. No true cross-browser compatibility
4. Platform-dependent applications
5. Unproductive, low quality, development environment
6. Poor user experience
7. Huge effort/cost to achieve acceptable performance
8. Difficult to make applications secure

Building world class applications to meet the current needs of businesses requires a flexible and robust framework that makes the technology transparent to developers. The framework should largely get out of the developer’s way and make it a straightforward exercise to implement business requirements. In order to achieve this goal, an application development framework should do the following:

• Utilize a single programming language across all development areas
• Use a single notation for user interface (UI) design across platforms
• Provide true cross-browser compatibility
• Enable building platform-independent applications
• Improve productivity with a high quality IDE
• Support applications that provide an excellent user experience
• Support developers in producing scalable applications with good performance
• Support developers in building secure applications

Formspider includes all of these features, thus enabling PL/SQL developers to build world-class applications now and in the future.

Architecture of a Formspider Application

The Formspider runtime engine enables PL/SQL developers to build applications around the simple Event-Condition-Action (ECA) Architecture.

Wikipedia explains ECA architecture as follows:

“Event Condition Action (ECA) is a shortcut 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 the interaction of a 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 any conditional logic that the developer places in the action.

To achieve this, the Formspider engine is split into two parts:

1. Server-side engine: The server-side engine receives notification of user activity, determines how the screen should be changed on the user machine, and transmits that information to the user’s device. The engine handles everything except updating the user’s screen. The server-side includes the core framework code, sessions, application data, transactions management, capabilities, etc. This is also the place where the custom code written by the PL/SQL developer resides.
2. Client-side renderer: The client-side renderer transmits user activity to the engine and responds to engine requests to update the screen. The renderer is composed of a code library used to draw the screens, apply the UI changes received from the server, and listen to the user interaction with the application UI which it then transmits to the engine. The client-side renderer changes depending upon the client platform on which the application needs to be executed. For web applications, the renderer could be a JavaScript library. A custom Java library would be used if the choice were to run on a PC without a browser. To run on a tablet or smart phone, the renderer would have to be written in a language supported by the device.

The ECA framework completely isolates the developer from the deployment platform. As long as renderers exist for the different platforms, a developer can code in Formspider and deploy to any supported platform with absolutely no changes needed to the code.

Figure 1 shows how this architecture works in a standard web environment.

Figure 1: Formspider ECA implementation

• The process starts with a user request (1), which includes any changed data since the last request plus a notification of what event took place that triggered the request.
• The application server simply passes the request to the engine that resides in the database (2).
• The engine in the database processes the request and determines what UI changes need to be made to the user’s screen (3).
• The engine passes that request as an XML file to the application server (4) which then passes it to the client (5)
• The client renderer processes the XML and makes the appropriate changes to the UI (6).

This communication model provides a simple and intuitive Event Condition Action (ECA) architecture with which PL/SQL developers can build applications. The web complexities are hidden behind the communication model and handled by the framework.

Note the following advantages:

1. There is never more than a single round trip from the client to the application server or from the application server to the database. The communication between any of the two layers is optimized by the design.
2. All interaction between the code and the data occurs in the database, making it very fast.
3. The application server is doing very little work, and thus has a very small load.
4. Only the changes to the screen since the last user request are transmitted from the client and only the changes to the screen are transmitted back, so the amount of network traffic between the client and the application server is very small.

The ECA architecture enables PL/SQL developers to develop applications for any platform including iPhones, iPads, laptops, or desktop computers.

Benefits of the Formspider Framework

The Formspider framework provides a number of important advantages.

1. Simple Development Environment

Creating an application should not be any more complex or expensive than it used to be using client-server technology.

With a simple development environment, developers can focus on solving business rather than technical problems.

The world used to be a simpler place. In Oracle Forms, one developer with knowledge of PL/SQL and Forms could build a working application. Now systems require teams of developers using many products that all have to work together perfectly. “Successful” projects cost ten times what they did a decade ago.

The job of the application developer should be to define the application, and not to worry about how it is implemented. There is no reason why the experience of building an application to run on a handheld device should be vastly different from building one to run in a browser.

The Formspider ECA architecture is much easier to understand and work with than most other framework architectures such as JSF and Struts. Figure 2 shows the life cycle of a web application in the JSF framework.

Figure 2: JavaServer Faces framework web application life cycle

Figure 3 represents the flow of a Struts application.

Figure 3: Struts application process flow

Web developers can spend a significant amount of time studying the mechanisms shown in Figures 2 and 3 that drive the inner workings of those frameworks. They must keep these diagrams in mind and ensure that every line of code is written to the appropriate place in the flow. These frameworks are also designed to only generate web pages and therefore completely fail to deliver in platforms other than the browser.

Formspider has a simple flow that is much more intuitive. There is hardly anything to learn or keep in mind during development. The development experience in Formspider is very much like that of Oracle Forms.

Figure 4: Formspider application process flow

2. Single Programming Language

Formspider uses only PL/SQL as its scripting language.

As long as data is stored in the database, code written in the database will have a huge advantage over code written in the middle tier. In the Oracle environment, developers know PL/SQL. Therefore PL/SQL is the natural language of choice for application development.

One of the biggest handicaps of currently available frameworks is that they require extensive knowledge of several programming languages. For most JavaEE frameworks, a developer needs in-depth knowledge of Java, JavaScript and a variety of component technologies. With so much to learn, it is understandable that most Java developers resist becoming skilled database developers as well.

Becoming an expert in a single programming language takes years. Asking enterprise application developers to become experts in two or more languages is counterproductive. An enterprise application developer must understand business rules and implement them in code. A programming language is the means by which this task is accomplished. Once a developer is expert at expressing the business rules in one programming language, learning any additional languages is time consuming and may not ultimately help them become better developers. If you ask an experienced PL/SQL developer to program in Java (or the other way around), they will struggle with the nuances of the new language for years. The result of this struggle is sub-par performance, bugs, and low-quality applications.

The PL/SQL scripting used in Formspider will look familiar to Oracle Forms developers. The ability to manipulate components is similar to what Forms developers have been using for years. Because the scripting is in PL/SQL and stored in the database, developers can use any PL/SQL editor to write programs.

The following code shows the script used to create a login screen button like that shown in Figure 5 work:

Figure 5: Sample login screen

procedure doLogin is
v_loginResult_tx varchar2(10);
begin
--- this is the call to the developer’s login package
v_loginResult_tx:=myapplication.doLogin(
--- this retrieves the value from the “User name”
api_component.getvaluetx('loginPanel.user'),
--- this retrieves the value from the “Password”
api_component.getvaluetx('loginPanel.password')
);
if v_loginResult_tx=’OK’ then
api_dialog.setvisible('loginWindow','N'); -- this hides the window
else
--login failed. warn user.
end if;
end;

The actual procedure would be more complex but this example shows how application behavior can be coded. It is as simple and intuitive as in Oracle Forms.

3. Single Development Environment for all Platforms

Excluding accommodations for differing capabilities, defining the application should not be dependent upon the deployment platform.

The technology to develop the same UI changes from platform to platform. Web, mobile and desktop technologies vastly differ in the way in which they define user interfaces. If a screen is developed in Java Swing, there is no way to render the same screen in a browser. It would be easier to rewrite the screen as a JSF, JSP, or ASP page. This is extremely unproductive because when a new platform emerges for deploying applications (such as mobile native applications), the UI development experience in the old tech stack is useless. Developers must go back to square one.

With Formspider, developers can learn it once, and develop screens for any platform. Each platform may have its own special components, constraints, layouts, etc. However, the way to build the screens, create events on them, and associate programs with these events can and should be similar. A button is a button, and a button press is a button press, whether it occurs on a tablet or a PC. There is no need for multiple ways to define this element.

Virtually every existing framework locks organizations into a platform by choosing a client-side programming language: web, desktop, or mobile. Developing in one environment without needing to know its details is just as valuable as true browser compatibility because, in the end, each browser is just another platform.

Many people believed that the web eliminated the need for deploying native applications. This perception was completely overturned by the emergence of mobile operating systems. As of today, PL/SQL developers have no way of building applications for the mobile world.

Formspider provides a way to deploy native applications to platforms including mobile operating systems. The client-side library of the framework can be Java, ObjectiveC, or anything else that happens to come along. This flexibility enables organizations to deploy to different platforms using the developers’ existing PL/SQL skill set. The platform is just another target to deploy to. Each platform may have its own set of layouts or even components. For example, the constraints and requirements of a mobile application are very different from those of a web application rendered on a 27-inch monitor connected to a quad core machine with 32GB of memory. However, the notation to develop the UI and the language to script the program flow stays the same. Developers continue to be productive in an environment that is familiar to them. They can use the same APIs, IDE, debugging tools etc..

Another side effect of the current development method is that separate developers work to deliver applications to different platforms which essentially fulfill the same business needs. It becomes very difficult to synchronize these applications in behavior, look-and-feel and features made available to users. The ECA architecture makes it possible for the same PL/SQL development team to control applications running on different platforms, thus providing consistency.

4. True Cross-Browser Compatibility

With Formspider, browser compatibility is our problem, not yours.

There are many different browsers available, and each has its own way of interpreting HTML, JavaScript and CSS.

With the first line of JavaScript, HTML and CSS you write, you are in browser compatibility hell. It is absurd to expect an enterprise developer to be an expert in this field as well, in addition to having expertise in industry business rules, screen design, and multiple programming languages.

Today, browser compatibility is a task for the development teams. Most teams just give up. In environments where rigid control can be exercised, users are banned from upgrading their browsers. So much for platform independence; we end up building web applications that are browser-dependent.

Some teams seek refuge in JavaScript libraries that are compatible with the major browsers. This makes sense. The only problem is that a developer must write JavaScript to use these libraries. However, this custom JavaScript code must also be tested in every relevant brand and browser version.

Some have faint hopes that this problem will go away eventually. In reality, it only gets worse. For example, the latest version of Microsoft Internet Explorer (IE9) does not work in Windows XP and leaves millions of users behind. IE9 does not consolidate the fragmentation among IE users. Instead, it makes the fragmentation worse.

The ECA paradigm separates the client library from the server. This separation results in specialization. While enterprise developers concentrate on turning business rules into code, the framework’s JavaScript developers focus on the JavaScript library. They spend all of their time and energy on JavaScript. Their only goal is providing the best library to the enterprise developers. They know nothing of the business rules of any industry or ways of writing an efficient query. When there is a compatibility issue with a component in a browser, they fix it. When they fix it, the problem is solved for all the applications out there that use Formspider. Nobody reinvents the wheel; nobody wastes time on forums; OTN, or Stackoverflow. Nobody tries to get creative and come up with kludges. The JavaScript experts solve the problem once and for all for everybody since everyone can download the updated JavaScript library.

Since every PL/SQL developer using Formspider writes only PL/SQL and communicates with the client using the framework’s PL/SQL APIs, the framework’s JavaScript library is the only JavaScript that executes in any of the applications built with the framework. Therefore, every application benefits from any improvement in the library.

5. Productive Development Environment

It should not take any longer to build an application than it used to.

Back in the old Oracle Forms days, a developer could build a moderately complex screen in about a day. That same screen takes a week to build in a JavaEE framework and the probability of that application actually working when you get to production is much lower than the old Forms application.

The Formspider IDE was written using Formspider. The IDE was the first application developed. From the very start, we were not just the developers, but also the customers. As a result, much effort has gone into making the IDE intuitive and productive.

We built the best, the most user-friendly XML Editor for the Formspider IDE. It helps you build your screens by completing your code automatically, formatting it beautifully, and giving meaningful error messages.

Because the main layout editor is written in XML, the entire IDE only comprises about 100 screens (~20 of which you use 80% of the time). Compare that with Oracle’s Application Express (APEX) that includes over 2000 screens in the IDE.

Objects that have been logically associated (such as panels on windows) can be found as child objects in the navigation tree, so there is no need for a text search for impact analysis when you delete something.

Testing your application requires a single button press. There is no deploying or waiting for the application to compile. It runs exactly as if it were in the production environment.

Formspider includes an excellent debugger. It will even show the component you are looking at which makes finding where a change needs to happen very easy.

6. Excellent User Experience

Applications must be beautiful by design.

It is not enough anymore to build applications the way we used to in client/server days. Users want a rich UI experience with beautiful screens.

Formspider has all of the components needed to build a great looking Web 2.0 framework. Every Formspider application works as a single page web application by design, using AJAX 100% of the time to communicate with the server. Formspider applications never do full page refreshes which are reminiscent of early web days. In fact, if you open your browser full screen, it is hard to tell that you are looking at a web application.

The look-and-feel of Formspider applications is infinitely customizable with CSS. Formspider has different layout capabilities that enable you to take advantage of every pixel on the screen any way you want.

You will delight your users with the applications you can build with Formspider and turn every Java and JavaScript developer green with envy.

7. Great Performance without Great Effort

A reasonable developer should not have any trouble building an application with excellent performance.

Back in the Oracle Forms days, the only way you could make an application perform poorly was to do something that an experienced developer could easily avoid or fix when discovered, such as write a bad query. In JavaEE environments, you must be an expert in every one of the component technologies, or applications that appear to work well in development will fail in test or production.

Large enterprise applications built with Web 2.0 technologies such as AJAX and JavaScript libraries, often create too many objects in the DOM and load too much code for the browser to perform adequately. This problem is usually detected very late in the development process and may have its roots deep in the architecture, with the result that correcting the problem in time may be an impossible task.

Development teams are expected to adhere to a certain set of rules and manage the load they are putting on the browser. This is a new problem in Web 2.0 development that did not exist in the early days, when the application was divided into many pages. Users called pages from the server as needed. Even if the actual application consisted of thousands of pages, the user accessed them one at a time. With the emergence of AJAX and JavaScript libraries, an entire application can be loaded to the browser all at once. However, this doesn’t mean that it should be. The architects are faced with the problem of web pages taking too long to load. For example, an entire finance system might need to be loaded to the user’s screen even though the only operation needed was looking up an account code.

The solution to this problem is obviously to load the necessary code and screens only when they are needed. However, there is no mechanism to do this automatically. Development teams are forced to choose between two evils. They either have to manage the deployment of the code to the browser manually, or just forward the user to a new web page. The first option causes a lot of “plumbing” for the developer to manage. Naturally, this process is very error prone. The second option sacrifices the user experience. It also divides the application into arbitrary page groups. Probably, the worst effect of the second option is that it involves server-side coding which means adding another programming language and framework to the complexity of the application.

Formspider applications run in the database and load only a small (300KB) JavaScript library to the client that has been extensively tuned. Each Formspider application uses the same library. The screens of the application are loaded to the browser only when they are accessed by the user and they are cached for the duration of his session. This provides an environment that “by design” is going to run quickly end efficiently. You have to work hard to make a Formspider application perform poorly. Any performance problems can easily be discovered by an experienced PL/SQL developer.

8. Scalability

Less hardware should required than used with client-server technology.

Scalable should not mean “you can buy a bigger database or application server to improve performance”. Scalable should mean that you do not need to buy more hardware to get good performance. In the Oracle Forms days, the main resource issue was that each user had his/her own database session. Since we are building stateless applications that use session pooling, hardware requirements should have decreased. Instead, most frameworks are so inefficient in their use of resources that hardware requirements are much greater than they were in the past.

Formspider applications scale with your Oracle Database. The entire server-side code of the Formspider framework is written in PL/SQL, so it is incredibly fast. It takes advantage of the speed of the Oracle Database in managing data. If your database is fast now, your applications will become faster with Formspider.

Formspider will also reduce your hardware costs because it puts very little weight on the middle tier. This has two benefits:

1. It requires less processing power, memory, and storage capacity in the middle tier hardware.
2. No sophisticated application server software is needed. Formspider can run on free Apache Tomcat or any JEE compliant application server. Even if you must run licensed software in your middle tier for various other reasons, Formspider will reduce your licensing costs because it will require less processors, memory and storage.

9. Security

Formspider has significant security capability inherent in the framework.

JavaScript is not secure. Anybody can open up a JavaScript debugger like Firebug and start changing the code. They can enable/disable fields, or change the content in hidden fields. One solution is to obfuscate the JavaScript. This only makes life harder for people with bad intentions. When JavaScript executes to hide or disable a field, the server is unaware of the change unless it is notified. This notification must come from a JavaScript execution which is not secure. Hence the notification cannot be relied upon because it can be blocked by a hacker.

Existing frameworks attempt to solve this problem in the server by creating security resources, assigning them to UI objects, and then giving these resources to different users and user groups. This is all well and good. However, enterprise developers are often expected to be security experts by assigning each secure component to a security resource and worrying about security at every step. Most frameworks are unaware of what is being sent to the client. There is no notification if a button on the screen is enabled or disabled or if a certain field is hidden.

The Formspider architecture stores a logical copy of every screen for every user. Every UI modification sent from the server is also stored in the Formspider engine. Therefore, it is very easy to validate every input received from the client to see if this event is valid for this user. The server rejects the event if it is not valid in a particular context. For example, if the developer disables a field using a PL/SQL API and a hacker attempts to set its value, the server will automatically reject this input. No additional effort is required from the developer. This feature does not eliminate the need for the implementation of user privileges and security precautions, but it adds a significant layer of protection without any effort by the developer.

Conclusions

Formspider enables PL/SQL developers build modern applications for Web 2.0 and mobile devices much more easily and inexpensively with their existing skill set.

Using Formspider, one PL/SQL team can deliver applications for different platforms such as Web and mobile operating systems. This helps organizations lower their IT costs.

Yalim K. Gerger

Share/Bookmark

Share/Bookmark

Formspider turns your PL/SQL team into super productive Web 2.0 developers instantly. It enables the same PLSQL team to deploy applications to different platforms using the same language to program and the same notation to design user interfaces. By empowering the PL/SQL developers, Formspider reduces the IT costs of organizations.

There are new projects spawning everyday all around the world that use Formspider as their primary platform. At Gerger, we are also not sitting on our hands. We are busy with helping our customers succeed and preparing a new version Formspider.

In a few months, we will tell you all about it. Stay tuned.

Thank you all again very much for your interest in Formspider. As usual, don’t hesitate to contact us if you have any questions or comments. We are here to help.

Regards,

Yalim K. Gerger
CEO

Share/Bookmark

As a beautiful summer comes to a close in the northern hemisphere, I’d like to take this opportunity to thank you for trying out Formspider, the Web 2.0 framework for PL/SQL developers.

This has been the most amazing summer in my life, by far. I’ve met with many brilliant PL/SQL developers around the world. We exchanged ideas, solved problems. This encouraged my teammates and me even more to further improve Formspider. We are determined more than ever to build the best Web 2.0 framework for PL/SQL developers. However, we cannot accomplish this task unless we communicate with our users. Today, I invite you to let us know what new features you want us to implement in the next releases of Formspider. Please, visit our feedback page now and vote on the many proposals our users made or make your own suggestions.

Formspider made a great start to what I hope is going to be a long wonderful journey. I hope we were able to help you along the way. If we were not, tell us what we can do better. We’ll try harder this fall.

Thanks for a great summer.

Sincerely,

Yalim K. Gerger

Share/Bookmark

Back in the Oracle Forms days, the only way you could make an application perform poorly was to do something that an experienced developer could easily avoid or fix when discovered, such as write a bad query. In JavaEE environments, you must be an expert in every one of the component technologies, or applications that appear to work well in development will fail in test or production.

Large enterprise applications built with Web 2.0 technologies such as AJAX and JavaScript libraries, often create too many objects in the DOM and load too much code for the browser to perform adequately. This problem is usually detected very late in the development process and may have its roots deep in the architecture, with the result that correcting the problem in time may be an impossible task. Development teams are expected to adhere to a certain set of rules and manage the load they are putting on the browser.

This is a new problem in Web 2.0 development that did not exist in the early days, when the application was divided into many pages. Users called pages from the server as needed. Even if the actual application consisted of thousands of pages, the user accessed them one at a time. With the emergence of AJAX and JavaScript libraries, an entire application can be loaded to the browser all at once. However, this doesn’t mean that it should be. The architects are faced with the problem of web pages taking too long to load. For example, an entire finance system might need to be loaded to the user’s screen even though the only operation needed was looking up an account code.

The solution to this problem is obviously to load the necessary code and screens only when they are needed. However, there is no mechanism to do this automatically. Development teams are forced to choose between two evils. They either have to manage the deployment of the code to the browser manually, or just forward the user to a new web page. The first option causes a lot of “plumbing” for the developer to manage. Naturally, this process is very error prone. The second option sacrifices the user experience. It also divides the application into arbitrary page groups. Probably, the worst effect of the second option is that it involves server-side coding which means adding another programming language and framework to the complexity of the application.

Formspider applications run in the database and load only a small (300KB) JavaScript library to the client that has been extensively tuned. Each Formspider application uses the same library. The screens of the application are loaded to the browser only when they are accessed by the user and cached for the duration of his session. This provides an environment that “by design” is going to run quickly end efficiently. You have to work hard to make a Formspider application perform poorly. Any performance problems can easily be discovered by an experienced PL/SQL developer.

Share/Bookmark

Back in the old Oracle Forms days, a developer could build a moderately complex screen in about a day. That same screen takes a week to build in a JavaEE framework and the probability of that application actually working when you get to production is much lower than the old Forms application.

The Formspider IDE was written using Formspider. The IDE was the first application developed. From the very start, we were not just the developers, but also the customers. As a result, much effort has gone into making the IDE intuitive and productive.

We built the best, the most user-friendly XML Editor for the Formspider IDE. It helps you build your screens by completing your code automatically, formatting it beautifully, and giving meaningful error messages.

Because the main layout editor is written in XML, the entire IDE only comprises about 100 screens (~20 of which you use 80% of the time). Compare that with Oracle’s Application Express (APEX) that includes over 2000 screens in the IDE.

Objects that have been logically associated (such as panels on windows) can be found as child objects in the navigation tree, so there is no need for a text search for impact analysis when you delete something.

Testing your application requires a single button press. There is no deploying or waiting for the application to compile. It runs exactly as if it were in the production environment. Formspider includes an excellent debugger. It will even show the component you are looking at which makes finding where a change needs to happen very easy.

Give it a try. You will love it.

Share/Bookmark

The technology to develop the same UI changes from platform to platform. Web, mobile and desktop technologies vastly differ in the way in which they define user interfaces. If a screen is developed in Java Swing, there is no way to render the same screen in a browser. It would be easier to rewrite the screen as a JSF, JSP, or ASP page. This is extremely unproductive because when a new platform emerges for deploying applications (such as mobile native applications), the UI development experience in the old tech stack is useless. Developers must go back to square one.

With Formspider, developers can learn it once, and develop screens for any platform. Each platform may have its own special components, constraints, layouts, etc. However, the way to build the screens, create events on them, and associate programs with these events can and should be similar. A button is a button, and a button press is a button press, whether it occurs on a tablet or a PC. There is no need for multiple ways to define this element.

Virtually every existing framework locks organizations into a platform by choosing a client-side programming language: web, desktop, or mobile. Developing in one environment without needing to know its details is just as valuable as true browser compatibility because, in the end, each browser is just another platform.

Many people believed that the web eliminated the need for deploying native applications. This perception was completely overturned by the emergence of mobile operating systems. As of today, PL/SQL developers have no way of building applications for the mobile world.

Formspider provides a way to deploy native applications to platforms including mobile operating systems. The client-side library of the framework can be Java, ObjectiveC, or anything else that happens to come along. This flexibility enables organizations to deploy to different platforms using the developers’ existing PL/SQL skill set. The platform is just another target to deploy to. Each platform may have its own set of layouts or even components. For example, the constraints and requirements of a mobile application are very different from those of a web application rendered on a 27-inch monitor connected to a quad core machine with 32GB of memory. However, the notation to develop the UI and the language to script the program flow stays the same. Developers continue to be productive in an environment that is familiar to them. They can use the same APIs, IDE, debugging tools etc..

Another side effect of the current development method is that separate developers work to deliver applications to different platforms which essentially fulfill the same business needs. It becomes very difficult to synchronize these applications in behavior, look-and-feel and features made available to users. The ECA architecture makes it possible for the same PL/SQL development team to control applications running on different platforms, thus providing consistency.

Share/Bookmark

As long as data is stored in the database, code written in the database will have a huge advantage over code written in the middle tier. In the Oracle environment, developers know PL/SQL. Therefore PL/SQL is the natural language of choice for application development.

One of the biggest handicaps of currently available frameworks is that they require extensive knowledge of several programming languages. For most JavaEE frameworks, a developer needs in-depth knowledge of Java, JavaScript and a variety of component technologies. With so much to learn, it is understandable that most Java developers resist becoming skilled database developers as well.

Becoming an expert in a single programming language takes years. Asking enterprise application developers to become experts in two or more languages is counterproductive. An enterprise application developer must understand business rules and implement them in code. A programming language is the means by which this task is accomplished. Once a developer is expert at expressing the business rules in one programming language, learning any additional languages is time consuming and may not ultimately help them become better developers. If you ask an experienced PL/SQL developer to program in Java (or the other way around), they will struggle with the nuances of the new language for years. The result of this struggle is sub-par performance, bugs, and low-quality applications.

The PL/SQL scripting used in Formspider will look familiar to Oracle Forms developers. The ability to manipulate components is similar to what Forms developers have been using for years. Because the scripting is in PL/SQL and stored in the database, developers can use any PL/SQL editor to write programs.

The following code shows the script used to create a login button:

Login Screen

procedure doLogin is
  v_loginResult_tx varchar2(10);
begin
  --- this is the call  to the developer’s login package,
  v_loginResult_tx:=myapplication.doLogin(
     ---this retrieves the value from the “User name”
     api_component.getvaluetx('loginPanel.user'),
     ---this retrieves the value from the “Password”
     api_component.getvaluetx('loginPanel.password'));
  if v_loginResult_tx=’OK’ then
    ---this hides the login dialog
    api_dialog.setvisible('loginWindow','N');
  else
    --login failed. warn user.
  end if;
end;

The actual procedure would be more complex but this example shows how application behavior can be coded in Formspider.

It is as simple and intuitive as in Oracle Forms.

Share/Bookmark

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:

api_textfield.set_visible(‘mytextField’,false);

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:

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.

Conclusion
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

Share/Bookmark