This content has been marked as final. Show 11 replies
Neil, I look after Forms and ADF PM teams so might be a in a position to shine some light on this.
If you want to embed a Forms inside a JSF page you can do it today simply by adding your Forms applet tags into browser page and have the jsp page in the same browser (maybe using a different frame) - the challenge is if you want to do any communication between the two. In Forms 11g we added the JS API which will make this easier however OraFormsFaces does a load of "out of the box" things which mean you don't have to code that into your solution.
The big question I would ask is why? followed by "what are you looking to achieve". Yes you can mash up UIs like this but remember they are still completely separate applications with their own database connection and sessions - so the solution is not without its drawbacks....
I don't know what information you were fed before, there is no standard component in 11g and there are no plans to offer this. 11g has a more "standard" API then you would have had to hack around in 10g - maybe that was what was meant/understood??.
HOpe that helps
Edited by: Grant Ronald on Jul 29, 2011 11:16 AM
Grant, thanks for replying.
As to the 'why' and 'what are we trying to achieve', we have a large application consisting of over a 1000 ORACLE forms and are looking to initially migrate / revamp the Sales order processing module to use ORACLE ADF. The intention is to convert the 'most commonly' used SOP screens and then over time gradually migrate the remaining 'less used' SOP screens, but obviously whilst this migration process was taking place we would still need to within the newly created ORACLE ADF app invoke the 'less used' SOP ORACLE FORM's.
Unfortunately, the impression that we were given was that if we upgraded to ORACLE 11G we would be able to 'seemlessly' interact with our core ORACLE Forms application, in fact the impression given was that a 3rd party tool had been purchased by ORACLE that would enable us to do this, from what you are saying the 'reality' is far from that.
All I'm trying to do at the moment is establish the facts and find a way forward that would enable us to achieve the above of gradually migrating / revamping our ORACLE forms application but still have the ability of being able to invoke those unconverted ORACLE Forms from within the ADF APP.
Edited by: 873993 on 29-Jul-2011 04:56
Edited by: 873993 on 29-Jul-2011 04:57
Hi Neil, well, how seamless is seamless? You can launch Forms from ADF pages and visa versa and as I said you can integrate some functionality on the same page but visually you are never going to mistake Forms for an ADF Faces UI. What you could do is evolve core business logic into a common layer (e.g. database or services) and call them from Forms and ADF applications - that would be slightly more seamless to the end user at least. Alternatively you consider a "fire and forget" approach when you can launch Forms from an ADF Application but you don't try to consider these as any way integrated, simply you launch it and thats its.
You are right in considering a gradual evolution although (and I don't want to open a whole debate here) possiblya new green field ADF development in stand alone business functions would be, IMO, the preferable option if you can because while you have Forms and ADF working side by side and you want a seamless integration then you POSSIBLY run the risk of trying to compromise your new development to make it fit in with you old development...anyway, thats just a heads up and slightly off topic - your approach may still be the right one.
I know of no tool in this area (and I should know if there is one) which integrates or migrates Forms in/to ADF.
Interested to hear how you get on so feel free to ping me on email as well.
Thanks for the links, I think I might have actually stumbled across these pages before but will re-review them.
When I stated 'seamless' it really has to be just that, seamless and more importantly user friendly.
However if I may, I would like to just summarize the various drawbacks that have been identified, feel free to add any additional points(or remove) that we should be aware of if we tried to combine both technologies:-
1) Invocation of the each embedded applet could be time consuming
2) Each applet fired up would require an additional DB connection
3) Two way communication although possible would require a considerable amount of effort to code?
Also, I'm not quite sure I understand your point regarding 'evolving core business logic' it sounds it has the potential to be an extremely time consuming exercise?
As I noted before, when you seamless, if you mean the user will be unaware that he has switched from a Forms app to an ADF app then I think he will notice - some clever integration of things like JS maps and Graphs might be seamless but a complete ADF app would be obvious to a user. Physically the Forms widgets are a different technology to ADF Faces - you can get the colors the same, you can event get the widgets the same size but it will pretty much be impossible to get the same because you are not comparing apples and apples.
Regarding your questions
1) Do you mean the time it takes to start up the applet? Possible longer than ADF but not necessarily
2) Each form runtime process will have its own database connection and each user has his own applet.
3) "Considerable" is subjective - it will involve some work but we specifically built the JS api to help
Your last point - are you refering to "evolve core business logic into a common layer" what I mean here is that if you have a business process (e.g. hire_employee) which involves creating a new record,ordering a laptop and getting a security pass - then you could take that code out of Forms and put it somewhere else. You could then call that code from Forms (your old apps that you still need) and also call it from your new apps (so calll that code rather than calling the Forms application to do the job). - Of course, there is effort involved there...
One final point to make ADF is NOT Forms - its not the "new" Forms and it doesn't replace Forms - so any change between Forms and ADF is by no means "go to the next version" - they are different technologies with different sweet spots - moving one to the other will be a considerable effort, and I would say one which should also accompany business process changes (if possible) as well..
Hope this helps
Hi Grant, no we were not looking to try and convince the user that the app was written entirely using ADF, the end user is aware that we will be mixing the two technologies (timescales don't allow us to convert the entire SOP area).
The term seamless was meant to represent the interaction between the two technologies in that it should not be cumbersome or unwieldy OR for that matter take longer to move between screens than it would already take in their existing application, the last point I think is a note for concern.
Regarding the 'common layer' I understand now, we are already looking to migrate both the .pll and any embedded PL/SQL from within the form to the database so that in theory, as you have stated, it could then be used either by the form or the ADF application (well I'm hoping that's what you meant!).
Point noted regarding ADF not being the new forms, but I'm really not sure if there is any alternative if you wish to 'update' your application and make use of the latest widgets......
"but I'm really not sure if there is any alternative if you wish to 'update' your application and make use of the latest widgets......"
well in a way that was what we aimed at with Forms PJCs, Java Beans and JS integration : the ability to update the Forms UI widgets - anyway, possibly off topic now.
I am reusing the topic, for some technical questions.
I have tried to use oraformfaces for use forms in adf. Now I am looking how to use adf in forms. In older posts you write
You can launch Forms from ADF pages and visa versa and as I said you can integrate some functionality on the same page but visually you are never going to mistake Forms for an ADF Faces UI.I am interested in this "visa versa". Can you give me some advice or link for do this?
It is possible to use one user login for both application? So the user does not need to type twice the username an password. I found a lot of post of how to integrate but never find a Yes or No.