OraTransplant

Oracle’s plans for Forms version 11g

7 June 2006 at 21:44 CEST | In Forms, Oracle, Patches and upgrades |

Tonight Oracle Product Management held a webinar about their future plans with Oracle Forms version 11 for the Customer Advisory Board for Development Tools. As you might know I’m a member of that advisory board, so I attended the webinar.

In this blog entry I would like to outline the plans as they were presented. Of course the webinar had the usual disclaimer that it was for informational purposes only and it is not a commitment to deliver these features.

Forms version 11 is planned to be part of Oracle Application server version 11, which is planned in 12-15 months, which means summer 2007. Forms will not participate in the 10.1.3 platform, so the version 11 will be the first after the current 10.1.2 line.

The primary focus for this new Forms version is with three areas; Interoperability, Deployment and Administration. In total, Oracle presented 8 new features that are approved and scheduled for version 11. Some of the features are even already being worked on. There’s a fair chance that all of these 8 new features will make it into Forms 11. This means it is not guaranteed that all these new features will make it in the final version. I assume that’s due to the normal time and budget limitations.

Let’s get on with describing the eight new features:

External Events

The first very exiting new feature is External Events. This will make it possible to call into Forms from the outside world. Currently we just have user initiated events and timers that can trigger code being executed in the Form (and thus on the Forms server). With External Events, Forms can be triggered by messages in Oracle Advanced Queuing in the database. Since BPEL can also communicate with Oracle AQ, this enabled triggering events in Oracle Forms from Oracle BPEL.

This strengthens the central position Oracle BPEL seems to take in the Service Oriented offering by Oracle. BPEL can already communicate with a whole range of external sources (monitor changing files, web services, mail, wireless, JMS, database data, .Net services, B2B, EDI, etc.). Using Oracle Advanced Queuing and Oracle BPEL all of these external systems can basically trigger events in Oracle Forms asynchronously.

But how can an event triggered on the server propagate to the client? The Forms client uses the HTTP protocol which is by its nature request/response only. If the user is actively working with the Forms session, any server side triggered event can propagate to the client. For example, if the triggered event changes some visual attribute, the client is synchronized on the next user interaction. But what if the user is idle? Oracle solved this with a polling mechanism. There is a MAX_EVENT_WAIT setting that sets the polling interval. You can define this in your configuration file, but you can also change this at runtime with SET_APPLICATION_PROPERTY.

The External Events sounds like an interesting new feature to Oracle Forms, but the downside is the extra resources used by the polling mechanism. You have to be wise in setting the polling interval.

Scheduled pre-starts

Back in the old days, every new user session had to create a new Forms server process on the fly. This resulted in delays for every new session. In Forms 10g, pre-starting was introduced. This allows you to define a number of pre-started sessions. This reduces the startup time of new sessions.

This works fine, but is a bit rigid. With Forms 11 you can schedule pre-starts. You manage this from the Enterprise Manager. You can schedule in a number of ways; define the number of pre-starts at server startup (what we have today in 10g), set a number of pre-starts to be effective immediately, schedule a number of pre-starts delayed (e.g. tomorrow at 11:00 AM pre-start 25 sessions), daily, weekly and monthly. This enables you to have a different number of pre-started sessions available at different moments. For example, be sure to have 25 extra pre-started session every Friday at 11:30 AM when the end-of-week cycle starts and user load increases.

JavaScript integration

The third (and for me most interesting) feature presented was the JavaScript integration. This goes both ways. JavaScript in the web page can raise Forms events and you can call JavaScript from Forms. This JavaScript integration enables you to mix and match your “old” forms with newer web applications (e.g. JSP or JSF).

The Forms applet has an extra method raiseEvent that can be called from JavaScript. This method accepts two arguments: the name of the event and a payload. A snippet of JavaScript to illustrate this:

function raiseFormsEvent(data) {
  forms=document.getElementById('frm');
  forms.raiseEvent('myEvent', data);
};

If this JavaScript function is called it will fire a WHEN-CUSTOM-JAVASCRIPT-EVENT trigger in Forms. This trigger can access two new system variables: javascript_event_name (the name of the event) and javascript_event_value (the data/payload). An example of such a WHEN-CUSTOM-JAVASCRIPT-EVENT trigger:

declare
  eventName  varchar2(30) := :system.javascript_event_name;
  eventValue varchar2(100);
begin
  if (eventName='myEvent') then
    eventValue := :system.javascript_event_value;
    handleMyEvent(eventValue);
  end if;
end;

It also works the other way around. You can call JavaScript from Forms with a new function javascript_eval in the already existing web package:

function web.javascript_eval (expression varchar2,
  target varchar2 default null)
return varchar2;

With the target argument you can specify the window in which to evaluate the javascript. If not specified, the window the applet is in is used.

Java Events

In version 10g, Java Components extending VBean (Java Beans) can raise server events. In version 11, all Pluggable Java Components (PJCs) will be able to raise these events. This will no longer be restricted to VBean childs.

We don’t use Java Components (yet), so this is not a very exiting feature for our environment.

Proxy User support

Forms 11 will be able to connect to the database thru a Proxy user. A proxy user only has the privileges to connect only. It does not have privileges to modify or select any data. The proxy user is allowed to connect “on behalf” of another user. This “other user” is the real user using Forms. That user does not require connect privileges in this scenario. This keeps these users out of the database directly with tools like SQL*Plus or ODBC connections.

Both in the database and in Forms you can get both the proxy user name and the “real user” name. In Forms this will be through GET_APPLICATION_PROPERTY calls.

PL/SQL tracing

Forms 10g already has a tracing facility. Unfortunately this trace does not log the names and parameters for called PL/SQL. This will change in version 11. This will log the name of all called procedures and functions, including the IN and OUT parameters, whether the call is to a local program unit or stored PL/SQL in the database.

Performance tuning

Forms 11 will include a Performance Tuning Tool that can identify and correct common performance draining application constructs. It will start by making a duplicate of the form(s) to scan, it will scan it and suggest ways to tune performance. You can call it by using a GUI or via the command line.

Typical constructs it will scan for:

Raise on entry property set for initially not displayed canvasses.
Unnecessary boilerplate objects
Prompt vs. boilerplate text
Explicit to implicit cursors. Back in the old days explicit cursors were preferred due to performance. But since (probably) version 9.2 of the database implicit cursors have been highly optimized and should now be preferred over explicit cursors.
Calls to SYNCHRONIZE
Use of CLIENT_TEXT_IO
URL_To_Client vs. AS_To_Client
Timers
Interaction mode
Query array size
Number of records buffered
Bind vs. PL/SQL variables
Mouse-Up and Mouse-Down triggers

I guess it will be similar to the Forms Migration Assistant that is based on the JDAPI.

Oracle Diagnostics Logging (ODL)

All the different components of the Application Server have their own logging strategy, which basically makes it a mess. You are left with dozens of log files in very different locations with very different naming strategies.

Oracle has developed the common logging mechanism ODL (Oracle Diagnostics Logging). This has to be used by all Application Server 11 components. It extends the Java logging framework in J2SE (java.util.logging API). In the first incarnation only the Forms Servlet will use the ODL framework.

Using OLD means that the log files will be easily accessible from Enterprise Manager. It also enables correlation of messages in different log files. It also handles things like log file rotation and file size restrictions.

Conclusion

Personally I was impressed with all the new planned (and scheduled) features for Forms version 11. Lots of people have been saying that Oracle Forms is dead and that Oracle is abandoning Forms and minimizing development. To me, this proves otherwise. Oracle is not allocating the amount of resource to Forms as it does to JDeveloper, but I don’t think it is necessary for a mature product like Forms. Especially features like External Events and the JavaScript Integration opens up Forms for integration with other technologies. This means Forms can be part of your architecture for years to come and can integrate with all the new BPEL, SOA and other stuff coming our way. It means Oracle is protecting your investments in Forms technology while still enabling you to start using newer technologies while integrating both.

41 Comments

TrackBack URI

Interesting inside information Wilfred. Your conlusion is very true, and should reassure Forms developers, including myself.

Michael

Comment by Michael — 7 June 2006 #
That’s very good news, esp. the javascript integration. My favourite feature would have been client/server support, though …

Comment by Chris — 8 June 2006 #
Wilfred,

I also attended this webseminar, but was not impressed at all. I was pretty excited about the whole thing, now I am just disappointed.

I personally think Oracle IS minimizing development on Forms and they are (slowly but steady) abondoning the Forms track.
There won’t be much Forms developers left at Oracle if it takes 12 to 15 months to implement this very low number of features.

Which features makes this version change ‘believable’ in your eyes?

I think Forms 10.1.3 (or even 9.0.5) would have been a better name, but that’s no good marketing I suppose.

Grtz,
Wouter

Comment by Wouter Janssen — 9 June 2006 #
I have to agree that Oracle is not investing as heavily in Forms development as hey have done in the 90’s. But I don’t think they have to. Forms is a relative mature product. I guess Oracle is putting Forms in a sort of “maintenance mode”, but so are most of their customers. We are moving away from Forms for any major new development, but we’re not actively migrating existing Forms applications to other technology stacks.

This means, we’ll probably have Forms running for a number of years to come. I do want to upgrade these Forms to the latest version to have the benefits of increased integration with my new J2EE applications. On the other hand, I don’t want to spend a whole lot of resources on these upgrades. I want Oracle to protect my investments in my Forms. I don’t want any majort upgrades like SQL*Forms 3.0 to client/server GUI or the client/server GUI to the web anymore.

So, the low impact improvements Oracle is making to the Forms product are just fine for me. They make it easier to integrate my “old” Forms with my new J2EE technology stack without imposing resource intensive upgrades/migrations.

So, to me the integration with my J2EE stack is the most important. This also makes the External Events and JavaScript integration stand out.

It looks like we will be using BPEL in our environment and it looks like the External Events feature can help us integrate our “old” Forms with the new BPEL flows.

The most usefull feature to me is the JavaScript integration. We are moving to a web based user interface (using UIX and/or JSF). We will slowly be rebuilding certain parts of our Forms application in these web technologies. However, we will have a hybrid environment (Forms and JSF) for years to come. So, when a user is in a JSF application I might want to jump to Forms and back to keep using the “old” Forms until they are rebuild in JSF technology.

We already tried this, but really needed communication between the two environments. For example, when starting up a Form in such a session you want to pass information from the web application. The selected OrderNumber is a simple example. Once the user is in a Form you also want communication between the Form and the web environment. What if the user browses to another webpage using one of the links on the webpage. Currently, the Forms applet will just die and no changes will be saved. With the JavaScript interface it should be possible to notife the Forms applet we’re “leaving”. This gives the Forms applet the opportunity to do normal post-form processing including asking for changes to be saved.

To come back to your original question; yes, I feel that Oracle is spending less resources on Forms development than what they used to do in the 90’s. But that’s fine by me.

Comment by Wilfred — 9 June 2006 #
i read the above comment from Wilfred he said
“There won’t be much Forms developers left at Oracle if it takes 12 to 15 months to implement this very low number of features”

i want to know why , are the form developers lefting the form development towards J2EE?? i am asking this because i am a new form developer , but i was surprised with this comment , i need more specifications please why their will not be much form developers left???

Comment by mohannad — 11 June 2006 #
Mohannad,

The comment you refer to was by Wouter Janssen, not me. What he was trying to say (I think) is that he thinks there aren’t a lot of developers left at Oracle working on Forms if it takes them 12-15 months to develop these new features.

I myself do not work at Oracle so I don’t have any inside information. It’s my own guess that Oracle doesn’t have as many developers working on the next verison of Oracle Forms as they had in the mid 90’s. Oracle Forms is a mature product and Oracle is not adding as much new features to it as they did in the 90’s. This can lead to the conclusion that the development department of Oracle Forms is smaller than it was in the 90’s.

It’s my own personal opinion that Oracle has found a good balance between protecting existing investments in Forms environments by their customers and adding new features to the product. These new features are mostly intended to ease the integration between Forms and the J2EE world.

Comment by Wilfred — 11 June 2006 #
I think oracle should invest more in J2EE environment but still maintain forms. It has been around for a long time and so many people have come to believe in the product.
What I would like oracle to do is to give an easier migration of oracle forms to J2EE and more seminars on the same.
I see a lot of good feautures in J2EE but I would like to know wheather J2EE can implement business rules as easy and fast as forms does.
Time is money!!!

Comment by Eric — 12 June 2006 #
Is forms used after 3 years for application developement.I am new in this field working in 10 g But I am not sure about forms future I think Forms will dead after max 3 years not used at all for web developement Bcz There is not much developement by Oracle in this product as editor,Object oriented feture properties etc. and user friendlynes so it is not comparable with upcoming technologies so that ORACLE has to develope it to fight with other technologies

Comment by user — 27 June 2006 #
Guys - I’ve really enjoyed reading these posts…what IS interesting is the number of people with opinions but very little inside information.
I suppose its like quip…”opinions are like belly buttons, everyone has one”…(and I cleaned that up as well! ;o) )

Grant Ronald
Forms Product Management

Comment by Grant — 5 July 2006 #
The interesting thing is that when you get an Oracle consultant on the phone today they act as if Oracle never made the Forms 2004 SOD. As far as insider information I would love to know how many developers are working on developing the Forms IDE and the JDeveloper IDE? How many Oracle Forms will be in the “Fusion” E-Business suite? How many Oracle developers are using each tool? What are budget ratios for the two IDE’s?

The company I work for is dealing with our life cycle issues and we are looking at re-engineering our homegrown enterprise suite, almost a thousand Oracle Forms, because of a change in business models / processes. Many of the Forms pundits quote the current SOD and advocate re-engineering in Forms others push for JDeveloper based on Oracle’s approach with the Fusion E=Business suite.

Comment by John — 5 July 2006 #
Hi,

I am using Oracle Forms 9.0.4.0.19 version.
Is it possible to call a java script function within forms in this version?

Is any other way to call a java script from forms?

Please let me know.

Thanks & Regards,
Chidambara Subramanian.s

Comment by Chidambara Subramanian — 7 September 2006 #
Yes, you can already call JavaScript from your Form. Have a look at Frank Nimphius’ article about calling Reports from Forms. He’s using a JavaScript solution there.

This blog mentioned the new feature in Forms 11 to do it the other way around (call Forms PL/SQL from JavaScript).

Comment by Wilfred — 13 September 2006 #
I wish Oracle would stop trying to walk this fine line between J2EE and Forms. The only thing that can be assured, at least in my option, is continued confusion and frustration for Oracle development suite customers. How many of you have a technology stack fight (between Forms and J2EE) within your groups/ organization? The problem for J2EE developers, and also as forms developers –especially as forms becomes more complex. Is the need to understand both J2EE and Forms in order to interoperate. I believe, allot of NEW forms developers are drawn to forms for its ease of use. –my Oracle rep told us J2EE was the way to go. Ok not a problem we learned J2ee. Now my “4GL” developers want to also retry the Forms track. Short of the story have to keep on top of J2EE and Forms because of Oracle’s double talk. I’m considering Microsoft’s dot net. At least I would have a vendor with a clearer commitment to product support/development.

Comment by Craig — 18 September 2006 #
There is no double talk - there is an official statement of direction which outlines various options. That is Oracle’s official position.
J2EE is one option and that may be a reasonable recommendation from your Oracle rep. In very much depends on a number of factors as to what you use to build an application…J2EE, Forms, APEX, Disco, etc etc - there have always be different options and our current position is no different.

Comment by Grant — 19 September 2006 #
We are committed to riding Oracle Forms and reports, and enhancing and selling our (ISV) application as long as Forms/Reports will run on Linux servers.

We believe that Forms/Reports is Oracles best chance to stay competitive in application development tools, but also believe that Oracle does not care about that market except for mining its past investment and developing their own applications.

We do not notice that Oracles Java toolset is making much of a splash outside of the Oracle Island, and that lots of people who use the Oracle DB seem to be migrating away from Oracle front ends completely.

We hope that Oracle will wake up and raise their level of support for Forms/Reports. We will not migrate to any other Oracle tool unless a big part of developers across the world start moving to it on its own merits, not because it is the only path open to them.

If not, when the time comes, we will migrate our application out of Oracle completely, either to dot net, or to open source tools.

Comment by Bob T — 25 September 2006 #
I meant to say we DO notice:
“..that lots of people who use the Oracle DB seem to be migrating away from Oracle front ends completely”

Comment by Bob T — 25 September 2006 #
can u provide me the material on forms9i.

Comment by shakir — 17 October 2006 #
What material?

Comment by Wilfred — 18 October 2006 #
Plenty of little companies like us using Forms/Reports and PL/SQL have no possibility to move into J2EE due the long learning curve. In the other hand MySQL/PHP etc firms are pressing the prices down.

Instead of J2EE I’m waiting “the solver” from ApEx which is based on pure PL/SQL and is very, very cheap and easy to learn. Just hope Oracle will invest in ApEx OR downsize the prices of Forms/Reports.

Comment by Heikki — 22 October 2006 #
thanks for this info

Comment by Sanyol — 23 October 2006 #
I have installed Oracle forms on my Red Hat Linux machine.
But I am not able ot start Form builder on it.
Can anyone please guide me how should I approach.

Thanks in advance!

Comment by Sumit — 26 October 2006 #
Hii
i am relatively new to forms
i would like to know if i should be getting into forms or look for other options
Basically is there future in forms??
thanks mandar

Comment by Mandar Deshwandikar — 21 November 2006 #
Compare it the easy way
[…] as a Oracle Forms/Reports and SAP/ABAP developer i see many relationships of both environments.
There is a J2EE hype at both vendors, but as you can see at SAP, it is tactical a smart solution, to go on investing in the ABAP infrastructure because of it’s business targeted easy of use. So i think Oracle have to do it the same way with his ‘traditional’ development tools.

Comment by Hans-Joerg — 12 January 2007 #
Hans - I don’t understand your comment - Oracle are still investing in the traditional tools such as Forms…thats what this post is all about…the new features in Forms 11!

Comment by Grant Ronald — 12 January 2007 #
Hi Grant,

well, did i say that Oracle is not investing in Forms/Reports ???
I only told that it is a good idea to still go on with development in business proofed tools, right ?

Sorry for the missunderstanding…

Hans

Comment by Hans-Joerg — 14 January 2007 #
Actually I didn’t say that you said Oracle was not investing…Its just that to me it read that SAP was investing then you said that you “think Oracle have to do the same in traditional development tool”.
This read as “to do the same” = “investment”

Your original posting.
“… as you can see at SAP, it is tactical a smart solution, to go on investing … So i think Oracle have to do it the same way with his ‘traditional’ development tools.

Anyway! enough of this! ;o) …It just pays to reiterate the message anyway.
Thanks

Comment by Grant Ronald — 15 January 2007 #
I’ve changed my original opinion (look at my third comment on this great post).

Have a look at
http://iadvise.blogspot.com/2007/03/oracle-forms-road-ahead_19.html
for my reasoning.

All additional comments are welcome off course!

Kind regards,
wouter

Comment by Wouter Janssen — 19 March 2007 #
It would seem the left hand is not watching the right hand. Oracle is pushing Fusion Middleware with the recommendation that Forms migrate to ADF BC and JSF. We are doing just that. However, we are keeping Oracle Reports. Why the new Forms 11g, when most of Oracle Applications are migrating out to Fusion?

As a long-time Forms developer, the change to J2EE was “interesting”. I don’t see moving back to Forms, even with all the new “enhancements.”

Comment by DaveF — 27 June 2007 #
DaveF, you seem to have a very binary view of tools. We are infact not necessarily pushing a migration message but we are saying you can adopt new technologies while retaining your existing investment…and those with that existing investment will want new features. Given that the “left hand” and the “right hand” are the same people making the decision, we are very aware and we find a message of mixing and matching one that fits well with customers’ needs.

Comment by Grant Ronald — 27 June 2007 #
What I would like to see is a major improvement with regard to user interface for the end user, i.e. a lot more options when it comes to layout and look-and-feel. Today it is possible to create applications that look “OK”, but takes a LOT of work if you want to create something anywhere near “NICE” or “IMPRESSIVE”. Oracle is way behind the .NET world here.

Comment by E. Lykke — 5 September 2007 #
[b]I think Forms 10.1.3 (or even 9.0.5) would have been a better name, but that’s no good marketing I suppose.
Grtz,
Wouter[/b]

I Completely agreed with Wouther

Comment by Faizan Dosani — 15 September 2007 #
Wouter, 10.1.3 and 9.0.5 would not have been good names as those releases of the application server didn't contain Forms - no every release of the application server contains every component.

Comment by Grant Ronald — 17 September 2007 #
Recently our government IT division has made a decision to go back to Forms (10g). We are experineced in both J2EE and Forms/Reports so the decision was lenghty but well informed.

We plan to continue to use java based technologies (not Oracle) with our Oracle databases for web applications used by the public, but there are about 10 as many non-public/in-house applications that are much more complex in terms of business rules that we need to build.

We had to consider the relatively unproductive 3 years we had recently experienced with J2EE on complex applications (we tried JSP, Stuts, JSF, Flex, etc on complex projects, consultants galore). As well we considered the maturity of the product and our very large SQL, PLSQL, and VB6 history. Also there were the everchanging J2EE standards. Our employees had limited capacity to learn the latest complexities of J2EE development without a very large investment. We ruled out .NET since our organization is pro-Java.

We plan to stay with Forms for the next 5 years before evergreening our technology stack. Judging by the first 2 months, where our 2 ex-VB6/Oracle developers completed 2 small but complex applications (clients were very impressed too), it seems to be paying off. This was after 4 weeks of training, and some mentoring. I really hope that Oracle keeps evolving Forms, at whatever rate they choose.

Comment by Steve Wechsler — 5 October 2007 #
FYI - Oracle Forms 11g New Features webinar now available at http://otn.oracle.com/goto/formsmodernize

Comment by Grant — 21 May 2008 #
O sea que al final forms no desaparece, mola

Comment by tomas — 10 September 2008 #
wow! Good job.

Comment by web form — 2 January 2009 #
Time is money? If so, go Forms 10/11g. Other tools are nice to design "pages", but we proved there are not ready to be a replacement for mature high-productivity tools like forms (interesting industry is going from 4GL to 3GL, not 5GL).

I admit I was expecting more enhancements from 11g, like tools to build more atractive "web like forms", better integration with MSOffice and Bi Publisher?.

Dear Oracle, your RDBMS is a good product, but remember Forms was the "why" most companies pay more for your RDBMS...

Comment by Cesar — 22 April 2009 #
I have to agree with Bob T's comment. Having worked on Forms for close to 7-8 years, I am finding it hard searching for new opputunities on Forms.

Additionally, Forms loses out big time in the look and feel interface richness that Windows.Forms in the .NET stable provides. Using Windows.Forms its possible to have a sleek and fully functional thick client (thick purely in user interface features) and push almost all of the database and business functionality to the back end using stored procedures / functions. You can pretty much develop and deploy industrial strength back office data entry modules using a Microsoft Windows.Forms .NET front end mated to an Oracle back-end.

My issue is Oracle seems to lack woefully in the front-end scheme of things. You either have JDeveloper thats powerful and feature rich, but is expensive in terms of training, re-writing existing code and complex, or you have the simplistic APEX or Forms, whose future is very much uncertain, and still doesn't meet the look and feel standards that we expect today from a front-end.

While I appreciate Grant Ronald's attempts at clarifying the situation, it is hard to find Oracle application development professionals who are NOT confused about ORacle's strategic plans with respect to JDeveloper vs Apex vs Forms.

Every Oracle man/woman says these are non-competing technologies and each have their own place, but Oracle's own movements towards JAva/JDeveloper combined with statements of continued committment towards Forms doesn't help clear the confusion.

With Microsoft, at least its clear that there is one product/path you need to adopt. With Oracle, the issue starts at the very outset itself with the choice of which Oracle solution to adopt.

My main grouse is as a professional, I am still unclear on which of these three solutions will still keep me marketable in the Oracle scheme of things, and therefore which product do I invest my time and effort in mastering.

Regards,
Venkat

Comment by Venkat — 23 September 2009 #
We give you loads of features to update the front end of Forms - here is an example of one customer case: check out http://www.oracle.com/technology/products/forms/pdf/capula.pdf

Comment by Grant Ronald — 23 September 2009 #
Hello,

i started replacing now all Oracle Forms based applications with browser-based applications where i need no plugin. We decided to use NetBeans with Woodstock/ICEfaces Components because it's easy to use while JDeveloper is not !
If there would be a nice integration of OC4J into NetBeans IDE(SunOracle what is the problem here ?), that's great, then i continue with Oracle AS(which we need for Forms). But until now i prefer Glassfish.

Comment by Hans-Joerg Alles — 23 September 2009 #
Grant,

That was a nice screen indeed, for a web application - definitely one of the better examples of a client/server app. makeover to a web app.

Can one dispense with the two window title bars, the default menu etc. ??

And you seemed to have missed a subtle point in my original post. Oracle doesn't have a satisfactory traditional Windows based front end offering for developing client/server applictions.

While I understand web-based applications and anything with Java in it are being touted as the next best thing since sliced bread, we need to consider the fact that not all businesses and processes need applications to be web-enabled.

Don't get me wrong. I love Forms. I have spent way too much time on Developer/2000 (Forms/Reports 6) and that too on a single project for over 6 years. I am thoroughly convinced of the product's superiority for database applications. But with the way things are, I am finding it hard to be convinced that Forms has a future. I am also worried about what I am now supposed to do, with respect to adopting the next "new" platform.

That is precisely the reason why I believe Oracle has not done justice to the platform with respect to subsequent development and positioning of the platform and to the scores of professionals who assumed that evolution of Forms would be more in keeping with current trends, while at the same time not entirely abandon the client/server domain.

Regards,
Venkat P.

Comment by Venkat — 23 September 2009 #

Trackback/Pingbacks:

IT-eye Weblog » Oracle Forms 11

[...] Wilfred has written a post on OraTransplant describing oracle’s plans for Oracle Forms version 11: Oracle’s plans for Forms version 11. Some of the improvements he mentions: [...]
OraTransplant » My first presentation at OpenWorld

[...] react to Advanced Queuing events from Forms and the new JavaScript API to Forms 11. In fact, these plans were already announced by Oracle in Jun 2006. Read that article for a more detailed description of [...]
Webmaster Book

Webmaster Book... Do you sincerely want to make a million? Learn how to work smarter, not harder....

Sorry, the comment form is closed at this time.