Information Builders is adamant that HTML files are edited ONLY via an external text editor.

I've found two holes in this procedure.

1) Sometimes, due to network issues, the temporary file passed back from the external text editor is not saved into App Studio. Since one of the many bugs of App Studio 8.0.08 is that the last date.time is not updated, you have no clue that the save did not work. I've found that if I remote in to my PC, and then later on, directly access the PC, the connection to the external text editor is lost, but there is no feedback from App Studio.

2) You cannot use the external text editor to edit two or more files with the same name, even though they are in different domains and/or folders.

These issues, of course, occur with any file type opened in the external text editor.

Do you find this acceptable? Has anyone else opened a Tech Support case asking for an internal App Studio text editor for HTML files? My case got closed:

quote:

The final decision is that we are not allowing text editing of HTML pages in App Studio.

So thank you for bringing this problem to our attention.
But therefore, I will just close the case.

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

Francis - As always your willingness to share information is very much appreciated, and is a great example of what makes IT such a great profession for me to be a part of.

May I ask a clarifying question?

Is this thread, and your case, talking about only files created by the HTML Composer tool?

(When we migrated from 7.7.02 to 8.0.07, App Studio was not available. For that reason, and several others, we develop with WFDS 8.0.07)

This particular post is for any HTML file, including htm, html, css or js file. App Studio is supposed to be the future, but I'd wager you're better off with WF 8.0.07 where there is no App Studio, because App Studio 8.0.08 is not ready for prime time.

Hi Francis,

The company I work for is fairly new to WebFOCUS, and as someone with a web programming background, I find the HTML Composer quite limiting and frustrating to work with. Of course I understand the merits of such a tool, but it has made my job harder, not easier. I opened a case with Tech Support asking about a text editor within App Studio for HTML files and received the following response:

quote:

Hi Sarah,

The Product Division has reviewed and edit of HTML pages will not
be pursued. Our HTML pages are HTML, XML islands, CSS and JavaScript
and the pieces are tightly integrated. You cannot successfully edit
them.

Please let me know if there is anything else needed or if the
case can be closed.

A former coworker posted in one of your other topics discussing this issue and received a surprising response here, but a decision was made within my team to use an external editor instead, so we decided not to pursue the issue further.

I'm now using Dreamweaver, which I've used in the past and like, but have run into another issue. When I open HTML files in Dreamweaver via App Studio 8.0.08, changes I make in Dreamweaver are never saved back to the file. Luckily, I also have Dev Studio 8.0.08 installed on my machine, because that application actually does play nicely with Dreamweaver. I do have a case open for the App Studio 8.0.08/Dreamweaver CC 2014.1 issue which, according to Tech Support, sounds like it has been fixed in 8.0.09. At this point, it's not a huge issue for me, because I can just use Dev Studio while I wait for my company to be ready to upgrade to 8.0.09.

I, too, appreciate your candor on this forum and share many of your frustrations.

Sarah

Sarah B, thanks very much for your post. Information Builders keeps repeating this mantra, "Our HTML pages are HTML, XML islands, CSS and JavaScript". But, what about OUR HTML CSS and JavaScript? (What is an XML island, by the way? Jargon for jargon's sake?)

If we take Information Builders decision a tiny bit further, (and I keep asking this, with no response) why do they allow us to edit THEIR GUI-built WebFOCUS reports in a built-in text editor? I can add one comment line somewhere in the middle of the GUI generated code and mess everything up. Why are they not protecting THEIR fex files as they are protecting their HTML files?

"Our HTML pages are HTML, XML islands, CSS and JavaScript and the pieces are tightly integrated. You cannot successfully edit them." - We're allowed to edit them in an external text editor and mess everything up, so what kind of protection is this anyways? I think something else is at play and we're not being told what it is.

Francis,

Agreed on all points. I thought "XML island" was just jargon for jargon's sake too, but then I googled it and found some (somewhat) helpful information. They seem to be more commonly referred to as "XML data islands" and are (according to webopedia.com):

quote:

Blocks (called islands) of Extensible Markup Language (XML) embedded in an HTML document. Microsoft Internet Explorer 5.0 and newer versions support embedding the XML data inside HTML pages. XML data islands can be accessed from client-side scripts or directly bound to HTML elements.

Sarah

And then there's this:

Microsoft Internet Explorer Dev Center: XML data islands are no longer supported

quote:

Support for XML data islands has been removed in Internet Explorer 10 standards and quirks modes for improved interoperability and compliance with HTML5. This means that XML data islands are now parsed as HTML, just like in other browsers. This change can impact pages written exclusively for Windows Internet Explorer or pages that use browser sniffing to alter their behavior in Internet Explorer.

Yes, I saw that too! According to IBI it doesn't seem to be an issue though, as all releases appear to support IE 10.

Web Browser Support for WebFOCUS


Sarah

Addendum:

So, you set up your favourite external text editor to edit htm files.

Now, every time you log in to Windows and start Internet Explorer, you will be confronted by this:



You have to remember why you get this message, and select "No, never ask again (until the next time I log in)".

quote:

Originally posted by Francis Mariani:
And then there's this:

Microsoft Internet Explorer Dev Center: XML data islands are no longer supported

quote:

Support for XML data islands has been removed in Internet Explorer 10 standards and quirks modes for improved interoperability and compliance with HTML5. This means that XML data islands are now parsed as HTML, just like in other browsers. This change can impact pages written exclusively for Windows Internet Explorer or pages that use browser sniffing to alter their behavior in Internet Explorer.

Like above says, other browsers never even supported XML data islands and (like IE10) interpret the tags as if they were part of the HTML structure.

To prevent the contents of the XML data island (that is being interpreted as HTML) to show up on the page, IBI used a trick: They wrap the contents of the XML data island inside a script-tag.

That's why this works in other browsers and why it will keep working for the foreseeable future, even in Internet Explorer.

Now that does not mean that it's an okay decision of IBI to disallow editing the HTML, since as long as you know what you're doing - especially if you don't even touch the XML data island or the associated form elements - there's nothing wrong with editing the HTML.
Most of the time that we edit a generated HTML file, it is to include a style-sheet or some Javascript. That's often much quicker and more convenient in a text-editor than it is using the GUI tools.

What's worse is that apparently the same limitation is put on files that were never generated by the GUI tools, like external Javascript or CSS references or custom-built HTML files without IBI controls. We should be allowed to edit those.

Now we're still on 7.7, so App Studio is not even on our horizon yet, so I may be missing a point or two :P