Since we haven't had a proper rant in months...

Ever since we switched to App Studio 8105, it removes our URL-based javascript includes whenever we edit our HTML pages in it's HTML Composer. Of course, it doesn't do so in an obvious roundabout way. When I save my HTML, the includes are still listed in the 'Manage CSS and Scripts' panel, even though they're not actually there anymore in the saved file!
Only when I switch tabs to, for example 'Parameters' and back to 'Design' the panel updates to the actual situation...

App Studio, keep your little dirty hands off my includes! I didn't add them as a joke!
Worse, now my HTML contains references to functions that are no longer available to the browser and "stuff" stops working.

I realise that's not very helpful to anyone, so:

Has anyone else run into this problem?
Are there known circumstances under which AS is known to do this?
Is there a way to prevent this other than not using AS?

Yeah, I know, I should open a case about this

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

"problem"? It is designed to do this

(I know I'm not helping here)

Hello Wep5622,

I'm not sure I'm actually following the issue you're having. Is this what you mean:

1. You create an HTML page in HTML Composer.
2. In the CSS/Javascript tab you add a javascript function containing an include.
3. You save the file and either reopen it or switch tabs.
4. The javascript code has been changed and the includes are no longer present.

Is that what you're saying, or is it something else?

Thanks,

Emily McAllister
Focal Point Moderator

Were these HTML pages created 100% using a previous version of App Studio? Or did you partially develop them using some other tool, then try to edit them in App Studio?

I can assume that if the html pages were created in Developer Studio HTML Composer, which allowed "URL-based" Javascript links, these may get mangled by App Studio HTML Canvas (or whatever it's called).

I'm pretty sure this from Developer Studio

<SCRIPT id=Util src="/approot/web/my-util.js" type=text/javascript></SCRIPT>

does not look the same in App Studio

<html_element rtFileName="/approot/web/my-util.js" bindcontrolid="Util" type="script"/>

I won't be surprised if something gets mangled.

Yes, in App Studio JavaScript links are stuffed into the "XML island" part of the HTML page.

Sometimes things go wrong on that island. A year ago App Studio would not let me modify or delete a control on an HTML page I was working on. I had to edit the HTML and remove all references to that control in the XML island to get rid of the thing. Starting over was not an option for me, as it was a big and complicated HTML page.

I'm getting worried.

We are moving from 8.1.04 to 8.1.05, and i fear the js lib included will go. We have a lot of HTML pages and I would not like to have to "fix" all of them.

quote:

Originally posted by Emily McAllister:
Hello Wep5622,

I'm not sure I'm actually following the issue you're having. Is this what you mean:

1. You create an HTML page in HTML Composer.
2. In the CSS/Javascript tab you add a javascript function containing an include.
3. You save the file and either reopen it or switch tabs.
4. The javascript code has been changed and the includes are no longer present.

Is that what you're saying, or is it something else?

Thanks,

Emily McAllister
Focal Point Moderator

Hello Emily,

That's not quite what happens, but you're close.

At step 2 we include a javascript file in the CSS/scripts panel, by typing the URL. For example: /approot/baseapp/myVeryImportantJavascriptLibrary.js

After saving and testing the HTML in a browser, the included code works as it should. Often this also involves a function added in the "Embedded Javascript/CSS" tab, but I don't think that's actually relevant to the issue, that stays unchanged (and still calls the now missing functionality from the supposedly included script).

At step 4, initially the file is listed in the CSS/javascript tool-panel and things are looking good and proper.
However, when changes are made to the HTML design (sometimes as minor as dragging a control to a different position) and the file is saved and then tested again in a browser, the code acts like the file included at step 2 is no longer there, although the CSS/Scripts panel still lists it.

At that point, when switching away from the Design tab and then back, the javascript file listed in the CSS/scripts tool-panel disappears! That does of course also match the witnessed behaviour in the browser.

For some reason, App Studio removed (or forgot about) the script from the HTML page.

quote:

Originally posted by Waz:
I'm getting worried.

We are moving from 8.1.04 to 8.1.05, and i fear the js lib included will go. We have a lot of HTML pages and I would not like to have to "fix" all of them.

They only disappear while editing the files first, so any existing pages will keep working. Until you modify them...

That said, this doesn't just happen with files left-over from Dev Studio days or from previous versions of App Studio. This happens as well with files I newly created and am still working on.

Wep5622,

You may have already verified this, but have you looked at the HTML code to see if the JavaScript URLs are there?

You can do this by Control-clicking on the HTML file and a fex file, then right-click on the fex file and select "Open as text". Both the fex and the HTML file should then open.

I did.

Before their disappearance they're referenced somewhere in the XML-island. After, they are gone.

Maybe they weren't moared properly and the upcoming tide flushed them away from the island...

quote:

Originally posted by Wep5622:
Maybe they weren't moared properly and the upcoming tide flushed them away from the island...

That can happen, especially if your version of WebFOCUS is current.

Are your JS files in the repository ?

To avoid this, I tend to use JavaScript to append or prepend the modules that I need. It negates having to worry about being cast adrift from the island!

I posted a method for including the jquery library within Dev Studio HTML composer as, adding it via normal methods meant that it wasn't loaded at the correct time for me to use it within the "onInitialUpdate" or "window_onload" functions.

It might help you here? Just call from the "window_onload" function.

function loadjQuery() {
  var element = document.createElement('script');
  element.async = false;
  element.src = '/ibi_apps/ibi_html/javaassist/jquery/jquery_min.js';
  element.type = 'text/javascript';
  (document.getElementsByTagName('head')[0]||document.body).appendChild(element);
}

T

@Waz; The JS files are on the reporting server, under the approot. We don't use the repository.

And what you do, Tony, is what our newer libraries do as well, the core library is an asynchronous loader that handles dependencies etc. But... we include it in above script panel.

We could use your trick to include it, but for most of my colleagues that would be a "bit" over their head!

quote:

that would be a "bit" over their head!

A learning opportunity

T

Good to know. Wonder if this persists into 8.2. Haven't tried this myself yet though. We're in 8.1 and have always just tied our HTML to a Js file that lived in either the RS or Repo areas. Never thought to use a manually entered URL. Again, good to know.

Hope this gets figured out for you!

If not from IBI's support team, I'd try and edumacate the masses to use Tony's workaround for now if that works for your scenario.

I have not experienced this using App Studio 8.1.05M. There was a post some time ago that emphasized using a fully qualified domain name, so that's what I've been doing. A link to a Javascript file starting with "https://www", entered in the URL/Find File text box on the settings tab seems to stay put for me. . . so far. I don't have a lot of background with this feature yet. . .

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

quote:

A link to a Javascript file starting with "https://www"

Thats going to be a problem for us, as we don't want to change the URL for each test environment, so its relative.

Well, I tried a relative URL, and experienced the same thing as you did. And I agree on not wanting to be forced to use a fixed URL.

Seems like it's time for me to open a case and request an enhancement. . .

Thanks,
Rob

Hoping its fixed in 8.2..........................

Perhaps only updating to "M" releases is a good strategy - most broken things get fixed, no new broken things get introduced.

quote:

Originally posted by Francis Mariani:
Perhaps only updating to "M" releases is a good strategy - most broken things get fixed, no new broken things get introduced.

Scheduled alerts are broken in 8.1.05 (for us at least), we are patching to 8.1.05M soon to fix it.

8.1.05M bugs that we have discovered:
+ Report title reverts to internal name after opening in external editor.
+ Side by side install with Dev Studio 7.6.10 doesn't work.

quote:

Report title reverts to internal name after opening in external editor.

I don't think this is a bug, as you are opening in an external editor, and it has no knowledge of what the display name is.

quote:

Side by side install with Dev Studio 7.6.10 doesn't work.

I think this is a known issue, we have the same problem here.

Waz, when you create a new object in the Repository you give it a name and a title. After that you can edit using the GUI, the repository web interface, the built-in text editor or an external editor. None of these have an impact on the object title. You can chose to modify the name and title using Dev Studio, App Studio or the repository web interface.

MathematicalRob seems to have found a bug...

To be more clear, it is after opening in an external editor and then saving back to WebFocus that the report Title reverts to the internal name in App Studio.

We have reported this as a bug, and IBI has confirmed it. We do not see this in 8.1.05 which preserves the title.

The world will still go 'round - just a warning; I didn't catch on right away what was triggering the reversion!

- Rob

quote:

The world will still go 'round

except if the repository tree is exposed to end users and they won't find their reports by report title...

quote:

Originally posted by Francis Mariani:
MathematicalRob seems to have found a bug...

Putting on my tinfoil hat now...

A bug, or a "feature" to discourage use of an external editor?

quote:

MathematicalRob seems to have found a bug...

Point taken.

I guess, as we don't care about the titles here, its not an impact to us