Formspider enables you to create gorgeous charts declaratively. Creating charts has never been easier for PL/SQL developers. Moreover, Formspider charts are implemented 100% in JavaScript. There is no Flash at all. So the charts you create with Formspider, work perfectly on mobile devices that do not support Flash, as well. Make sure you check out the demo and the tutorial.
300 Installations
Posted by admin on November 22, 2011
0 comments
Today, we are happy to announce that Formspider surpassed 300 installations worldwide in less than seven months. The response to our value proposition from organizations and developers that use PL/SQL has been phenomenal. Everyday, more and more PL/SQL developers embrace Formspider and appreciate its benefits.
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
A Summer of Forms
Posted by admin on October 5, 2011
3 comments
Dear Formspider Users,
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
Benefits of Formspider: Great Performance without Great Effort
Posted by admin on September 22, 2011
0 comments
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 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.
Benefits of Formspider: Productive Development Environment
Posted by admin on September 21, 2011
0 comments
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.
Give it a try. You will love it.
Benefits of Formspider: Single Development Environment for all Platforms
Posted by admin on September 20, 2011
0 comments
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.
Benefits of Formspider: Single Programming Language
Posted by admin on September 19, 2011
0 comments
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 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.
How does Formspider work?
Posted by admin on August 24, 2011
2 comments
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. 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:
- 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.
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
Charts with Formspider
Posted by yalimgerger on June 29, 2011
0 comments
Korhan prepared four cool tutorials on how to create charts with Formspider. The interesting thing is, these tutorials are just the beginning of what you can do with charts in the framework. Take a look at them and find out how you can add beautiful charts to your Formspider applications.
How to build charts with Formspider
Building single plot, single renderer XY and Category Charts
The 100th Confirmed Installation
Posted by yalimgerger on June 15, 2011
0 comments
When we made Formspider Installer available in February, we counted how many people are actually downloading it. After a while a thought came to our minds. PL/SQL developers from all over the world were downloading Formspider. But were they installing it? We had built a notification system to the installer that alerted us when an installation attempt failed (with user’s permission of course). However, we had no mechanism to know how many of the installation attempts succeeded. We updated the installer in May to count the successful installations.
Formspider Installer opens up a thank you web page when the installation completes and we count how many times we render the thank you page. This page serves to a much more important purpose too. We’ve felt like the end of the installation did not really reflect our sentiments about how happy we are that you are giving Formspider a shot. Our thank you page shows how we really feel about it.
Formspider surged passed 100 installations in just five weeks. This is amazing. Thanks to Formspider, we have met many people from all around the world. We exchanged ideas, received invaluable feedback and hopefully we were able to help them as well.
On behalf of the team, I would like to sincerely thank everyone who is giving Formspider a shot. We love to hear what people do with Formspider. Please don’t be a stranger. Let us know what you do. Send us an email, ask a question or get involved in social networks. We are here to help.