Adding a custom group of buttons to a menu via Ajax & RPGsp

[kevinh]

We use RPGsp to provide PUI pages their values for dropdowns and even run some RPGsp programs in an iFrame of a PUI page so we are familiar with how RPGsp can be used in conjunction with PUI.

I would like to enhance over a dozen UI menus on our system with a custom/dynamic group of buttons based on user settings. These buttons need the ability to cause the PUI menu program to call a CL/RPG program similar to how clicking a menu option does (we used the standard menu widgets where the choices value is passed back in the Menu Response bound field.) My thought is if I can use an Ajax Container on the UI menu and point it's Ajax URL at a RPGsp program that has the logic for what buttons to include on the resulting page then I could get by with minimal initial changes to the menus and menu programs to get this working then I would only have to maintain the one RPGsp program going forward for what buttons to return to the menus.

The problem I'm having is determining what action needs to take place when one of the buttons (returned by the RPGsp program) is clicked to trigger the PUI menu program to call the respective program.
We can add buttons directly to the PUI menu and add a Response indicator field and check for that in the PUI Menu's RPG program, but that would be a massive amount of programming to place in multiple menu programs.
What I'm looking for is a way that the PUI Menu RPG program could receive a response from the buttons that were added by the Ajax call to the RPGsp program so that the PUI menu program makes the appropriate call based on the button that was clicked.

It's like I need the buttons created by the RPGsp program loaded with the call string that when clicked the PUI Menu program takes that string and calls QCMDEXC passing it the call string, which is what it does when menu options are clicked.

There may be a better way than what I have described but what I'm looking for is a single program to use to provide the PUI menus with buttons (or by other means) that need to trigger a call to a RPG/CL program (that will also be a UI program for displaying in the browser session.)

Thanks in advance!

[David]

PUI applications can only take input from the display file, so you'd need to think about it in terms of display file programming. I think that you would have to make at least some modifications to the menu programs to make this work.

One idea...

You could create an external program or service program that uses a new display file with a simple record format to display the RPGsp content and to receive the values.

The menu programs could call this program/procedure at the time they display their screens. This piece of code overlays its simple record format onto the screen. This record format could have a hidden field or whatever widgets needed to receive the values.

Then, the menu programs could call the external program/procedure again to read the record format to see if it had any input before they check their own record formats. If the external program/procedure returns a command, they could run it like usual, although you'd want to validate this very carefully if you are passing to QCMDEXC to prevent a user from attempting to 'inject' commands into it (certainly possible if you don't watch).

This would minimize the modifications you'd have to make in the menu programs. Using this approach you wouldn't have to put a lot of RPG code into them or modify their display file record formats.

[kevinh]

David,
I'm getting nowhere with getting an external program called from the menu program to overlay its screen format on the same page as the menu. Does this get into designer properties like overlay, assume, and display file compile options such as rstdsp and dfrwrt? If so I've been unable to find the right combination.

If from my menu program I call the external program that just displays a simple UI record format with a button then all I get is the button if doing an exfmt in the external program. Once I click it then I get the menu display being that it returns to the menu program from the external program. Using a write in place of exfmt in the external program never displays my button and the menu display appears like normal. This is where I expected overlay, assume, etc. to come into play.

I'm not a display file guru if you could include some details as to which display file needs the properties for overlaying and assuming and any compile options that should be used. Or maybe I'm totally off track by what you meant by calling an external program that overlays its record format onto the screen.

Thanks again.

[David]

Compile parameters for display files are completely ignored by the OA Handler. It always behaves as if SHARE(*NO) and RSTDSP(*YES) are used.

To get content from two records residing in two different display files on the screen at the same time, you need to set the 'assume' and 'overlay' properties on the format in the 2nd display file. 2nd meaning the 2nd one that you WRITE, which is to overlay the 1st one already on the screen.

Another thing to keep in mind is that PUI actually sends content to the browser on a read, not a write.

This is because an http server cannot do anything with the browser screen until the user submits back. So, the server must wait until user input is required before sending anything out.

You'd want to do something like this to display and then process the screen. It takes 2 calls to the external program.

Code: Select all

// In menu program: 
Write MENUFORMAT; 

// In menu program, call external program to do this: 
Write NEWOVERLAY; // 'assume' and 'overlay' on. 
*InLr = *Off;
Return; // Leave file open. 

// In menu program: 
Read MENUFORMAT; // Now the user has the screen.

// In menu program, call external program to do this: 
Read NEWOVERLAY; // This will not go back to user, but will input from prev. submit. 
*InLr = *On;
Return; // Send some parameter back if something was clicked.

// In menu program:

If Parameter <> '';

  // Got input from external program.

Else;

  // No input from external program, check for input on my own format.

EndIf;

[kevinh]

Almost there!

I triple checked what I have against your code and this is the remaining problem.

The NEWOVERLAY external program does not display it's contents on the menu program screen until the READ NEWOVERLAY occurs on the second call of the external program.

So when I first call my menu program I don't see the overlay from the second program until I click something on my menu program then the overlay from the second program appears overlaying the menu as it should. Clicking any of the overlay's buttons works. Clicking any original menu options causes the first menu option clicked before the overlay appeared to be called.

In other words the READ MENUFORMAT isn't sending the screen format from the WRITE NEWOVERLAY that occurred in the external program (leaving INLR *OFF.)

I tried a few tricks on having a dummy record format in the NEWOVERLAY screen with ASSUME on as well as trying user controlled open of the NEWOVERLAY screen without any good results.

We are running PUI version 4.5.2.

[kevinh]

Bump.
David, Any thoughts or direction on this? Anything you need from me?

[David]

I"m sorry -- I've been meaning to post a working example for you. I thought that code would work as described -- I'm not sure why it wouldn't right off hand. But I will actually put together a working example to make sure I'm giving you the correct technique.

[kevinh]

David,
Any chance of this happening today? I have 3 business days left before a demo where I wanted to show off this functionality to some of our clients.
Thanks.

[David]

Sorry for the delay -- here is a working example.

The MENUTEST1D/MENUTEST1R are the 'original' menu program/display. The MENUTEST2D/MENUTEST2R are the new additional record format that you want to display on the menu programs.

What's different from my previous suggestion is that I found that I had to reverse the order of the READ operations to make it work.

Also, I had to do an extra WRITE on the original to make the function keys active for it -- see the comments in the source.

You can run this by transfering the members to your system and compiling, then launching MENUTEST1R.

You'll see that both record formats get put out to the screen, and the program can process input from both of them with 1 submit back from the user.

Let me know if this helps, or if you have any questions on it.

[kevinh]

David,
It was worth the wait.
Your examples and my test menu and overlay program were very similar. I saw the extra write you added and the read that was moved down in logic, changed my test menu program to match, and it worked first try!
Great example by the way. Looks good enough to add to the PUI Samples page as is.
Thanks for the great work.