[MY OPINION ONLY]
Fascinating how the Dev Studio GUI tools enable some people and cripple others.

I've hated them since v4.3.6 and though they have improved, I still hate them, particularly HTML Composer. My developmental skills are completely stifled by it - if you try to deviate a millimetre from the code generated by pointing-and-clicking, heaven help you. If you managed to shoehorn something out-of-the-norm into your HTML Composer designed screen, heaven help you when you open the file in an upgraded version. Documentation is meagre.

I believe the sales guys are pulling the wool over the eyes of the people purchasing the software - I wonder how many of you are asked to build something based on what a sales guy said was possible, but in reality is a real struggle...

Don't get me wrong - WebFOCUS has been my bread and butter for a dozen years and more, and I really love it - I just wish the powers that be weren't sold a bill of goods.
[/MY OPINION ONLY]

Hi Francis,

I accept with your words.

But my point is Composer is not a tool of entire rubbish. We can do simple pages easily, and complex pages with bit more patience and experience.

But definitely It is one power of webFOCUS which other BI tools, doesn't provide. To run a FEX for populating your input control, to chain them for change of values without page refresh, that to on a single button click.

JS scripts with WF HTML and Manuals, I purely go by your words on this. A lots lots can be improved on that area. Lot of limitations as well. And lot of hidden features, for which we don't have manuals as well.

A relevant discussion from Doug's blog is here.

http://bi-software-webfocus.bl...ocus-extremists.html

HTML Composer - agreed; I find it to be of limited value. I use it for very little - sometimes to produce the initial layout of a page, but often I use a previous page for a template instead.

I would use HTML Composer for very little as well, but when a sales person oversells the component and management then insists on developing with said component, development can take twice as long...

I had this discussion with my management on Friday. Management (based largely on IBI input) believes that we should be doing everything possible within the GUI and only going into the code when absolutely necessary. I gave them the following reasons for working in the code:

• GUI isn't as stable a development envrionment
  
• GUI develops much more lengthy and more difficult to understand code (as do most code generators)
  
• GUI is not intuitive or, by any means, easy to learn
  
• Working in the code gives more flexibility / capability
  
• Working in the code allows for understandable code compares for versioning
  
• Eventually, you will need to work in the code (sometimes even while working in the GUI)
  

Well, that's my two cents,
Steve

I tend to use HTML Composer to create the xml for my controls. I've also learned not to touch the generated HTML significantly, or I'm likely to break page functionality. Replacing SPAN's by DIV's because they really are supposed to be block elements, for example, will render widgets unusable because the javascript code depends on the span-tag... Ugh!

It also generates style-attributes for hidden fields and does all kinds of other fun things that are like sticking hot pokers in your eyes if you're a (former) web developer like me. But, if you know its limitations, it does get the job done.

I don't love it, but it's darn useful to create those incomprehensible xml tags. I'm sure I could learn to write those myself if I put in enough time and effort, but I'm glad I don't have to.
OTOH, the layouts I can create with it are limited by its tendency to change things it shouldn't touch.

I totally agree!!

For those of us who really don't have prior web development experience, especially at the code level, are there any alternatives?

I too find the HTML Composer very frustrating. Is it possible to generate the 'shell' and then add the necessary code for the IBI controls? Or can you do the opposite? Add all the IBI controls and then do your styling somewhere else?

I think the issue is that no matter what you do externally, when opened/saved in HTML Composer, it changes/overwrites the code. At least it has the capability of doing this.

- ABT

At least you aren't an IBI Consulting person out in the field who has to use these tools, no matter what, because the sales team convinced the customer they were all that was needed to develop applications. You cannot call BS because you work for IBI. The tools are powerful, but you still need to break into the code occasionally ... just not when the customer is looking!

quote:

you still need to break into the code occasionally ... just not when the customer is looking

Been there, done that!

quote:

sales person oversells the component

quote:

you still need to break into the code occasionally ... just not when the customer is looking

Frequently!

quote:

Originally posted by Francis Mariani:
I would use HTML Composer for very little as well, but when a sales person oversells the component and management then insists on developing with said component, development can take twice as long...

Ai, ai; I wouldn't like that!

I use HTML composer more frequently. Nut report painter only for style sheets and alignment. Graph tools are OK. But I expect HTML composer to do some javascript as well to do form validations.

quote:

Originally posted by Steve:
I had this discussion with my management on Friday. Management (based largely on IBI input) believes that we should be doing everything possible within the GUI and only going into the code when absolutely necessary. I gave them the following reasons for working in the code:

• GUI isn't as stable a development envrionment
  
• GUI develops much more lengthy and more difficult to understand code (as do most code generators)
  
• GUI is not intuitive or, by any means, easy to learn
  
• Working in the code gives more flexibility / capability
  
• Working in the code allows for understandable code compares for versioning
  
• Eventually, you will need to work in the code (sometimes even while working in the GUI)
  

Well, that's my two cents,
Steve

I'm having this exact problem. We do have a very nice functional guided ad-hoc tool built in HTML composer but I had to hire 3rd party consulting to help build it. I am not (AM NOT) a code person - but I find I spend more of my time in it than in the GUIs. My management discussions often result in him asking me "well can't you use the GUI for that??".

My addition 2 cents..

quote:

Nut report painter

gave me a jump start to

• learn the basic programming flow of the Focus language.
• learn the basic syntax
• dump the columns onto the report quicker and without typo
• learn what is available
• is better than google translate to learn a new language

The HTML composer only allows me to do what I have to do. I could not learn anything from it. It broke everytime I touch it.

IMHO, the Dev Studio tools are just that... tools.

If the task at hand can be accomplished better with the GUI, I use the GUI, if I can do it better in code using the text editor, I write code.

Occasionally I have run in to a client that has a company policy of "NO GUI" and occasionally another client has said "the code MUST open in the GUI". No problem. I give the end client what they want, the way they want it, and use the tool that best suits my style to get there.

As the man said, just my opinion.

rfbowley, that is certainly a "glass half full" attitude!

I'll also add...If anyone remembers the state of the GUI toolset with "PC Focus for Windows version 6xx" circa middle 90's...talk about frustration...IBI has come a long way in making them actually usable, though.

I remember PC Focus Six, it certainly did GPF alot, but also had some very interesting capabilities.

I have watched the state of IBI GUI efforts since the very first product: PC Focus DLL, IIRC. To say I have been underwhelmed is an understatement. And the problem hasn't really gotten any better down through the years as the bad practices have become embedded deeper into IBI products and culture.

Compare PC Focus for Windows with something like Visual FoxPro or Visual Basic, to see that something much better could have been done.

The only GUI tool I ever used that much was the Report Assistant, to throw together quick and accurate TABLE code to further refine by hand. And while I have been mostly working with Maintain in the WebFocus era, I tried to take a look at the HTML Composer, but couldn't even find it until a very recent Dev. Studio version. And, after hand coding a number of websites and report front-ends, I seriously doubt that I would have ever used it for of much of anything anyway.

So I'm a hand coder by training, but very amenable to using GUI's by nature. Unfortunately IBI GUI implementations have been so flawed, they have discouraged me and many others from app learning through exploration, through they do provide IBI with some additional revenue for training classes, where rote learning of a cookbook of obscure incantations is necessary to get things to work. While that may be an acceptable 'workaround' for some, I can't see it as helping to sell the WebFocus product to as wide an audience as, I believe, it's underlying capabilities deserve.

Being not very impressed with the first PC's, I was exposed to the early Mac's and have been involved with them ever since. In addition, and perhaps because of these early experiences, I became interested in, and have studied and worked with User Interface Design ever since.

You might be interested to know that IBI actually started a version of FOCUS for the Mac, consistent with their multi-platform strategy, but unfortunately it didn't get very far. So IBI hung its star on the Microsoft Windows GUI, and lost a great opportunity. They could have learned a lot from Apple instead of using the worst of MS GUI garbage.

I find it very ironic that IBI, who pioneered the idea of ease of use and learn-ability for text based programming on the mainframes of the 1970's, should screw up so badly in the era of the mouse.

..........................

This may be my parting post to FP, as I have pretty much retired since being laid off at the end of last year. And I see less and less Maintain discussion going on here as well.

A big hearty THANKS to all on the forum how have helped me both as a lurker and poster !

Dave Ayers

Dave,

Best of luck in your retirement years, I hope you have some hobbies to keep you busy - stay away from coding.

WebFOCUS 7.7.02 sounds so new, but have you looked (I know you're not supposed to) at the HTML code it generates? Definitely not standards compliant: HTML tags without quotes around values is one annoying aspect, mix of upper and lowercase HTML tags is another - I plan to compile a list when I have time and a fine-toothed comb.