Formspider Presentation

Joysticks vs. Game Controllers

If you allow me, I would like to talk about joysticks a little bit before I dwell into web, frameworks and application development, because I know we’d all rather play than work.
First Joystick

First Joystick

Remember the first joystick? The red button, the stick with eight directions. God knows how many I have ruined playing soccer games on my computer. Over the years the computer hardware improved. Soon enough the software followed and games became much more sophisticated. It is arguable whether they got any better but they certainly got way too complicated for the good old joystick. The joystick was out of its league. It needed to be replaced and after several iterations, what we ended up with for games of the 00’s and 10’s is the six axis game controller. Two sticks, seventeen buttons that I could count and tilt sensors. One wonders if there is a variation of Moore’s Law in play here for the number of buttons on a game controller.

A Modern Game Controller

A Modern Game Controller

The joystick was the perfect solution for the games during 80’s and the early 90’s. A simple solution for the simple controls gamers needed. It was intuitive. A lot can be said for six axis game controller but one thing you cannot claim is that it is intuitive. It has a steep learning curve that puts controlling the controller ahead of enjoying the game you are playing for quite some time. Pressing L1+R2+O is hardly what I think of when I want to take a fade away jump shot. Those of you who follow the game industry will know, there is now a lot of innovation going on to replace the six axis controller with something better. Sony is experimenting with a magic wand, Microsoft is trying to watch your moves while you play. We also know the amazing success Wii had because it was able to align the moves in a game with the gamers instinct to make those moves.
Remote Controllers in the Living Room

Remote Controllers in the Living Room

The point is that when technological advances occur, the hardest part for the producers is to incorporate them into their products and still keep them intuitive, easy and productive to use for the customers and it virtually always comes last. It is during this transitional period where we have lots of features and lots of buttons which makes the users feel out of control, overwhelmed, unproductive and ultimately unhappy. The exact opposite feelings that product design aims to achieve. Just take a look to our myriad of remote controls at home for another case in point. By the last count we had six remote controls in the living room and I am pretty sure a button on one of them makes it rain. I swear to God, I don’t think it is a coincidence.
Oracle Forms Developer

Oracle Forms Developer

Forms Development vs. Web Development

A similar transition has happened in the Enterprise Application Development world as well. In the 90’s our joystick in the Oracle world was the Forms Developer. That was all we needed to know to control the game of application development. In the 2010’s we have Javascript, Java, PL/SQL, Oracle ADF, Hibernate, Google Web Toolkit (GWT), HTML5, CSS3, Web Workers and browsers with their idiosyncratic behaviors to worry about. In Forms, you developed in PL/SQL and the application magically ran on every Windows machine. You did not know a single Windows API. Today, before you even make a mouse move you need to think whether it would be wiser to code that line in JavaScript or Java. You have to know what brand of browser or platform your code will execute in. One day a new version of Forms came out which deployed to Web and your applications now were running in a browser, in all of the browsers. How convenient. Today, a new browser or platform emerges and several die out every couple of years and you go back to square one again. There goes all the time and money your company invested in Oracle ADF Struts.
Block.item

Block.item

In Forms, you put a text item on the screen and it showed up where you put it. You didn’t worry about box layout, flow layout, grid bag layout, spring layout. You didn’t have different user interface component libraries or the option to build your own. When you needed to look up a value from the user interface, you went :block.item. You did not create a backing bean, made sure the user interface control is tied to the right bean property and exposed the relevant method unless of course you are utilizing partial page rendering. In that case you need to be a little careful because the applications have a life of their own now and in the case of partial page rendering the life cycle takes a different path. Well what can you do. That’s how life is. In those days, when the users wanted to go to the previous screen they were looking at, they closed the window or switched to the previous tab. Now you need to worry about the Back button and implement a history token and handle it in an object that implements the ValueChangeHandler interface. Alternatively, you may choose not to support the Back button at all and make it a user training issue. However the users (oh life would be so easy without them) will click it anyway and send you the same order seventeen times and then complain about it even more. In 1995, you wanted to show data, you populated the block with data. In 2010 you gotto create an EntityObject, a ViewObject on top of it, create an application module and inside of it create an instance of the ViewObject. OK that is the work in the model layer. Now in the view layer, you need to create a data control so that you can access the application module you created in the model layer. From here on it is all downhill though. Once you create a binding container that will hold an iterator which points to the ViewObject instance and attach a binding to the iterator, all there is left to do is to create a table in a page which points to the binding. Not the binding container, the binding. Don’t be silly.
Comeback

The State of Enterprise Web Development

So what now? Should we go back to Forms? No way. I think the changes are for the better. I love Web 2.0, HTML5, Ajax, JSON etc…They make many things possible which weren’t in Forms. Life did change in the last fifteen years and we all must adapt. Yes Oracle still makes databases, British still make crappy cars and Guns and Roses is still about to make a comeback. (For the record, they actually made a comeback. It is just that no one noticed.) But even compared to five years ago we deliver applications to more users, have more devices and platforms to support, have to manage more data and deliver more quickly. Forms is out of its league but its replacement JavaScript, Java, HTML5, GWT, ADF, ExtJs, Hibernate, EJB… in short the six axis controller with its seventeen buttons is unproductive. What we need is a chef that makes a delicious meal out of all these delightful ingredients. Something that puts all these technical possibilities together in a meaningful way. A framework, a tool, a development environment.
Half-baked
Well obviously I am not the first one who noticed this problem. Some of the buzzwords I’ve been mentioning are attempts to solve this very issue. JDeveloper&Oracle ADF, Struts, GWT to name a few. Some of these attempt to solve only a part of the problem. UI developers who know Java but pretend it is Javascript developed GWT. UI developers who know both Java and Javascript but made it a point of honor not to code in Java developed ExtJs. But they still don’t help you with your interactions with the database. So you naturally ask “This is all great but I’ve got 150 tables that I need to query in the database and I need a way to show the rows in them in your marvelous text items. The users must be able to update these rows and save their changes back to database.” “You are on your own dude” is the answer you get along with a lecture. “We do the View and the Controller (when we can) not the Model. Model is separate.”. “OK so could you at least point me to the right direction?” “Use EJB’s or Hibernate, or code your own, there are many libraries out there to give you a head start”. “Hmmm…OK fine. Assuming I’ve done all that. All the data is now in the server ready to be served up to the application. How do I do that?”. “Oh that’s easy. Just use XML, JSON or your own structure for best performance, wrap it all up, retrieve it using an XMLHTTPRequest or a beacon or whatever and make sure you distribute all the data to the necessary components.”. “OK. Now obviously UI development is your strong suit. Let’s talk about that a little. Declarative UI design, an empowering development environment etc…” ” Good news! The latest version we released last week is our first attempt for declarative UI Design. We also have an SDK to help you build applications and an Eclipse plugin”. If there is anything you need to be aware of, it is that when framework people say SDK they usually mean a DOS screen and Notepad and by Eclipse plugin they mean a DOS Screen and a glorified Notepad. So at best this is a six axis controller with seventeen buttons for the view controller layer that requires another one for the model layer.
Ambitious Changes

Ambitious Changes

Some of the frameworks are more ambitious. Like the Oracle ADF. Oracle ADF went after the whole thing: View, controller, model. It went further and provided a complete IDE, declarative UI, business process and database design with WYSIWYG editors. Oh my god, it is beautiful. It is the holy grail of JEE application development. As a result, you deal with at least two different markup languages, two and a half programming languages and hundreds if not thousands of files automatically generated by the framework for your convenience that manage thousands of Java Objects. So what do we do if creating all these things are very tiresome. We build wizards! Wizards are great to create a text item. You drag and drop the text item, point it to a database column and there you go, all the XML files needed to make the emp show up on the screen are generated for you. So far so good. But what if you delete the text item? Will these XML files be updated automatically? What if I want to do something very particular, very interesting about this text item? This must be the case anyway, otherwise what am I doing here as an application developer if my work can be done by a wizard? What then? Which one of these 765 XML files do I update? What happens is that you get pointed to an application developer guide that makes you think of getting a PhD in biotechnology instead. And there happens the very thing that we’ve been trying to avoid right from the very beginning. The developer feels that she is not in control. She is frustrated. Hunderds of UI Components, dozens of Java libraries, thousand of files in the workspace make her feel like she spends more time in solving technical issues caused by the development environment than the business process she needs to implement. She is not productive. She is not happy.
Even though these frameworks are all steps in the right direction, the solution they bring to the table for the problems of our time still lacks the elegance of the solution that Forms brought to the challenges of 80’s and 90’s. And that is why we built Formspider.
Expectations

Expectations

The Revolt of the PL/SQL Developer

So what did we do? We set our expectations high. We refused to settle for less functionality and more complexity. We set out to eliminate every obstacle that turns web application development into a drudgery and embrace every feature and advance in technology that makes it a joy and an intriguing problem to solve.

One Programming Language Across All Application Layers

On the top of our list of back-breakers was the multiple programming languages one needed to master to develop a web-based application. It takes a couple of years to get very good at a programming language. It takes five six years to become really good. We already had the tens of years of experience in PL/SQL. Do we really want to throw all that intellectual investment away? Couldn’t we build a specialized small team of really good JavaScript developers and have them build the components we need in our applications and provide us a way to control them via PL/SQL? Of course we could and of course we did.
only pl/sql
In Formspider, PL/SQL is the only scripting language. Period. There is no need to know or learn Java, JavaScript or any other scripting language. You want to make a text item visible in the UI? You call a PL/SQL API. You want to set a value to a text label? You call a PL/SQL API. The benefit is that we get best of all the worlds. Our small team of specialized JavaScript developers can go read all the books, follow all the tweets, jump every bandwagon they want and figure out how to render our UI’s the fastest, the most beautiful way to all the browsers out there. They know all the tricks, bugs and idiosyncratic behavior there is to know about them. They know them so that you don’t have to. They test every piece of code on three browser brands and their six versions, so that you don’t have to. They bang their heads onto the wall and go through nervous breakdowns whenever a new ECMAScript Specification is released so that you don’t have to. When they improve anything, they will improve it for all Formspider applications out there because all Formspider applications use the same library. In the meantime, Formspider developers focus on the best way to code their business requirements in PL/SQL and become awfully good at it.

High Level Abstraction in Screen Design

The second annoyance in our list was the markup languages one needed to master to design a freaking Order Entry screen.  One always naively starts at a high abstraction like a JSF or JSP tag library only to find out that unless one masters HTML and its upgrades DHTML, XHTML and the DOM along with the BOM it is impossible to finish the screen let alone debugging it. Formspider features an intuitive XML notation for declarative UI design with instant graphical feedback. There is no need to know anything else. However, it plays nice with every other mark up technology out there and provides components for seamless integration.
Web to Desktop

Platform Independence

The other issue that always caused discontent was the technology lock in most of the available frameworks brought about. If your application is coded in Flash, it will run in Flash today and tomorrow and ten years from now on. No way of changing that puppy’s name. If your application is built with DHTML/JavaScript, in the browser it stays. Technologies come and go. First it was JSP’s, then Flash, now that seems to be on its way out too. We were also frustrated with the loss of tremendous amount of perfectly functioning high quality code each time developers faced a rewrite because a user interface technology became old and the application had to be ported from JSP’s to JSF. We couldn’t help but wonder: What if we could change the user interface technology of an application with the click of a button and it would all just magically work? Thursday 14:01:24 the application is running as a Java Desktop application. Thursday 14:01:25 the application is running as a Web 2.0 application. Yup, Formspider does that. The applications built with Formspider are evergreen. They never get old, out of style or archaic. How is that possible? Since all the programming is done in PL/SQL and we just have PL/SQL API’s to manipulate our JavaScript library of UI objects, all we had to do was to develop a new Java library of UI Objects. So if we use the Java library to render the UI instead of the JavaScript one, we have a perfectly functioning desktop application. Both libraries use the same protocol to communicate with the same API’s. So why do I care what technology the application runs in when I turn my business into code? Let it be whatever the order of the day is, I say.  Today Formspider applications can be deployed as Java Swing Applications and DHTML/JavaScript Applications. By just building a new UI library we can deploy them to Flash, Iphone, Android, Silverlight or whatever is next.
Formspider Web and Desktop IDEs

Formspider Web and Desktop IDEs

Productive IDE

We also demanded a superb development tool. We know how much a great tool can help improve productivity and the joy of coding.  We clamored for a tool that enables quick access to all framework features and objects without cluttering the screen with twenty dockable internal frames that keep popping out from their docks, a robust way to do dependency analysis between framework objects without text based search, an editor that helps you build and visualize your UI design. Formspider IDE gives you all that. One other thing that our developers hated was that the IDE’s of today are gigantic in size. Most of them are one two gigabytes. We dreamed a development tool that is small in size and easy to install. We achieved this goal by making Formspider IDE completely a web based application. So your last excuse to work from home has gone too. As last but not the least, we are a big believer in eating our own dog food. We value using our own framework to build our own applications and Formspider IDE is no exception. Our IDE is entirely built using the Formspider Framework. How many frameworks can claim to have built their own development tool? Not many.
Healthy Application

Painless Database Interactions

Declarative binding to database tables,views and queries, out of the box support for automatic DML generation were must haves for us. To give credit where it is due, Oracle Forms truly excelled in this area. Have you ever heard of a Forms Developer worried about binding a text item to a database column? It is as if the very notion of binding doesn’t exist in Forms. It is implemented that good. So the spoiled brats we are, we’ve never had any intention to do all the plumbing for binding UI Components to database objects and managing database transactions. There are frameworks that have this feature but they make you aware of the fact that there is a binding. As a result, the developer is burdened with creating, maintaining, and worrying about this binding in her daily work. Formspider seamlessly binds UI Components to your database objects and manages your database transactions. Just like in Forms…it just works.
Web Performance Test

Web Performance Test

Best Practices

We love to embrace industry best practices. The JavaScript library passes all performance tests with flying colors. Gzip, minification and the rest of the 34 rules of best performance on the web all packaged in our installation ready to excel in the most challenging environments in terms of Internet speed. All Formspider applications use AJAX to communicate with the server. In fact, AJAX is the only way they communicate with the server. A Formspider application’s look and feel can be infinitely customized using CSS. You may use one of the ready made CSS files that ship with the framework, edit them or write your own.
Battle Tested Framework

Battle Tested Framework

Proven Track Record

Formspider is also arguably the most battle tested framework that ever came out. We built multi million dollar projects with it. It runs in government offices of United States and in African networks. Thousands of users conduct their business in applications built with Formspider everyday and manage billions of dollars. Formspider is reliable and has the track record to prove it.
So there you have it. PL/SQL is cool again. Formspider empowers PL/SQL developers to build amazing Web 2.0 applications that will make the Java, JavaScript Developers jealous. It is an intuitive, elegant framework that just feels right to build applications with. A framework that puts you in control, eliminates all the drudgery of the Web but embraces all its beauty.
Yalım K. Gerger

Leave a Reply