Re: Impressions of EGL - Part Duex -- WEB400

Nathan Andelin wrote:

In the example of the radio group, I embedded the style and JavaScript elements in the page so folks could understand my thought process, and so we could compare with an EGL equivalent. Perhaps Joe will step in and create an EGL equivalent, since it's pretty trivial, and he was the first to mention how easy it is to handle radio groups in EGL.

I agree that your example is trivial, because you've hardcoded everything in the HTML page, from image names to the number and names of the buttons. The harder part would be to hook it up to a back end. That's what EGL does so easily. Consider the following code. It does what your code does: it changes the image based on a radio button. However, mine does it using a round trip to the server where I could invoke business logic, which is what goes from trivial to a business application.

http://66.80.39.69:9081/GettinWebbie/Test.faces

Here's the entire body of the JSP. This includes the graphic image, the radio button, and the ajax request which returns the clicked value to the EGL program.

<f:view>
<body><hx:scriptCollector id="scriptCollector1"
preRender="#{Test._preRender}" postRender="#{Test._postRender}">
<h:form id="form1" styleClass="form">
<h:panelGroup id="MainPanel">
<h:graphicImage id="image1" styleClass="graphicImage"
value="#{Test.imageUrl}" binding="#{Test.imageUrl_Ref}">
</h:graphicImage>
<h:selectOneRadio disabledClass="selectOneRadio_Disabled"
enabledClass="selectOneRadio_Enabled" id="myPet"
styleClass="selectOneRadio" value="#{Test.myPet}">
<f:selectItems value="#{selectitems.Test.pets.pets.toArray}" />
<hx:behavior event="onclick" behaviorAction="get"
targetAction="MainPanel" />
</h:selectOneRadio>
</h:panelGroup>
</h:form>
<hx:ajaxRefreshRequest id="ajax1" target="MainPanel" params="myPet"/>
</hx:scriptCollector></body>
</f:view>

This is the EGL program. The *entire* EGL program.

package jsfhandlers;

handler Test type JSFHandler
{onPrerenderFunction = onPrerender,
view = "Test.jsp"}

imageUrl string;
myPet string;
pets string[] = new String[] { "dog", "cat", "bird", "iguana"};
function onPrerender()
myPet = J2EELib.getQueryParameter("myPet");
if (myPet == "") myPet = "dog"; end
// Business logic goes here to format the appropriate URL
imageUrl = "http://www.radile.com/rdweb/temp/"; :: myPet :: ".jpg";
end
end

It retrieves the selected value, and if none is selected defaults to "dog". It updates the URL based on the select value. This is the point where you call an RPG program. Please show us what it would take to add the Ajax request to talk to an RPG-CGI program. Show us the changes to the HTML to support RPG-CGI. Return the URL from the RPG program; don't hardcode it in the HTML (this simulates returning the image name from a database file, which is what a business application would do).

(Took me about 20 minutes.)

Then we can compare.

I inserted a radio group on the page using point and click methods, and filled in the property sheet prompts for button labels and values.

I did the same thing, except I was able to specify an array for the value - an array that is dynamically filled at construction time, but which could be changed at runtime. All I would have to do to add a new value would be to change the array and add a new image - I wouldn't have to change the JSP page at all. Yours would take considerably more work, since you'd have to add a whole new class.

That's why business applications don't hardcode things like URLs in the HTML.

The idea of a visual image of a Dog, Cat, Bird, and Iquana struck me, to emphasize the choice. Then came the idea of placing the four radio buttons on each corner of a box, with an image in the middle.

I didn't put mine in the middle. I put mine on top. Now, since I was working on both the EGL and the JSP at the same time, it was easy to add a string variable for the image URL and bind it directly at to the image. I added an Ajax request that returned the selected value from the radio group, used that to format the new URL (this simulated business logic), and I was done. What would it take for you to actually format the URL in your server program and pass it to the HTML?

I inserted the table using point and click methods, then switched to code view and cut and pasted the radio buttons into table cells and played with the formatting, a little.

From that point on, I worked in code view. Dreamweaver supports writing HTML and style elements via intellisense prompting, and supports JavaScript with automatic code coloring. On-line help is packaged.

I normally prototype an application fairly completely with HTML, style, and JavaScript elements. Then later write server code for DB I/O and UI support.

For comparison purposes, I think it would be good to store the user's radio button choice in a table and show the stored choice when the page is initially requested. And update the database when a new choice is selected. And display an applicable completion message. Ajax could help with this.

To stress test the server request & response cycle we could press and hold down an arrow key to select each button and fire the onClick event VERY rapidly in succession.

We compare UI code, server code, development approach, and performance. Sound good?

Before you go mucking about with more JavaScript, how about doing the basic back end stuff (which is what EGL really gives you). I'm already done with all that. I already have a back end program, and a call to RPG to add true business logic becomes trivial for me. Why don't you finish your example and let us see it. Just do what I've done: when the user clicks on a value, go to an RPG program and change the URL based on the selection. Show us the code that allows your server program to detect the radio button selected and then change the URL. No hardcoded URLs in the HTML allowed.

In fact, how about no hardcoded radio button names either? Send that from an array.

Joe