Hi All

I would like to understand logic how Developer studio creates HTML.

I was willing to have a checkbox and pass value to procedure (I have done it in some way for simple inputs, lists and dropboxes).

Developer studio creates construction like

SPAN (there is my checkbox)
...
variable (there value of variable is passed to my WF variable &dollars)
...
input_control (there is usualy described what value to put into my checkbox, what name to display).


So, I was thinking to make something like (I removed < at the beginning of line, otherwise text of html become invisible)
div class="checkbox">
label>
input type="checkbox" id="dollars" value ="USD" >in Dollars
/label>
/div>


and pass "dollars" as variable to report. (I an using bootstrap library). I have tried to add this into html made by DevStudio, but there was no success.

First, it looks, that I was not able to change SPAN by my construction with

Nobody really knows how it works???

What is reading data from what?

quote:

I would like to understand logic how Developer studio creates HTML.

Wouldn't we all.

I like to know it very seriously

What is absolute minimum to create a control, i.e. checkbox, understandable by WF?

I describe it with ID=BOX. Will it be ID or persistentuniqueid used after that to fill this checkbox?

What is absolute minimum to mention in variable and in input_control?

How Varable, input_control and my objects are related?...

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

There was long silence, so, I have spend few hours and done a lot of elimination. But it looks, that there is such logic:


1. You create HTML object (i.e checkbox) and give it id=object_id

2. In variables you create variable and essential is to use name=WF_Variable_name (it goes to WF) and in link section describe persistuniqueid=object_input_control_id

3. In input_controls, you create lines with bindcontrolid=object_input_control_id and id=object_id

All fine? Any observations?

Have a good day,

Piter

That's about right.

Basically, the launch-page consists of 2 sections:

• The HTML form;
  This is the visible part of the form. Each element has a unique "id" attribute value, that can be used to reference it from the IBIcontrol-section or for use with javascript.
  
• an embedded XML section; this is custom XML code designed by IBI, undocumented AFAIK. We can but guess how it works. It consists of input_control sections that reference the HTML form elements by id and variable-sections that are cross-references by persistentuniqueid attributes.
  

For checkboxes and radio buttons, the input_control id references the surrounding span element (quite non-standard, btw) by id. Next to that, you can't change that span element to some other (more appropriate) element, even though span is supposed to be an inline element instead of the block element it's being applied as...

But I think that's about as much as we (as users of the product) know. It's probably also more than we're supposed to know, as IBI really wants us to use the GUI for this kind of work. It'd surprise me if some IBI employee would step up and explain in detail how this works.

In using a GUI tool, the code behind the scenes should be irrelevant. It can change between releases. This tool shields the user from HTML, CSS, JavaScript and FOCUS.

I learned the very very hard way that you must create the report (fex) first, with -DEFAULT parameters.

Then you use HTML Composer to create a parameter screen for that report. If you do it this way, the persistuniqueids, requestids, etc get automatically created - which you're not supposed to know about or look at. Heaven help you if you need to add a second parameter or if the structure of the report has changed drastically.

After a couple of years of pain, I have figured out ways to cheat the system.

quote:

This tool shields the user from HTML, CSS, JavaScript and FOCUS

I consider myself and many of the people on FocalPoint "developers" not "users" so it isn't helpful that we're shielded from HTML, CSS, JavaScript and FOCUS...

This tool is designed for those who don't want to know HTML, JavaScript, XML, FOCUS and CSS. If you want to deal with that stuff, then you should not use a GUI tool designed this way.

Modifying a report after the page is created entails:

1. Make the changes to the report
2. In the HTML page, delete the controls that pertain to the report
3. Right-click the iframe that contains the report and select "Refresh Parameters" to get the "New Parameters" dialog and generate controls for the modified report
5. If the report has no iframe, you re-reference it in the "Hyperlink Properties" dialog

quote:

delete the controls that pertain to the report

Is this documented anywhere?

Does this sound like a good idea "for those who don't want to know HTML, JavaScript, XML, FOCUS and CSS"?

Rebuild all the controls? Pointing and clicking to style a bunch of controls that you've already created? Pointing and clicking to re-add dynamic or static values? Just to add a new parameter?

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

Hi Francis,
Do NOT delete your controls.
Un-check the bottom selection and "DO NOT" recreate all your controls.
This way you will get your "new" parameter that you placed into the fex, then, you can bind it to one of your controls...
Tom

Tom, don't worry - I don't delete the controls. I've found very convoluted ways to work with HTML Composer - both when designing a page purely with the GUI and also when working with a hybrid GUI/coded page.

I do wonder why the instructions from IBI are to delete the controls - in my humble opinion this does not sound productive at all.

Hi Francis,
OK, I was hoping you hadn't done that!
I have to use the GUI now, AND, if you Edit in Text, you get a message that it may not be compatible. Doesn't bother me too much, what bothers me most are all the HTML tags within FORM are on 1 line now...

Agree with point #2, don't know...
Tom

I do enjoy this conversation...

I gave one method. Of course if you add a new parameter, "Refresh Parameters" will add that one. If you change existing parameters though, delete will take care of that easily as opposed to changing properties of existing controls, but you can do that too. I was just showing that it is not hard nor convoluted.

I can get the checkbox to work (in the way David describes), but when I schedule the report, the checkbox value is ignored.

The checkbox works in scheduling if the Hyperlink Properties dialog is opened (right-click the schedule button on the report page) and closed (click OK in the dialog).

See also https://techsupport.informatio...ry.jsp?case=20783554

Unfortunately, I have to take that back. Opening the Hyperlink Propoerties dialog etc may help in some scenario(s) but not in all.

The basic problem is that if the checkbox is not checked, processing of the fex will make WebFOCUS prompt for the value of the amper var, which is not what we want. We could fix that by setting a default value for the amper var by means of a -DEFAULTH statement in the report procedure: this default value would be used if the checkbox is left unchecked.
BUT this -DEFAULTH statement would make the report scheduler ignore the amper var altogether, causing the checbox to be unchecked when the report schedule runs (ignoring that the user may have checked the checkbox upon scheduling).

The good news is that there is a workaround: Use a drop down list with values Yes and No (bound to the amper var) instead of a checkbox. Unacceptable you might say. Well, then you can hide this drop down list, drop a checkbox on the page, and write some JavaScript that upon (un)checking changes the selected value in the hidden drop down list.

I'm with the vast majority on this thread when I say make the tool work for developers. This tool is almost a joke as it stands now. Too many nuances where you have to know a workaround, go to several places to do one thing because we "users" aren't trusted with HTML and Js.... Basic web technologies even youth are excelling at.

I've spent way too long looking for ways to get basic form validation working, parameters working between HTML forms and reports, and trying to place my own Js files into the Content folders I've created. It doesn't let you. Why? This tool would be far better if IBI treated the developers like intelligent beings and not the way they do. It's very very very frustrating not to be able to access our HTML, etc. Not a good direction for this company.

In Visual Studio, when working with C#, tool-generated code is placed within collapsible #region tags with comments warning the dev not to manipulate such, but still allows proper manipulation of HTML, CSS, Js, etc. w/o issues due to sufficient decoupling. With IBI, they cut your left and right arm off and spoon feed you partial bits of information in hopes that you will buy another add-on, etc. If this wasn't my job for the time being, I would totally leave IBI and their products behind. As far as I'm concerned this product is in Beta (AppStudio).

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