Invelos Forums: HTML Window and external files...

Welcome to the Invelos forums. Please read the forum rules before posting.

Read access to our public forums is open to everyone. To post messages, a free registration is required.

If you have an Invelos account, sign in to post.

Invelos Forums->DVD Profiler: Layouts and Reports

Page: 1

Previous Next

HTML Window and external files...

Poll Results

Yes	(8)
No	(1)

Please sign in to vote on this poll.

Author

Message

	xyrano
	41215.reg 70320.urk

Registered: March 13, 2007

Posts: 646

Posted:

You may know that in DVD Profiler we (the users) can create a simple html page and then have that shown in the DVD Profiler Layout through the internal HTML Editor (HTML Section) as a floating window or as a fixed window (tabbed).

As a creator of several such HTML Sections I've discovered some shortcomings in the HTML Editor. DVD Profiler cache handling of these HTML Sections does not allow external files that, for instance, a normal browser do.

The external files I am referring to are files included in the HTML document through; link(css) and script(javascript) tags.

I can understand the amount of work Ken might need to put in so the HTML Editor support these type of files, I do understand Ken might not want this in the HTML Editor at all. I'm not saying this must be done by Ken, but rather that we could find a solution for this.

So, in this situation, I want to start a discussion with you guys on how to do it, what it means and how this affects a already written HTML Window scripts (such as the GV, EPGL, ...).

I realize we who, at one time or another, have created such scripts are few, but thought to ask;
Is this something that would interest you?

[edit]
Naturally, this would be done in such way that it would not interfere with DVD Profiler's normal behavior.

Last edited: by xyrano

	goodguy
	Sita Sings the Blues

Registered: March 14, 2007

Reputation: Superior Rating

Posts: 1,029

Posted:

I'm not sure I understand your request. I'm using external links for CSS and SCRIPT all the time for my HTML sections. Of course, I have to use absolute file paths when doing that, so maybe that's your problem.

If you don't want to deal with absolute paths for publicly shared scripts, there are basically two workarounds.

You can rename scripts and stylesheets to *.gif and add them to your layout. IE is perfectly happy with such an bogus file extension for them. You may try this little demo:

Save this as Test1css.gif and add it as image to your layout:

Quote:

BUTTON { background-color: magenta; }

Save this as Test1js.gif and add it as image to your layout:

Quote:

function someFunc() { alert("Hello from external script."); }

Create a HTML section with this content:

Quote:

<HTML>
<HEAD>
<LINK rel=stylesheet href="$DPIMAGES.Test1css.gif">
<SCRIPT language=javascript src="$DPIMAGES.Test1js.gif""></SCRIPT>
<SCRIPT language=javascript>
function doit() {
try {
someFunc();
} catch (e) {
alert("Oops! Didn't find the script link.\n" + e.description);
}
}
</SCRIPT>
</HEAD>
<BODY>
<BUTTON onclick="doit()">Test script link</BUTTON>
</BODY>
</HTML>

The second solution is a plugin acting as a container for HTML resources. You can then use "res://myplugin.dll/<resname>" in LINK href or SCRIPT src.

Matthias

Last edited: by goodguy

	xyrano
	41215.reg 70320.urk

Registered: March 13, 2007

Posts: 646

Posted:

Quoting goodguy:

Quote:
I'm not sure I understand your request. I'm using external links for CSS and SCRIPT all the time for my HTML sections. Of course, I have to use absolute file paths when doing that, so maybe that's your problem.

If you don't want to deal with absolute paths for publicly shared scripts, there ...

Yes, this is about absolute paths because this is the only thing that works in a HTML Window in DVD Profiler when accessing a local resource. Relative paths would require a container of sorts (your second solution might be that container). So basically, you and me are 5 by 5 on what this is about.

Quoting goodguy:

Quote:
...scripts, there are basically two workarounds.

How to - Solution 1.
Quoting goodguy:

Quote:

You can rename scripts and stylesheets to *.gif and add them to your layout. IE is perfectly happy with such an bogus file extension for them. You may try this little demo:

Save this as Test1css.gif and add it as image to your layout:
Quote:

BUTTON { background-color: magenta; }

Save this as Test1js.gif and add it as image to your layout:
Quote:

function someFunc() { alert("Hello from external script."); }

Create a HTML section with this content:
Quote:

<HTML>
<HEAD>
<LINK rel=stylesheet href="$DPIMAGES.Test1css.gif">
<SCRIPT language=javascript src="$DPIMAGES.Test1js.gif""></SCRIPT>
<SCRIPT language=javascript>
function doit() {
try {
someFunc();
} catch (e) {
alert("Oops! Didn't find the script link.\n" + e.description);
}
}
</SCRIPT>
</HEAD>
<BODY>
<BUTTON onclick="doit()">Test script link</BUTTON>
</BODY>
</HTML>

[fallingofchair]

Oh, man, that is a nifty solution indeed... one that was "hidden" from me... until now. Thanks!!!

How to - Solution 2.
Quoting goodguy:

Quote:
The second solution is a plugin acting as a container for HTML resources. You can then use "res://myplugin.dll/<resname>" in LINK href or SCRIPT src.

This is something I'll have to learn or if someone could put one together.
I do understand the fundamentals of it (the plugin is holding the absolute path to a resource location of choice), but do not know how to do it (the actual plugin dll file)... yet...

	xyrano
	41215.reg 70320.urk

Registered: March 13, 2007

Posts: 646

Posted:

How to - Solution 1 - Implementation
While this solution certainly works beautifully for the user that understand the concept and can deal with the renaming (in the implementation process), I do feel it may be a cumbersome event for the users who have trouble understanding say, html. I'm particularly concerned with updates to the resource files which in this case would be gif's and yet, it is to good to rule out. I guess, one thing that could help is a recommendation to use strict name conventions to these files, so it would be clear what format they really are. Something silly like [this_is_a_css_file.gif]

or
css-font_background_settings.gif file containing say, this

Quote:
* { color: white; font-family: verdana; font-size: 10pt; }
html,body { margin: 0; padding: 0; background-color: rgb(0, 0, 83); }
body { background-repeat: repeat-x; background-image: url($DPIMAGES.bgimage.jpg); }

content.

Will ponder about this some more. Thanks again goodguy, for bringing it!

	goodguy
	Sita Sings the Blues

Registered: March 14, 2007

Reputation: Superior Rating

Posts: 1,029

Posted:

No. The res:// protocol accesses resources included in a DLL or EXE file. Since the plugin is loaded in DVDProfiler's process space, you don't need a full path for referring to it and can simply write src="res://myplugin.dll/xxx", where xxx is the number or name of the HTML resource compiled into the DLL. But I only would recommend this solution if the plugin is needed to provide additional functionality. For example, my Profile Comparison Plus plugin uses this method.

But regardless of which solution you use, you have to ask yourself: Why do you need external files in the first place?

For my private HTML Sections I use them, because I prefer to work in my normal development environment instead of DVDProfiler's HTML Editor. So I keep the content of the HTML Section to the absolute minimum and usually don't need to change it often during the development and debug process, because most of the necessary changes happen in the external files.

But from a end user's point of view that really doesn't matter. And the performance gain from having a smaller HTML section is not really noticable.

So if you write HTML sections for public use, the best thing you can do is having a Make script that replaces your external refs with the actual content of the referred files. For example, my CreditsPlus HTML sections are created that way.

Matthias

	xyrano
	41215.reg 70320.urk

Registered: March 13, 2007

Posts: 646

Posted:

Quoting goodguy:

Quote:
No. The res:// protocol accesses resources included in a DLL or EXE file. Since the plugin is loaded in DVDProfiler's process space, you don't need a full path for referring to it and can simply write src="res://myplugin.dll/xxx", where xxx is the number or name of the HTML resource compiled into the DLL. But I only would recommend this solution if the plugin is needed to provide additional functionality. For example, my Profile Comparison Plus plugin uses this method.
x: Thanks for clearing that out.

But regardless of which solution you use, you have to ask yourself: Why do you need external files in the first place?
x: Indeed I have, I wouldn't have started this thread if I had not.

For my private HTML Sections I use them, because I prefer to work in my normal development environment instead of DVDProfiler's HTML Editor. So I keep the content of the HTML Section to the absolute minimum and usually don't need to change it often during the development and debug process, because most of the necessary changes happen in the external files.

But from a end user's point of view that really doesn't matter.
x: I do not agree!

And the performance gain from having a smaller HTML section is not really noticeable.
x: No its not.

So if you write HTML sections for public use, the best thing you can do is having a Make script that replaces your external refs with the actual content of the referred files. For example, my CreditsPlus HTML sections are created that way.
x: a Make script?

	xyrano
	41215.reg 70320.urk

Registered: March 13, 2007

Posts: 646

Posted:

Why
When creating the TV Episode Guide Loader (EPGL) and Gallery Viewer (GV) I use one (1) single place to put underlying resources. DVD Profiler itself is located in its default place on C. Each of these scripts reside in its own substructure (/EpG and /Gallery).
In each of the EPGL and GV there are elements with values that are defined exactly the same (bold).
As a short example there are two style definitions and a portion of the path that are same (bold):

Quote:
In EPGL:
* { color: white; font-family: verdana; font-size: 10pt; }
body { background-repeat: repeat-x; background-image:url($DPIMAGES.bgimage.jpg); }
and in GV:
* { color: white; font-family: verdana; font-size: 10pt; }
body { background-repeat: repeat-x; background-image: url($DPIMAGES.bgimage.jpg); }

Quote:
In EPGL:
var pathToEpGStorage = "E:\\DVD Profiler\\EpG\\";
and in GV:
var gsl = "E:\\DVD Profiler\\Gallery\\";

These two elements and the portion of the path could be located elsewhere. The key to all this is of course the portion of the path that point to external resources (the absolute path).
Example:
Imagine you wish to change say the background of all your HTML Windows. With what I have just explained; you would change the background value in one css file and it would show in all your HTML Window scripts that use this solution. There is no need to edit every script!!!

Now, think of all the styles and functions in those two scripts and realize there are more things that can be externalized.
Now, think about what is common in all the HTML Window scripts you use in your layout.

Another example:
When a script editor (such as myself) make an update to a script and the script has a bundle of inline variables, the user of the script needs to set them over and over, for each update.

Externalizing those variables would simplify for the user, would it not?

How to - Solution 3
As mentioned before, the key is the absolute path to the resource location. Here we could use the solution brought forth by goodguy (How to - Solution 1).
Example: A file named myAbsolutePath.js containing (my) a absolute path.

Quote:
E:\\DVD Profiler\\

Renamed to myAbsolutePath.js.gif then imported into DVD Profiler.
Although, this would mean that the script would not function outside DVD Profiler.

A HTML Window script could start of with something like this:

Quote:
<html>
<head>
<script type="text/javascript">

</script>
<link rel="stylesheet" href=" (pathToStorageLocation + '[subfolder]/font.background.css'">
...
</head>
<body>
...
</body>
</html>

What you think?

Although, I would prefer it, if Ken could give us $DPSCRIPTS that support externalized style and javscript files.

	goodguy
	Sita Sings the Blues

Registered: March 14, 2007

Reputation: Superior Rating

Posts: 1,029

Posted:

Quoting xyrano:

Quote:
How to - Solution 3
...
What you think?

That you didn't test this one.

You can't just put the path name into the external file, it has to be a valid JScript expression and you need to include the external file via SCRIPT if it contains JSCript code. And you can't use a JScript expression in an href attribute directly and expect it to become a link all by itself.

Anyway, I don't deny that there are scenarios where external files might useful for the end user as well, and I am also a big fan of modularization myself. But your example simply isn't worth all the trickery. If you really want to make it user friendly, provide a configuration dialog, where the user can enter the location of the EPG or Gallery storage and save it either as a cookie or in IE's persistent user data store for reuse by your script.

As for the make script I mentioned earlier: I'm not sure what's unclear about it. It is a script file that reads an HTML file, resolves external refs and creates a new HTML output file for the end user. For example, this HTML source:

Quote:

...
<LINK rel=stylesheet href="mystyle.css">
<SCRIPT src="myscript.js"></SCRIPT>
...
<BODY>
...

becomes this end user file:

Quote:

<STYLE type="text/css">
/* Content from mystyle.css inserted here. */
</STYLE>
<SCRIPT language=javascript>
/* Content from myscript.js inserted here. */
</SCRIPT>
...
<BODY>

Matthias

	xyrano
	41215.reg 70320.urk

Registered: March 13, 2007

Posts: 646

Posted:

Quoting goodguy:

Quote:
Quoting xyrano:
Quote:
How to - Solution 3
...
What you think?

That you didn't test this one.
You can't just put the path name into the external file, it has to be a valid JScript expression and you need to include the external file via SCRIPT if it contains JSCript code. And you can't use a JScript expression in an href attribute directly and expect it to become a link all by itself.
x: Well, that sucked!
When I posted there were more code in the href attribute. Somehow the wording javascript + a colon got truncated. There is also a ) missing.
Regardless, no, I didn't have time to test it. Besides, I didn't intend to post a fully functional application Just wanted to post my idea. Now it seems I can't do that either.

Anyway, I don't deny that there are scenarios where external files might useful for the end user as well, and I am also a big fan of modularization myself. But your example simply isn't worth all the trickery. If you really want to make it user friendly, provide a configuration dialog, where the user can enter the location of the EPG or Gallery storage and save it either as a cookie or in IE's persistent user data store for reuse by your script.
x: That would be the ultimate solution. I'll need to get access to the plugins forum and spend some time with the API before that is even an option for me

	goodguy
	Sita Sings the Blues

Registered: March 14, 2007

Reputation: Superior Rating

Posts: 1,029

Posted:

Quoting xyrano:

Quote:
Quoting goodguy:
Quote:
If you really want to make it user friendly, provide a configuration dialog, where the user can enter the location of the EPG or Gallery storage and save it either as a cookie or in IE's persistent user data store for reuse by your script.

x: That would be the ultimate solution. I'll need to get access to the plugins forum and spend some time with the API before that is even an option for me

That doesn't require Plugin API functionality.

Matthias

Last edited: by goodguy

Invelos Forums->DVD Profiler: Layouts and Reports

Page: 1

Previous Next