cancel
Showing results for 
Search instead for 
Did you mean: 

Need clarification regarding "depreciation" of WDA UI-el f for Java Applets

Former Member
0 Kudos

In a recent Scripting Language Forum thread, Thomas (Jung) mentioned that the WDA UI element for running Java applets is being "depreciated".

What does "depreciated" mean exactly?

Will WDA apps that invoke Java applets stop running at some point in the near future?

Or will SAP continue to allow such apps without supporting them in any way whatsoever - i.e. no fixes to WDA, whether free or paid?

Can someone clarify?

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member181923
Active Participant
0 Kudos

closing question to get below 10

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

The construct that you are refering to, the iFrame, is not specific to Java Applets. It is a normal HTML iFrame and allows you to host any content that can be accessed via URL. The main problem with the iFrame is that unlike the islands framework, it has no session handling . That means that the content of the iFrame is potentially reloaded after any server request. We also don't have any mechanism to interact (via events or data) with the content hosted in the iFrame.

So now we have the reasoning for the deprication, now to the meaning. SAP delivered the UI element and then had second thoughts due to the limitations listed above. SAP doesn't want to just remove the UI element as that might potentially break existing applications. On the other hand SAP wants to make it clear that future usage of the iFrame should be avoided. It does mean that SAP MIGHT remove the UI element all together at some future point (SAP's disgression).

former_member181923
Active Participant
0 Kudos

Thanks, Thomas.

I don't mean to belabor the point or take your valuable time unnecessarily, but ...

1) "That means that the content of the iFrame is potentially reloaded after any server request".

Say a user picks something from a WDA tree control and passes the name of this something to the applet running in the iFrame, and then the iFrame applet does its thing based on this name (and maybe a few other parms that are passed along with the name.) Since there is no "server request" in this case, wouldn't this first "limitation" not really apply in this case?

2) "We also don't have any mechanism to interact (via events or data) with the content hosted in the iFrame."

Suppose it's not necessary - suppose you just need a pushbutton to close the iFrame when you're done looking at or manipulating its contents (using only the native controls of the applet running in the iframe). Wouldn't this second "limitation" also not apply in this case ????

Again, sorry to take more of your time - I'm just trying to understand.

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

You are correct. It is possible to build an application where the interaction between the WD and iFrame work correctly. But as described this has to be a fairly simple application from the WD side.

The problem from SAP's standpoint is that it is also really easy to build an application where the interaction with the iFrame doesn't work - usually leading to a support question we are powerless to fix.

By deprecating the UI element we have hopefully made these limitations more visible and we have restricted our own internal developers for using the UI element in our delivered applications.

former_member181923
Active Participant
0 Kudos

Thanks very much again, Thomas.

Your response gives me hope that a "political" solution can be reached here that does not involve pulling any technical "plug" permanently.

By a "political" solution, I mean a solution like that which is already in place for regular ABAP BAdI's and exits - because if you think about it, an iFrame is really like a "user-exit" from WDA.

Customers already know that there is no support for customer code in exits or BAdIs - and no one complains about this.

So the only thing SAP would be responsible for maintaining is the integrity of the outbound interface - the passability of parms to whatever's in the iframe.

Maybe SAP will agree to adopt this attitude toward iFrames - classify them as user exits with SAP's only liability being the integrity of the interface ????

Best regards and thanks again.

djh

former_member181923
Active Participant
0 Kudos

Thomas -

At another site:

http://www.artima.com/forums/flat.jsp?forum=1&thread=235563

someone suggested this work-around:


You could use the ExternalInterface.call("javascriptFunction", arg1, arg2) from the 
Flash object to call Javascript and next setup a javascript function that passes 
the arguments to the Applet object. Works the other way around too with 
Javascript relaying the arguments. 

Is this correct?

Thanks

djh