If you spend any time digging around in the JavaScript on PeopleSoft, you will see a lot of functions and other objects with names that end with "_win0." I always wondered why that was, but since it never seemed to change, I just went with it.
Now that we are planning a PeopleTools upgrade to 8.53 (currently 8.49), I started looking at some 8.5x applications to see what upgrade issues I might have with my custom JavaScript. I'm mainly worried about the places where I override delivered JavaScript. I inadvertently discovered that it isn't always "_win0." If you use the "New Window" link that appears on most content pages, you will note that the URI on the new page changes from .../psp/... to .../psp_1/.... If you then look at the code you'll see that "_win0" is now "_win1."
I have yet to figure out why the JavaScript is rewritten this way. I assumed that the JavaScript in one window or tab cannot interfere with the JavaScript in another. Am I wrong? Can anyone help me out here?
Now that we are planning a PeopleTools upgrade to 8.53 (currently 8.49), I started looking at some 8.5x applications to see what upgrade issues I might have with my custom JavaScript. I'm mainly worried about the places where I override delivered JavaScript. I inadvertently discovered that it isn't always "_win0." If you use the "New Window" link that appears on most content pages, you will note that the URI on the new page changes from .../psp/... to .../psp_1/.... If you then look at the code you'll see that "_win0" is now "_win1."
I have yet to figure out why the JavaScript is rewritten this way. I assumed that the JavaScript in one window or tab cannot interfere with the JavaScript in another. Am I wrong? Can anyone help me out here?
By-the-way, I got lucky in my original exploits. A lot of my functionality depended on overriding or proxying delivered function submitAction_win0. This could have broken, but our custom pages did not expose the "New Window" link. I've done some thinking about how to get around this. I took a look at HTML object PT_PAGESCRIPT where much of the basic delivered JavaScript in stored. You can see that code contains replacement variable %FormName. This must get replaced somewhere in the page processing with "winx." I'll do some experimenting with that. Or I may just have to parse the %ContentURI in PeopleCode to determine the window value. I don't think it's exposed anywhere else.
-Keep Digging
If you really want to see the winX functions in action, load up the Manager Dashboard (or any homepage with several component based pagelets). From the browser side you will see each of these components has the winXX hard coded into both function calls and element ID's. If you open something like PT_PAGESCRIPT in App Designer, you will see lots of %FormName Meta-HTML. The idea is to match functions to component instances to avoid submitting the wrong form, processing type ahead on the wrong field, etc. There are other ways to accomplish the same task, but this is what was chosen back in the early days. As you compare JavaScript over PeopleTools releases (from early 8.42 to 8.53), you will notice more code moving into generic scripts like PT_COMMON.
ReplyDeleteThanks Jim - I should have known you would know. Is there any programmatic way to determine what the XX value will be in the page or component PeopleCode?
ReplyDelete