This content has been marked as final. Show 6 replies
It might be possible to use java script to pass the value into the form. You likely can do this after the form has started or while it was starting. To pass the value in during the form's start up, you would need to create a Forms parameter and populate its value as part of the startup. Again, it may be possible to populate the value using java script in the ADF page. To pass the value in after the form has started, this may be possible using the new feature in Forms 11 which allows you to communicate via java script to and from the hosting page. Either, idea would likely require a minor code change to the hosting ADF page and the form, but it might be possible.
Without understanding how you have integrated the form into the ADF page makes it difficult to offer specific ideas.
For an alternative option: If you're worried about the two apps running on different ports, you could also run Forms and ADF on the same ports via Oracle HTTP Server (OHS) Reverse Proxy. Its just a few entries in your OHS configuration files and both apps can run on the same port. Forms 11g Installers come with OHS.
We have integrated the forms html code inside a page fragment and have been using it as part of a bounded task flow.
For now we have added a parameter to the env file and are accessing it using TOOLS_ENV.GETVAR in-built. But I was hoping to find a solution wherein the form itself finds a way to know the port it is running on, the way it is possible for a webapp.
Thanks for your inputs nonetheless :-)
Ok, now I am confused. You suggested that the ADF environment/server is not the same as where Forms lives. So, there would be only two (maybe three) ways in which you could "embed" a form (java applet) into a web page. You can either hard code the applet parameters into the hosting page or create something like an IFrame within the page and use the typical url to call it. The third option could be to use java script to actually write the desired html dynamically (I won't get into these details).
In the first option, you would need to fully qualify parameters such as serverURL, archive, etc because the information needed for Forms lives on another server or in a different environment. And in this case, WEB.SHOW_DOCUMENT would also need to be fully qualified (i.e. http://formserver:8888/forms/html/myhelp) again because the hosting page did not come from the same server as the form. The behavior would be exactly the same regardless of whether the call was made by Forms or any other application not originating from the same environment. This is not a "Forms" issue.
In the second option, if you use an iFrame the WEB.SHOW_DOCUMENT call would use the server and port which launched the form in the iFrame. In other words, if the surrounding page (e.g. ADF) was called using http://abc:8888, but the form displayed in the iFrame was called using http://xyz:7777, WEB.SHOW_DOCUMENT calls could successfully use a relative path rather than fully qualified. For example,
In general, WEB.SHOW_DOCUMENT would always use the url responsible for launching it in the first place. This would be true of any html or java app if you provided only a relative path rather than fully qualifying. Keep in mind that Oracle Forms does not perform any magic when calling WEB.SHOW_DOCUMENT. This is merely a call to Java's showDocument method. Here is demo from java:
So I guess what I am saying is that it is unclear as to how you are "embedding" your form into the page and what exactly you are trying to do with WEB.SHOW_DOCUMENT
Mike - the applet parameters are coded inside a page fragment, which is the default view of a bounded task flow. So the applet renders when the task flow is called.
Forms and the ADF webapp are deployed on two separate servers.
So in this case, WEB.SHOW_DOCUMENT will take up the ADF webapp's machine and port.
Again, the Forms runtime has no idea what the web server or application server configuration looks like. So you will have to hard code the desired values somewhere (e.g. in default.env or formsweb.cfg) or extract it from the code in the page.
Also, you keep saying "+... WEB.SHOW_DOCUMENT will take up the ADF webapp's machine and port....+ ". Yes it will if you are only providing a relative path. You need to provide the complete path as you would to run the form in the first place.
Even if the Forms runtime was aware of the port number being used, it would not be the correct one relative to the client. If you are using the product as recommended, you have OHS in front of the WLS managed server hosting Forms. Therefore, the Forms Servlet is operating on port 9001 (by default), but the client requests are coming in on OHS's 8888 (by default).
With that in mind, I had an idea. You could query the managed server from Forms using WLST. However, as I mentioned this would return the WLS port and not OHS. To do this from Forms you likely would need to call a script or generate one dynamically then execute it. For info about getting the server port and other info, refer to the WLS documentation.
For help using WLST, your best bet is to post those questions on the WebLogic forum.