Formspider is a truly amazing powerful web application development framework that deserves a serious evaluation. Compared with Oracle APEX they have a little disadvantage, APEX is free and Formspider is not. Still, if you have been around in APEX for a while, you already found that issues pop-up if applications grow bigger. If you foresee that your application will become a large application my recommendation is to make a serious selection process. For a while there was no serious alternative for APEX, with Formspider, there is.

Formspider is useable but not finished. It is an actively developed tool. When customers/developers ask for features that make sense, the development team builds it on request. They chose to start with the basics and respond on demand. Doing so allows them to concentrate on what is actually needed instead of making a pile of features that no one uses. I think this is a good approach and if you see how quick they can respond on feature requests … amazing. Signup on their site and play with it yourself using their online IDE

Because Formspider is a living tool, you will almost certainly going to be confronted with upgrades. It is at this moment where you really find out how you should install Formspider. For me, upgrades form a challenge because whatever I do, I want the easiest/ quickest possible fallback thinkable. Just like with the Oracle rdbms software, the most flexible way to upgrades is out of place. This means to make an installation next to the previous version. In the case of Formspider, most code is in a database schema so this means having to create a schema for a version of Formspider.

flexible and secure installation of Formspider

The goal here is to

• make an installation that does not give unrestricted access to the database by using the middle tier connection details.
• make multiple versions of Formspider in one database possible
• make upgrades easily reversible with the least possible amount of downtime
• make upgrades easily to test before it goes into production/development.

In my blog post http://ronr.blogspot.nl/2012/07/how-to-setup-formspider-apex.html the general installation process is described. Here I will describe the changes needed to make the flexibility.

In short it comes down to

• install Formspider in a versioned schema (for example formspider_1_00 or formspider_1_01 or formspider_2_12)
• make  a Formspider web user that is the user of the versioned Formspider schema (formspider_web_2_12)
• create private synonyms for the formspider_web_* user referring to the corresponding Formspider schema.
• grant a few privileges from the Formspider schema objects to the corresponding Formspider_web user.
• lock the Formspider schema.
• Create a new jdbc pool that uses the new Formspider_web user
• deploy the corresponding .war file as a new Formspider application in GlassFish – formspider_2_12
• give it a versioned Document root – for example – /formspider_2_12
• make a proxy_forward rule in Apache to point to the versioned Document root in GlassFish

The only privileges that the Formspider_web_* user needs are create session and a list of Formspider_* object privileges, listed below. This list might change and with a little luck, Formspider will integrate a similar setup script in their installer and upgrade scripts. I won’t sue them for copyrights … 😉