Hey folks,

It's been a few months since I've been able to do some serious WebFOCUS work. A few weeks ago I started on a project for a customer of ours that forecasts vehicle parts consumption rates and monetizes the opportunity. It's a pretty cool project and I've been having a lot of fun with it. That is, until it came time to build the HTML Launch Page. Working in HTML Composer the last few days has been one big fun-sucker!

My procedure works very well. I just discovered the use of -PROMPT and I'm using them to capture some user selections and put them in a variable for a SQL Stored Procedure. If it weren't for the fact that I have no control over the layout of the auto-prompt screen and that it won't allow me to chain controls I'd almost consider delivering the application from the fex file rather than build a launch page. But, alas, I need one. Not only to control the layout but to put instructions, copyright info, logo, etc. all in a nice package.

I really thought doing a lot of the work in the fex was going to save me some headaches in HTML Composer. I put in -DEFAULT values for my parameters, took care of translating the 'this' OR 'that' format into 'this','that' so my stored procedure would be happy. I don't know javascript very well so this keeps me from having to write some in my launch page. Plus, I'm to the point where the less I need to do in HTML Composer the better.

Here's what I don't quite understand. When you add a report to your launch page (I usually reference and external procedure) the composer 'reads' the procedure and identifies parameters for which you may want controls. That's cool right? That's going to save me a bunch of work adding them separately. Plus, now I can tell the tool which ones to chain together right there in the dialog box. Select one of the cool new styles and, bada-bing, I have a launch page.
Except I have a problem. None of the chaining is working. When I look at the settings in the GUI everything looks exactly as it should but something isn't right.
This is where it gets troublesome for me because I really don't have a good grasp on the code inside a launch page like I do inside a WebFOCUS procedure. I can't just look at the code and determine where the problem is so I need to do some troubleshooting.
To make a long story even longer, I ultimately built a launch page with all the controls I needed, put in the procedures to populate the controls and chained them together. It all worked beautifully. Not very useful though because there is no report procedure associated with the launch page yet. So, I add a button and set the hyperlink for the button to run my report. The nice HTML Composer offers to add all the controls for me like before but I say, "Nay nay. I just built all my controls from scratch and they work quite well thank you." So, the nice HTML Composer just adds the hyperlink to my button. Now all I need to do is bind my controls to the appropriate report parameters and I'm good to go, right?
No, as soon as I bind a control to a report parameter the nice HTML Composer 'reads' my procedure again and basically says, "All that work you just did setting up the controls? What were you thinking? Here let me..." And just like that it's all broken again!!!

Seriously, there has to be a better way.

I get it that the GUI won't be able to present everything that's in the code but it at least needs to display what it can in an accurate manner. If I delete a control I expect the code for the control to go away. When I re-add the control (which is really a completely new control that I'm programming to do the same thing as the previous one) I should not see remnants of the settings for the previous control mysteriously appear!!

I know there are some of you out there that code your launch pages in the text editor. I'm tempted to try to learn how to do that. Any tips?

Thanks for letting me rant. I feel better already!

Cheers!

Dan

Yeah,

the HTML composer is a real B!*ch...

You have to follow the rules.
If you have a clean procedure with clear parameters it actually workable.

I never use chaining except for some testing just to see how that work. But I did the chaining afterwards. ( So when asked to add parameters.. yes... chain? no ).

And don't even try to look in the code. There is WAY to much going on there. A lot of things are stored just to support the composer which is not used when running the html.

And the 'garbage' is bad. A lot is left-behind when deleting or chancing anything.

Best practice. Start all over again, just to get rid of the junk.

I hope WF8 has a better one...

Dan, i don't know 77 but here's how i work in 76, when i start, the procedure that i'm going to call is a dummy fex. it has just the very few variables i'm going to need for the controls.
once i get the launch page working, i open in IN TEXT EDITOR and change the fexname....or just use a fexname like 'project_container.fex'
and then change the project_container.fex to -include my real one.
and then NEVER open it again in composer. never

It is disappointing. It seems like you can setup the html page with controls populated and everything. Then, if you try to reference a report, even if you select the same form and select existing controls and uncheck the create new control check box, it still wipes out the control. I always create the procedures to be executed first, and then the htm page. However, if a variable is changed or sometimes even when the control changes, the control has to be set up again. Very frustrating. Especially in my post about moving things from the MRE to the Data Servers section of Dev Studio.

The control clearing happens regardless of the chaining. I created two simple drop downs not related in a new htm file. Then I pointed the form to the fex I was going to run which had simple amper variables. I unchecked the create controls for all parameters and I pointed the variables to the existing controls. Guess what... it still wiped them out even though I was just assigning them. Same thing happened when I didn't reference or create the controls at all and switched to the parameters tab to connect variable to control.

As a developer, I am spending more time recreating than actually developing it seems like.

This message has been edited. Last edited by: J,

Dan, "beat HTML Composer into submission" - unfortunately impossible - it has beaten me to the ground.

I'm sure many developers have gone through what you have - I have many times.

Don't you dare look at the code! The only code you should look at is the JavaScript you add - don't look at all that proprietary HTML code and the multiple entries for a single control and the left over code for a control that was removed. Don't you dare convert a double-list control to a drop-down and then attempt to convert it back to a double-list: can't happen.

It's really unfortunate, but I have no pointers for you - I feel you and I have found the predictable problems with HTML Composer, but many unpredictable things occur as well.

Very sad making.

J, "As a developer, I am spending more time recreating than actually developing" - absolutely correct. If you're a work-term student and have never developed an HTML form, you'd be tickled pink with your results after pointing and clicking away at HTML Composer. If you're a developer with some experience, it's quite annoying, because you have expectations of an HTML development tool, but are left wanting.

Scan the forum, you'll see many complaints about HTML Composer, or "HTML Composter" as it has been dubbed.

I'm hoping for a miraculous transformation in version 8.

This message has been edited. Last edited by: Francis Mariani,

You have my vote on the title alone.

- ABT

quote:

. . . . and then NEVER open it again in composer. never

- Agreed! (Although, I've been known to make a copy, then open a page, make a small change, and then compare the two files to see what happened.

I have probably had the best success, when breaking new ground, by starting with a working page built in the HTML Composer, and modifying it a step at a time until I get it where I want it. If I delete something and the page stops working, then I know I can't do that!

More practically, though, after a lot of trial and error, I've developed template pages that I use so that I rarely have to start back at the beginning with an HTML Composer page. I build my pages with floating controls using CSS which eliminates a huge amount of work re-sizing and lining up controls, etc., while making the code a great deal cleaner and easier to read.

I've also written a small collection of JavaScript functions that do different things (like setting the focus to the first control on page load). These are all stored in a .js file that I link to every page I build.

On the JavaScript topic, I did have to spend a fair bit of time combing through the IBI JavaScript files, sometimes making copies and adding alert statements to figure out how the original worked so that I could figure out how to hijack/modify/replace the default functionality. I'm still waiting to see what a major upgrade does to all my customized JavaScript, but I've written everything with an upgrade in mind so that when certain functions have to be re-written it can hopefully be done in a transparent manner.

When it comes to chaining, I do basic chaining in the text editor just like HTML Composer would do it if it worked, but for more complicated scenarios I use some of my own JavaScript to make it happen the way I want it to.

If you build and test your pages in FireFox, they can probably be made to work correctly in all the other browsers with very little extra effort once you get over some initial issues (Not being an expert with CSS, I did have quite a time getting my initial CSS written to work with all the current versions of all the major browsers. Since then, however, I've had very few issues). This thing of supporting only one or two browsers is nonsense in my opinion. . .

You're ahead of us on the upgrade curve, so I'm not sure how much help I can be with details. . .

Rob

Interesting ideas...

Perhaps it's not so hard to completely bypass the IBI code and generate the required javascript and metadata by hand as I initially thought.

I'm tempted to experiment with writing a small javascript library that interprets some simple XML inside form tags to handle embedded TABLE FILE's and some simple chaining descriptors; something like this:

<label for="listbox1">Foo:</label>
<select id="listbox1" name="foo">
  <wf:control>
    <wf:table>
      TABLE FILE foo
      SUM FST.foo
      BY baz
    </wf:table>
  </wf:control>
</select>

<label for="listbox2">Bar:</label>
<select id="listbox2" name="bar">
  <wf:control>
    <wf:parameter name="foo" ref="listbox1" default="FOC_NONE"/><!-- use the selection in 'foo' as input parameter -->
    <wf:table>
      TABLE FILE bar
      SUM FST.bar
      BY foo
      WHERE foo EQ &foo;
    </wf:table>
  </wf:control>
</select>

That doesn't look like it'd be very difficult to do at all, especially not with JQuery or similar libraries. Plus, it allows us to handle more complicated embedded FOCUS code or different sorting, etc, done at the WF server (instead of sorting in the browser!). It could even support option-groups! Bye bye HTML Composter

Thanks for the input everybody. I find it interesting that there are two schools of thought. One school says build the basics then go into the code and NEVER open it in HTML Composer. The other school says NEVER look at the code.

How can we convince IBI that this is a big enough deal that it must be addressed? I'm on the Advisory Council and I'll start by posting something on their forum that points back to these discussions.

If you have other ideas let me know.

Let's see what happens...

Dan

'NEVER' looking at the code is just silly. If you want to be good, open the code and learn something.

HTML Composer is intended for the same purpose as any other tool - to shield the user from complexity. If you are a sophisticated user, then tools are not for you. It is perfectly acceptable to use a tool to create a skeleton and then hand edit it, but then don't attempt to go back into the tool since what you did manually may not be handled the way you want. In fact in Release 8 a warning message will display if you try to open a manually modified HTML file in the tool. Additionally, you should not attempt to reverse engineer our JavaScript files since they are our source code and we can change them at any time. If you attempt to use them on your own, your pages may no longer function as you want. Our JavaScript goes along with our frontend tool abilities. Tools should be used for their intended purpose. It is when you try to stretch that, problems occur.

Wep5622, Your markup looks lots easier to maintain for the long haul. Are the "wf:" tags you are referencing

<wf:control>[/CODE} something that you've created to illustrate a concept or is this markup part of IBI's product offering and I just don't know about it?

[CODE]
<label for="listbox1">Foo:</label>
<select id="listbox1" name="foo">
  <wf:control>
    <wf:table>
      TABLE FILE foo
      SUM FST.foo
      BY baz
    </wf:table>
  </wf:control>
</select>

-James

Yeah, that's something I created to illustrate what I meant.

I think one of the main complaints about the generated code is that it is far more complex and far more difficult to grasp than seems necessary, while on the other hand the capabilities of embedded procedures are rather limited (because the RemoteValues servlet that gets called to execute the embedded procedure requires XML-input instead of the actual FOCUS code).

In WebFOCUS 8 you are not allowed to modify the HTML code in the HTML Composer. If you change the code then a message will come up when opening the code in the HTML Composer that the HTML code was modified and is not supportable. So you can view the HTML tags in the text editor but if you modify the code beware. Writting JavaScript code to change properties on the HTML tags at run time is okay.

Build a procedure that has all the parameters needed for the HTML page and insert the procedure in a new HTML page as a report or using a hyperlink and allow the tool to create the controls for you. You will have a much better experience doing it that way. Let the HTML Composer Tool do the initial work and then you can modify the HTM page in the GUI or with the JavaScript code.

quote:

Originally posted by David Glick:
HTML Composer is intended for the same purpose as any other tool - to shield the user from complexity. If you are a sophisticated user, then tools are not for you. It is perfectly acceptable to use a tool to create a skeleton and then hand edit it, but then don't attempt to go back into the tool since what you did manually may not be handled the way you want.

David - that is exactly the way I would like it to be. The only reason I've been going into the code is because working in the GUI sometimes breaks my functionality. I'd much rather stay out of the code all together. For example, let's say I change the function of a chained listbox by going from a static list of items to a dynamic list. I would expect that, as long as the Resolves Parameter value stays the same the chaining would still work. Not so. I've had many instances where changing something in the GUI causes it to break. Therefore I have resorted to copying the code from a working version, making my changes in the GUI, and then merging those changes into the previously working code so it still works.
This is obviously not a best practice!
I can only conclude one of two things from my experience: 1) the GUI doesn't work right or 2) I need to be re-educated on how to effectively use the GUI.
I'll even give the tool the benefit of the doubt so, please, have someone create some best practices documentation on the HTML Composer. You could title it "How to develop a launch page in HTML Composer without needing therapy". I'll buy the first copy hot off the press!

Dan,

The example you state, static values versus dynamic values in chaining is a good one. They are very different. With static values and chaining, you need to map the values from the first control to what value they should display in the next control. This is done by creating a condition for each value. For example, if I select ENGLAND as my COUNTRY, then show JAGUAR and JENSEN as my CAR values. It is a very manual process. If I do dynamic, I don't do any of that mapping and just use a TABLE request. This is documented, and the HTML Composer manual is pretty much the biggest manual if the product. I can look into a best practices guide if course.

Dan, I sent a pm to you

quote:

Paraphrased: Here's how I do it:

1. Create the real fex with -DEFAULTd variables for anything that I will want to use as a control in my launch page (LP).
   
2. Verify that it works as desired (or according to the specs).
   
3. Create any fexes which I'll need to use to populate any controls which I will need on my LP.
   
4. Open the composer and add a button.
   
5. Add a link to the external procedure (shown in item 1).
   
6. Assign the types of controls accordingly.
   
7. Rearrange them the way that I like them. (or, according to the specs).
   
8. Go to the parameters tab (lower left) and assign the “population fexes” to the controls.
   
9. Add the chaining (sorry) cascading.
   
10. Run it and enjoy the results.
    
11. Tweak and test it until I run out of time.
    

I very rarely have any issues when I following this methodology.

I have recently developed a fex using the text-editor which works with 3 chained controls. I have reprogrammed it using the (sample) SALES-master. See the code:

  
-* File selectiefex03.fex
-* Initial fill the ampers
-DEFAULT &AREA = 'U';
-DEFAULT &CITY = 'NEW YORK';

DEFINE FILE SALES
            TXT1/A90  = IF AREA EQ '&AREA' THEN '<OPTION SELECTED VALUE=' | AREA | '>' | AREA | '</OPTION>' ELSE '<OPTION VALUE=' | AREA | '>' | AREA | '</OPTION>';
            TXT2/A90  = IF CITY EQ '&CITY' THEN '<OPTION SELECTED VALUE=' | CITY | '>' | CITY | '</OPTION>' ELSE '<OPTION VALUE=' | CITY | '>' | CITY | '</OPTION>';
            TXT3/A90  = '<OPTION VALUE=' | STORE_CODE  | '>' | STORE_CODE     | '</OPTION>';
END

-* Create the list of areas
TABLE FILE SALES
       SUM TXT1
        BY AREA        NOPRINT
  ON TABLE HOLD AS AREAS
END

-* Create the list of cities
TABLE FILE SALES
       SUM TXT2
        BY CITY         NOPRINT
     WHERE AREA         EQ '&AREA';
  ON TABLE HOLD AS CITYS
END

-* Check if the current combination area and city is valid
TABLE FILE SALES
       SUM TXT2
        BY CITY    NOPRINT
     WHERE AREA    EQ '&AREA';
     WHERE CITY    EQ '&CITY';
  ON TABLE HOLD AS CITYSCHECK
END

-* If there are lines proceed
-IF &LINES NE 0 THEN GOTO SKIPREFILL1;
-* If there are no lines, &CITY must be filled with the first city of the current area
TABLE FILE SALES
       SUM FST.CITY
     WHERE AREA    EQ '&AREA';
  ON TABLE SAVE AS CITY1
END
-RUN
-READ CITY1 &CITY.A15

-SKIPREFILL1
-* Create list of stores
TABLE FILE SALES
       SUM TXT3
        BY STORE_CODE  NOPRINT
     WHERE AREA    EQ '&AREA';
     WHERE CITY    EQ '&CITY';
  ON TABLE HOLD AS STORES
END

-HTMLFORM BEGIN
<HTML>
 <HEAD>
  <TITLE>WebFOCUS MZS02 - Testing chaining controls</TITLE>
     <LINK rel="stylesheet" href="/css/standaard.css" type="text/css">
 </HEAD>
 <BODY topmargin="0" leftmargin="0" scroll="no">
  <DIV align="left">
  <DIV id="powered" style="position:absolute; top:220px; z-index:1;visibility:visible; overflow:auto;">
  <IMG src="/images/powered.gif" align=right border=0 vspace="100">
  </DIV>
  <DIV id="hoofd" style="position:absolute; left: 180; top: 100; z-index:2; visibility: visible; width:600; height: 154">
-* Define a javascript which is called on changes in the dropboxes
  <script language="JavaScript">
  <!--
   function submitIt() {   document.DoIt.submit();      }
  </script>
-* The javascript calls the fex again with filled/changed ampers
  <form name="DoIt" action="/ibi_apps/WFServlet" method="GET">
     <INPUT TYPE="HIDDEN" NAME="IBIAPP_app" VALUE="ad_hoc">
	 <input type="hidden" name="IBIF_ex"    value="selectiefex03">
   <TABLE>
    <TR>
     <TD width="20" rowspan="20"></TD>
    </TR>
    <TR>
       <TD>
         <STRONG>Kies een hoofdstuk</STRONG></TD>
      <TD>
-* If the user selects a different area run the javascript
       <SELECT name="AREA" onchange="javascript:submitIt();">
       !IBI.FIL.AREAS;
       </SELECT>
      </TD>
    </TR>
    <TR>
       <TD>
         <STRONG>Kies een soort </STRONG></TD>
      <TD>
-* If the user selects a different city run the javascript
       <SELECT name="CITY" onchange="javascript:submitIt();" >
       !IBI.FIL.CITYS;
       </SELECT>
      </TD>
    </TR>
   <TR>
    </TR>
   </form>
-* The last control is placed within a new form which calls the actual reporting fex
   <FORM name="form1" action="/ibi_apps/WFServlet" method="GET" target="resultaat">
   <INPUT TYPE="HIDDEN" NAME="IBIAPP_app" VALUE="ad_hoc">
	 <input type="hidden" name="IBIF_ex"    value="mzs02">
     <INPUT type="hidden" name="AREA"       value="&AREA">
     <INPUT type="hidden" name="CITY"       value="&CITY">
    <TR>
       <TD>
         <STRONG>Kies een artikel</STRONG></TD>
      <TD>
       <SELECT name="MSTORE" >
       !IBI.FIL.STORES;
       </SELECT>
      </TD>
    </TR>
     <TD><INPUT type="submit"      value="Overzicht" style='cursor:hand;'>
     </TD>
    </TR>
    </TABLE>
    </DIV>
  </FORM>
 </BODY>
</HTML>
-HTMLFORM END
-EXIT

where is 'selectiefex03'?
and would you tell us what version of 7.6 you're in?

quote:

Originally posted by susannah:
where is 'selectiefex03'?
and would you tell us what version of 7.6 you're in?

selectiefex03 is the name of the fex which I posted the code from. In other words this fex calls itsself...
We're using version 7.7

ah. i see. Can you tell us why you found you needed to write your own? does the usual* method of chaining several separate fexes no longer work in 7.7? (*hand editing cacheruntimedata =0)

We have only recently migrated from version 7.1 to 7.7.
All our fexes use this method to call on other fexes so I just carried on with it.
Anyway, the case I was trying to solve was chaining dropdown boxes without using HTML Composer. This is what I came up with. If there are other ways I'm very interested in them.

quote:

This is what I came up with. If there are other ways I'm very interested in them.

To reload your drop down list boxes it looks like your user reloads their page.

This recursive design will work, and might be fine for certain purposes.

When we looked at this technique, we didn't like the way the page reloaded in the browser, and hence the users 'wait time' included a rerendering/redrawing of the page.

We switched our prototype/design to use Ajax to call the focexecs that would get the data needed for the drop down list boxes.

Basically the TABLE FILEs you have at the top, would be split off into separate fexes.

Your drop down list box controls would trigger the appropriate 'get data' focexec, i.e., a change to the 'area' control, would trigger a reload of the 'city' control.

There are several Focal Point posts describing this, below is an example:
http://forums.informationbuild...557042116#1557042116

In addition to the forum entries on calling the IBI XML Support library for Ajax requests, a presentation at Summit 2012 gave examples of using jQuery to perform an asynchronous HTTP request to run a focexec on the server.

Thanks Brian for the information. I will definitely have a look at the Ajax-methode.

The wait time is not really an issue for us because all the fexes we have load pretty fast.

Also I am not sure if Ajax will work here because our company still uses an old version of Internet Explorer.