I still don't get THE problem. Why on earth would you want to run the Forms Runtime on Java? This would help us exactly with...what? You do know that the YoForms! guys simply exchange the Forms Applet with a HTML application. The forms runtime would still be the good old frmweb.exe running on the application server whereas the rendering of the GUI would be done in HTML (just like it is now with a java applet).
Christian Erlinger a écrit:
I'm fine, thank you . How are you?
Very fine ! I work now in the south of france for a big company
Thank you all for your replies.
Why do I opened this thread ?
First, this is not another "is form dead?" blah blah thread.
We are frequently asked about our desired features for Forms.
Oracle Partner sponsored survey
Participate in a short online survey about your plans and desires for Oracle Forms
I participate to this survey and I wrote that I desire a FormsFx.
In the past 4-5 years, there was a kind of "lobbying" to promote ADF and migrate Forms to it.
Then APEX has grown and and grown fast. The new upcoming version 5 sounds very promising.
Now Oracle offer us 2 different alternatives to Forms, APEX or ADF as written in the statement
For Oracle Forms or application development requirements that exhibit these characteristics:
• Extensive business rules or UI control logic in the application itself
• Need integration with and access to Fusion Applications or other 3rd party applications
• Need access to features provided by Oracle Fusion Middleware, such as BPM, BIP,
WebCenter, and SOA
• For larger scale deployments where most of the processing time is in the application,
and scalability is achieved by adding multiple middle tiers
• Larger development teams with requirements for complete development lifecycle
• General preference to use Java/JEE technology
Oracle JDeveloper 11g with Oracle ADF is the tool of choice for building applications on Fusion
Middleware. However, given the architectural difference between Java EE and Oracle Forms,
Oracle has no plans to offer a complete migration solution that attempts to automatically migrate
applications built with these tools to Java EE.
For Oracle Forms customers with these characteristics:
• Most of the application logic is database resident PL/SQL
• For larger scale deployments, most of the processing time is in the database, and
scalability is achieved by scaling up the database server
• Small development team with modest development lifecycle support requirements Oracle Statement of Direction Oracle Forms, Oracle Reports and Oracle Designer
• Do not have the skills or do not want to learn Java
Oracle Application Express (APEX) may provide a fit as it leverages PL/SQL for business logic
scripting, and offers a productive environment for simple HTML forms.
Why did the adoption of ADF as an alternative to forms failed (in my point of view of course) ?
Probably because of most of the applications written in forms meets the second part "Most of the application logic is database resident PL/SQL and Do not have the skills or do not want to learn Java".
So now that Oracle has acquired Java, why not offer us a 3rd alternative, just stay with Forms but rebuild with JavaFx ?
For me it will be the best RAD ever seen !
It is perhaps too short for oracle for the 13 version but please, Oracle, consider it for Forms14Fx
So i renamed the thread
Ce message a été modifié par : JeanYves Bernier
I have been following this thread for several days and wanted to see where it would go. I must say.... very interesting.
From my side, I want to say "thank you" to everyone that has been a loyal user of Oracle Forms over the years. I also want to thank all that participated in recent and past surveys. Although it may not always seem that we are listening, we are. All suggestions are reviewed and considered. That said, there are many reason why a feature may or may not be implemented. One very important consideration is understanding how providing this new feature will impact existing applications and will it prevent them from being able to upgrade without having to change their code. Because we know we have more existing users than we do new ones coming in, ensuring that we don't break your current applications- is one of our biggest concerns. Just like there is no direct migration path from Forms to ADF, we want to ensure that we do not create the same problem going from Forms version A to version B.
Regarding JFX, this is something coincidentally being investigated. As you noted, it would be mostly impossible for us to provide such a drastic change in the next release and probably even the following one. But at any rate, we are looking at it as a possibility. In the shorter term, we are considering blending technologies. If technically possible, we would plan to adopt a few new features that are JFX based while retaining everything else currently in the product. Likely we would start with features that would not require UI components. For example audio support.
Our current plan is that we will continue to welcome and consider any reasonable feature requests. If we determine that we can safely implement a requested feature while still considering what I mentioned above, then we will do our best to include that feature in a future release. For the next release, we are hoping to see over two dozen new features and enhancements. These will likely be a mix of "fine tuning" features as well as more significant features. Although the next release may not be what you are dreaming for v14, hopefully it will offer you and our other loyal followers reason to upgrade and put some life into their applications.
For those of you still running versions older than v11, I encourage you to upgrade. Being on the current version will make upgrading to the latest simpler when it becomes available. The further in versions you are away from the current version the more difficult it will be to accomplish.
Hopefully, I will soon be able to share some details about what new features are being planned. My expectation is that over the next few months, I will be sharing bits of information leading to the eventual release. So, stay tuned if you want the very latest. Be sure to monitor the Oracle Forms page on OTN and follow me on Twitter: @OracleFormsPM
I forgot to mention, we are working closely with Oracle Partner, AuraPlayer. AuraPlayer offers a simple way to expose Oracle Forms application's business logic as web services. These web services can be easily used to develop mobile application. One great thing about this product is that you do not need to make any changes to your Forms application in order to expose the web services and create a mobile application.
In the next few weeks I will be co-presenting with AuraPlayer to present various web session as well as co-presenting at this year's ODTUG with them. I encourage you to be on the look out for those session. And, if you are attending this year's ODTUG (aka KScope14), please be sure to visit our session and stop by and say "hello".
Message was edited by: Michael Ferrante (Oracle)
What is wrong with adf you asked? I heard it through the grapevine here that people that committed to use adf here had performance issues so they dumped it and went to using various other traditional servlet based things such as spring framework etc.
I think it also puts a lot of people off that they have to know java and know it well to do adf. If you have to do web apps and you don't know java there are a million other technologies some of which are quite higher level languages than java.
Adf doesn't make any sense unless one is schooled in classic mvc servlet practices. The mvc thing was in my opinion an artifact of the development of servlets with collect info,send post, display results web application paradigm.
Web applications are inherently annoying with delayed error checking, have a great security burden for the developers and have various points of failure that don't exist in client server/console type programs. This is the thing that is so good about applets in my opinion,
the good performance (a bit sluggish to start but then performance is super) and it is not plagued by that stateless web application stuff. It runs like client server. You can have a truly gigantic sized form in forms and it runs very well. That is a big plus for
folks that deal in big forms. Another plus with forms is being able to handle known keys (vs generated keys). I don't know if adf does known keys. Definitely apex did not do known keys the last I checked. If you like non-generated keys, forms is a good choice.
I don't see why people feel that plsql is the problem in forms. Forms depends on the jre and it's the jre that is not present even in android running on dalvik. Jre is not in ios based devices either. It's not the lack of "pvm" that is the issue.
There's a lot of interesting pie in the sky ideas here:
wikipedia claims a port of jfx to ios and android:
For me, Would be sufficient in 12c: Forms rendering ( any screen resolution) and a better management (out of box) of Blobs and datetime columns. I'd be happy!
I will assume that by "rendering any screen resolution", you mean that you want objects to resize if the window is resized. Unfortunately that isn't likely to happen. You can code such behavior on your own, but it is unlikely this feature will be presented in the next (or possibly any) version. Remember that the Forms product is going to create a desktop-like application and not an html based web application. Although in desktop applications fields do resize as the parent window changes, that behavior most often is coded by the person that developed it. However, in web (html) application such behavior is native to the browser. Forms does not run in a browser. It is "launched" from a browser, but runs in the Java Runtime Environment.
Regarding blobs, what do you mean "better management"? Keep in mind we need to limit the amount of data being sent to the client. If we were to send 4gig of data to the client tier, the application could potentially sit with an hour glass for a long time. This would not be good behavior. Working with LOBs in Forms needs to be done very carefully. In the current version (18.104.22.168) we extended, albeit only slightly, the limit in size for text fields from 32k to 64k. Extending beyond this likely will adversely impact performance and the user experience.
Finally, datetime. Again, what did you have in mind here? Would supporting the "TIMESTAMP" datatype help?
If I may, but Java has several Layout Managers which are capable of resizing / repositioning components when their parent component is resized. They are sometimes a bit stubborn I have to admit, but fitting to any screen resolution in a plain java application is not impossible and also not too uncommon with a reasonable amount of coding (without having to invent the wheel every time). I haven't looked deep at JavaFX, but obviously there would be even the possibility to use CSS to do the layout of an application:
As screen sizes and resolutions seem to double every two or three years it's especially tiresome to have a forms application with a small window on a big screen where I have to scroll around to get to all items or fitting them on 27 tab pages even though my screen resolution would support showing all of them (but you'll have to design the form for the smallest supported resolution)...clientDPI only partially solves the problem, as I certainly don't want to have fat text boxes but simply...more text boxes on my screen.
Of course as far as designing such a form with a not-null Layout from the forms builder goes this certainly would require a complete rewrite of the layout designer, as you can bid the idea of putting items on a canvas and expecting them to stay where they are farewell. I'm not saying that I would be especially miss the layout designer, but...I guess if I'd have to choose between a new layout designer and a *search backward button in the PL/SQL editor* I'd go with the backward search...
Thank you Michael four your hopeful responses !
I registered for the The Evolution of Oracle Forms: The Results Webinar | AuraPlayer - Oracle Forms Solutions.
And even if I'm not a twitter fan (I prefer to focus on my daily work and increase my knowledge rather then spending 60 to 65% of my time on my smartphone like some of my colleagues do ) , I reactivated my account @ic4it and I'm now following you.
Can't wait for April the 25th.
Thank you Michael and you Christian,
Yes, for the first question is that Christian talk about too. Francois Developed a something
The second, Blob, I speaking for example, to store PDF output in Blob table (yes I can use Pluggable Destinations with Reports Server ot Pl/sql code DBMS_LOB), but I do not think it's the same thing as out of box, insert-read adn show file image or pdf or others.
Finally, yes I am in last version (Oracle Forms and Reports 11g Release 2(22.214.171.124.0)) , happy for spaces in dir, but I don't believe that datatime datatype are very well managed between Forms and PL/sql stored / function.
Too bad, because I think that still Forms and Reports (or Bi-Pubblisher) are among the best (in development time and integration with Db) development tools in circulation.
Thanks again for your time.
Michael Ferrante (Oracle) a écrit:
One very important consideration is understanding how providing this new feature will impact existing applications and will it prevent them from being able to upgrade without having to change their code. Because we know we have more existing users than we do new ones coming in, ensuring that we don't break your current applications- is one of our biggest concerns. Just like there is no direct migration path from Forms to ADF, we want to ensure that we do not create the same problem going from Forms version A to version B.
Of course the goal is not to brake any existing Forms application.
But I made several migrations in my career, from 4.5/6i to 10g and we used the forms migration assistant (based on JDAPI), that provided us what parts of code were to change.
What Does the Oracle Forms Migration Assistant Do?
The Oracle Forms Migration Assistant updates obsolete usage in your PL/SQL code in order to migrate your Forms 6i applications to Oracle Forms.
The tool issues warnings when it cannot make the required changes automatically.
This tool has a command line and a wizard version.
The Oracle Forms Migration Assistant does the following for all Forms module types (including object libraries and PL/SQL libraries):
Updates PL/SQL code where possible, for example:Updates RUN_PRODUCT to the RUN_REPORT_OBJECT Built-in when used to call Reports.
Updates CHANGE_ALERT_MESSAGE to the SET_ALERT_PROPERTY Built-in.
Provides a list of obsolete code usage, including code that the tool cannot change when there is not a straight-forward equivalent for migration, for example:
Provides warnings when specific obsolete Built-ins are used at runtime, such as ITEM_ENABLED.
As Christian pointed, I guess this has certainly something to deal with PJC's, but a new Forms Migration Assistant could be able to check the use of PJC in a form ? Am I totally wrong ?
And if Fomrs is not dead, probably Reports has, as we say in France "un pied dans la tombe" - "one foot in the grave"...
Oracle provides well document migration steps from Reports to BI :
Step by Step, year after year, I want to believe that my dream become reality..
As there is no hard reference to the used Java Classes I guess the only thing the Forms Migration Assistant could do is point out the PJC Java Classes used in an Application.
However; in order to make use of Pluggable Java Components one has to extend the Java Classes used by the Forms Applet (VTextField, VTextArea,...). So what Oracle would need to do in order not to break existing code is what any decent provider of a Class Library would need to do when they add new Features or do changes to their Class Library (don't delete methods even though they are not used or actively extended any more and so on, and maybe release a javadoc on it...).
For me as a user of the Oracle Forms Class Library I couldn't care less if there is Java AWT, Java Swing, Oracle EWT, Eclipse SWT or JavaFX used behind the scenes.
In reality of course it's not always that easy, as all these librarys do behave differently and it's not always possible to rebuild the exact behaviour of one library with another, but at least the need to rewrite PJCs can be kept at an absolute minimum. And in the past we often had to do some code changes when upgrading to another version (run_product or get_file_name for example), so this might be such a thing.
Well we want and require the ability to position things exactly and have them "stay there". We do a lot of data entry forms from paper copy. So the form on the screen has to look like the paper copy. The more it does, the less errors are made. So I hope the option is retained to keep relatively exact locations on the screen. (Like the universe the characters could expand/or contract and the space between them could expand or contract with the resolution/window size changing. But from afar it would look like the same layout.)
We really need to be able to print from forms. Users like printing. They all have a printer.
Don't worry - as Michael said the Layout feature isn't going to be implemented and my response is merely a how-I-would-implement-it or rather a it's-not-impossible-to-implement-it
Thank you for all your posts, that brings a more technical point of view for what is doable for my dream.
I hope this is not only my dream, but also the dream for all of us, loyal forms developers.
The dream to have a brand new forms developer that will be the best RAD (in development time and integration with Db as Rosario said)
Thank you also to all contributors of this thread (Zlatko, Lake, Rosario,user12155310,dsscott and Michael), that will reach soon almost 1000 views.