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.