Getting rid of SCRIPTPATH

Poster: Andy
Dated: Monday September 15 2003 - 11:53:17 BST

After the many problems we've seen associated with scriptpath. We've decided to remove it. The only reason we need it is because of Netscape 4.0 and as this browsers day are numbered it seems pointless structuring the menu for a soon to be defunct browser.

So, here is what we propose. Remove the scriptpath variable completely and replace it with a much less troublesome <script> reference technique.

Here's what we propose.



Can anybody see any problems with the above. Doing it this way allows the user to declare the path to the files from within each HTML page. Not quite what we wanted to do but it is at least much easier to use.

Let me know what you think

Andy

Poster: Hergio
Dated: Monday September 15 2003 - 12:58:10 BST

Andy,
I guess it simplifies it a bit. And for those that just don't want to support ns4 (like me because I dont need to) can leave it out, hehe. Yeah its another line of code but the placement seems more intuitive and easier to follow. It will also make troubleshooting of peoples code easier now. Guess its the best idea because it will eliminiate the problem, hopefully.

Poster: John
Dated: Monday September 15 2003 - 15:10:46 BST

We'll still have the problem of trying to teach server-relative addressing, but we had that anyway. As for me, when my sites start getting 'deep' I use includes for the calls, so it makes no difference. We'll have our hands full in the conversion as far as support is concerned, and Andy will have to update the docs.

Overall, with one less file to worry about, I would hope it makes it easier for the folks.

Poster: Andy
Dated: Monday September 15 2003 - 15:15:15 BST

Docs are done - There may be remnants remaining here and there though.

The directory structure problem is a big one and something we can do little about. It's been around for almost as long as the computer itself but some people have a big problem getting their heads around it.

Although, if the few people we advise on this subject actually listened to what we told them, life would be just a tad sweeter. Am I sounding cynical?

Cheers
Andy

Poster: John
Dated: Monday September 15 2003 - 15:26:09 BST


We will check...

Not at all. Actually - you beat me to it. I just couldn't find a polite way to phrase it

Poster: Andy
Dated: Monday September 15 2003 - 15:29:21 BST



Oh-eck

Poster: Hergio
Dated: Monday September 15 2003 - 19:53:00 BST

I will be sifting through it tonight also. I agree, addressing isn't super tough, but I kinda think that some of these users are more design oriented and less code-jockey-esk. Not real technical. But then again, the job of a webmaster is to wear many, many hats!

Poster: Andy
Dated: Monday September 15 2003 - 20:00:37 BST

This is where a Windows App will be useful then?

BTW - I discovered Webmin today - Can't believe we've been struggling for so long. Check it out at http://www.webmin.com/ definitely on the ToDo list once we've figured out how secure it is. Most helpful if you run a Unix server.

Cheers
Andy

Poster: John
Dated: Monday September 15 2003 - 20:05:24 BST

Jeez, there's a lot of stuff there! Might be fun to play around with it on my Linux/Apache box.

Poster: Hergio
Dated: Tuesday September 16 2003 - 3:34:54 BST

Took a look at the documentation, didn't see anything out of the ordinary. Even did a text search of the documents and could not find the word scriptpath, hehe. One thing, but they are small, but I think you like us to be picky... you did a nice job saying that a style is ABSOLUTELY necessary for a menu, but I dont remember seeing you say that you MUST have at least one menu item declared (an aI() ) in the menu. I removed all the aI's from a menu and it errored out on me. Not that people would do this on purpose, but they can, so its relevant. hehe picky picky picky.

Yeah Andy, thats where I think a GUI for building the menu would be a great help. It would allow the more artistic webmasters to get an awesome and powerful menu without having to get technical and mess with the nuts and bolts. But we would still allow for hands on customizability...if wanted.

That webmin looks like a great thing. Lots of functionality, I must say. I like the idea of using it.

Poster: John
Dated: Tuesday September 16 2003 - 3:37:10 BST


Shame. You missed the milonic_src.php (unless you pulled the file after Andy fixed it).

Poster: Hergio
Dated: Tuesday September 16 2003 - 3:44:24 BST

Yeah I actually downloaded it about 30 minutes ago, theres no record of the php reference that I can find. But I woulda caught, I know it! hehe

Poster: John
Dated: Tuesday September 16 2003 - 14:42:02 BST

That .php thing was trippin' up a lot of folks. Hopefully that's now put to bed.

Poster: Hergio
Dated: Wednesday September 17 2003 - 13:06:08 BST

Andy, noticed the FAQ page on the main site still answers a question and uses scriptpath to answer it. Just FYI.

Poster: Ruth
Dated: Sunday September 21 2003 - 20:47:53 BST

Hello everyone,
I've been away for a bit. I just read the info and will mess with it, but wanted to say, as to the script paths. You're right on the more design oriented than tech-ish. Yes, if you're a webmaster you need to wear more than one hat, however....it's a term applied to ANYONE who does their own work on their own site and MANY are just guys with some personal pages for fun who are putting them up hit or miss with NO idea how things work. That was myself [and to be honest with a lot of the new stuff, it's like I'm back to that point ] It's kind of like the field of math, most math instructors CANNOT make analogies to the real world because in truth the math is NOT equivalent to that analogy, but for the student many can't 'visualize' outside of the real world so they feel lost and ultimately frustrated not knowing just what the 'functions' etc are doing. Heck, for a lot of the 'webmasters' they don't really know what they are seeing when they see directory structure.... They've never made the connection to the more or less analogous 'file cabinet' in the real world with it's drawers and files. And that's a decent analogy if you are telling them about scriptpath, just like finding a file in a cabinet, you have to know in which building[domain- http://www.etc] office resides [root directory] and the cabinets [sub-directories] and drawers [next level sub directory] to the files [all the stuff they upload. Not perfect but pretty realworld visual. ?? Ah well, just wanted to put in my two cents,

Ruth

Poster: bobwill
Dated: Monday September 22 2003 - 15:17:24 BST

Don't force me to change all my "htm" because some folks cannot understand the "scriptpath" variable. I believe that there is so much confusion because of a lack of documentation and examples about the "scriptpath' variable. I think that you assume that people using the menu are javascript literate. Wrong assumption

If the "scriptpath' variable is causing you a lot of questions to be asked them try to explain it all in one place, rather than having to search thru numerous forum questions to get the answer. Summarize and publish the "Doc". Give examples using both "relative and absolute" addressing. Don't talk techie. I develop my menus on my personal PC and FTP them to the server. Someone else develops menu directly on server. What is
difference betwen these two methods.

Also the answer from "jgillet", " As for me, when my sites start getting 'deep' I use includes for the calls, so it makes no difference. ", is a perfect example of what I am talking about. What the heck is an "includes". I have a hunch, but give an example. Techies just assume everyone else understands, because it is such a "simple" thing.

Poster: Andy
Dated: Monday September 22 2003 - 15:33:33 BST

For starters, the scriptpath has now been removed as it was causing too much confusion. Not just for the newbie's but even for the more seasoned user. As the only reason we used it was to continue support for Netscape 4.0 we thought it wise to go back to a similar method that was in used version 3.0

On the issue of not explaining deeply enough. It's tough call. Knowing how to explain something giving enough detail without being patronizing is very difficult. I think in general the answers on this forum are pretty good and it's a very difficult job for the more complex stuff.

Documentation is something we are constantly working on and I do agree that it is very important to get this right.



It's a HUGE difference. Basically you are developing for a completely different system. The Internet and all that surrounds it is based on Unix and only Unix. These problems are only now apparent because Microsoft decided it wanted a piece of the action. When you develop a website on a PC you are using a DOS based file system which uses c:\root\dir\ to point to files Unix uses hd0:/root/dir/ and is the basis for the http, ftp, https protocols i.e. http://website.com/root/dir

In reality it's so much better to develop a website on a web server. Microsoft bundle both Personal Web Server and Internet information Server with their OS's, these are not that complicated to install and it means you can perfectly emulate a web server from your desktop.

I could go on all day about this but I need to get back to work

Hope this clears up one or two issues
Andy

Poster: John
Dated: Monday September 22 2003 - 16:09:11 BST


All ya had to do was ask

OTOH, an include is a pretty standard item in HTML coding, and its function should be known. It is not "techie". Why no example? For that very reason, and the fact that the syntax is slightly different depending on the particular language you're using - HTML, CFML, PHP, etc.

We have to assume some level of knowledge here. To answer every question in step by step detail would not only be a giant waste of time (in most cases), but waste of server space as well. Again, if an answer is not understood, just ask.


You forget, we're still working with a beta system here. Changes will happen in such an environment. If that's not acceptable then simply wait for the final release.

I disagree. The problem, IMHO, is that folks don't bother to read what has been posted. The docs explain it, and in the versions that still contained it, Andy had very clear notes in the code just below the scriptpath variable. They clearly stated both a leading and closing / was required. All the questions I dealt with involved incorrect paths because folks did not bother to read that. We saw everything except /path/.

Further, the information contained in scriptpath has nothing to do with Javascript. It is simply asking where certain files are located on your server - path info, not Javascript info.

Why was it explained in many different places? Because folks asked the same question over and over in many different places, rather than use the excellent Search feature built into the Forum.

Poster: Ruth
Dated: Monday September 22 2003 - 21:20:10 BST

OK, to get back to the first subject..... What is it we're supposed to do now? Do we still upload all the same files but not put the scriptpath in the one file and put the coding you gave instead? I've not gotten mine up yet, I am just on the point of putting everything on the web so I want to make sure I do it the correct way....Thanks a bunch.

Ruth

Poster: John
Dated: Monday September 22 2003 - 21:32:37 BST

Exactly right. More info is in the install file included in the download.

Poster: bobwill
Dated: Tuesday September 23 2003 - 2:01:24 BST

I still disagree on one point. My "scriptpath" variable does not have leading and closing "/". It works for me without them. My 'scriptpath' variable conatains the exact "url" of my server that I am using. that is "http://www.mysite.com/"

Also you state that this a beta version. Not so. Your statement says that you will not longer support any version except V 5.0.

Mr. "jgillet" once again evaded my question. He states "OTOH, an include is a pretty standard item in HTML coding, and its function should be known."

What do you mean it is a standard item, and what is "OTOH"??

I am sorry to be such a pain in the "A--", but you still need to explain things in terms that us "dumb A--' understand.

You need to have some one write your documentation that has no knowledge of your system so they can write in from a total netural prospective.

Poster: Ruth
Dated: Tuesday September 23 2003 - 4:48:47 BST

hmmm, does that mean we need to download version5 again? Sorry, I'm confused . All I have is what I downloaded...when it first came out... the original that tells about script path. Is there another version we need to download now with the changes in it?

Ruth

Poster: John
Dated: Tuesday September 23 2003 - 14:51:03 BST


Definitely. You are way behind, Ruth. As of this message, the current v5 is...

Version 5.0 Release Candidate 11.0 Built: Monday September 22 2003 - 14:57

This item can be found towards the top of each of the 3 main code files. You do read the comments - right?

Note that the 'Built" item is important. The 'Release Candidate 11.0' number may or may not change with every update, therefore the date becomes your key to a new post.

I do not post a new message every time there is a minor update (just when the RC number goes up). Sometimes there's one a week, sometimes less, and sometimes, as in the last one, only 2 days between new versions.

Poster: John
Dated: Tuesday September 23 2003 - 15:18:15 BST


Whatever. It's a moot point, anyway, since scriptpath is no longer a part of the system.

Excuse me? I didn't realize you were part of the development team. You do realize that RC stands for "Release Candidate", which is NOT a final version. Granted, it's a step up from beta, but still, as I said, subject to changes and updates.

Correct. What's your point?

I mean just what I said - an include is a command used by programmers at all levels to keep from re-writing frequently used pieces of code.

As for "OTOH", about as easy as an Emoticon - "On The Other Hand", which has nothing whatsoever to do with HTML or coding.

As a former magazine editor, I believe Andy has done an excellent job of writing the docs. They are, as is the menu, still in beta (rough draft), but I don't see any major changes coming along for them.

As for, "...have some one write your documentation that has no knowledge of your system...", how could that be possible? If you were asked to write a maintenance manual for a Boeing 777, and had absolutely no knowledge of that aircraft at all, could you do it?

A certain level of computer and HTML knowledge has to be assumed for this system. It is basically easy, but not for the absolute rank beginner. We try to answer all questions as clearly as possible, again with the assumption of basic understanding, and without 'talking down' to anybody.

Poster: Hergio
Dated: Tuesday September 23 2003 - 20:33:11 BST

I feel the need to say something here. First of all you are coming across quite rude and seem to be taking things personally for no apparent reason. Everyone here has been nothing but helpful and have never declined to help someone or even explain things 8 times with ever greater detail.

As John said twice, this menu is two things. One, its still in RC, so it is NOT final. Technically it doesnt really NEED to even be published to everyone, rather, it could be released to a select few and milonic only support them. But instead, they wanted it out there so people could begin experimenting, implementing, and getting to know the new code. Secondly, this menu is done in javascript and HTML. You need to know practically nothing about HTML (3 lines of <SCRIPT>) and you need to know some of the basics of javascript. If you dont know javascript, take it upon yourself to learn alittle about it and its terminology so you can follow things alittle better. We don't exactly talk that advanced on this forum, BELIEVE ME we don't. And we're also not here to give you a course in javascript either. Taking it out on the creators of the menu for your lack of programming experience on a product that is still in development is pretty short sighted, IMHO (in my humble opinion).

So all that aside, you are having problems...fine. Ask the questions and we will answer them, every time. The menu is still changing so if you don't like it, wait until it IS final and there IS final documentation. Considering what all the creators of this menu are doing and still managing to get some docs out there is pretty good.

But come across the way you have been, and don't expect to get much in return. I don't like helping people that refuse to help themselves.

Poster: bobwill
Dated: Wednesday September 24 2003 - 14:41:35 BST

OK, I apoligize for my attitude. I do like the menu and I have been trying to learn more about javascripts. So with that being said here is my question. I had the "Scriptpath" variable set to "http://www.myserver.com/". Inside of each "htm" file I had the following code:

SCRIPT language=JavaScript src="javascripts/milonic_src.js" type=text/javascript></SCRIPT>
<SCRIPT language=JavaScript src="javascripts/menu_data.js" type=text/javascript></SCRIPT>

With the new code where do I add the path? I want the path to be a variable rather than hard code.

<SCRIPT language=JavaScript src="javascripts/milonic_src.js" type=text/javascript></SCRIPT>
<script language=JavaScript>
if(ns4)_d.write("<scr"+"ipt language=JavaScript src=javascripts/mmenuns4.js><\/scr"+"ipt>");
else _d.write("<scr"+"ipt language=JavaScript src=javascripts/mmenudom.js><\/scr"+"ipt>");
</script>


Once again, thanks for your fine support.

Poster: John
Dated: Wednesday September 24 2003 - 15:24:50 BST


Accepted, Sir, and thank you. Dave and I really do try to keep things on a level everybody can understand, without 'talking down' or 'talking above' anybody. It can be, to put it mildly, tough

Your 2 calls above indicate you have your menu scripts in a directory called /javascripts/. That being the case, scriptpath would be simply...

This is server-relative addressing - where the directory is relative to the server address. Your server is http://www.myserver.com/, and your structure in the calls says the menu stuff is in /javascripts/, so the relative path is /javascripts/.

Do you mean the path to your menu data file? Typically that would be placed directly after the calls, but it depends on how you are setting up your menu and page structure.

But first, you have...

I would change that to the following...

Note the addition of a / before 'javascripts', and also the menu data call at the end (yours may be named differently, and/or, again, need to be in a different place depending on how you're setting up your page).

The / in front of 'javascripts' makes these calls server-relative, as above. This means, regardless of how many levels deep your site may get, the very same calls will still work; i.e., you won't have to re-write the calls with ../javascripts, or ../../javascripts, etc., for different pages.

As for includes, it's a shortcut for code that is reused. In this case...

...could be put on a page all by itself (no <html>, <body>, or any other HTML coding), and saved as, say menucall.htm. Then, anyplace in your page that you would normally put all those lines, put instead...

That 1 line will go get the file with all the Javascript code and automatically insert it in your page. The real benefit here is if something should change in the Javascript calls you need to make the change only in that 1 file, not on every page in your site.

Hope this helps. Post a URL we can look at when you get things up and we'll go from there (assuming you still need help at that point!).

You are welcome.

Poster: Hergio
Dated: Wednesday September 24 2003 - 16:26:48 BST

Thank you bobwill, we would be glad to help you in every way, not matter what it takes.

John, I would just like to catch something you mention that I think is incorrect. The Include you are referring to, John, is what is used in pages that utilize ASP (Active Server Pages); they are pages that end with .asp. Basically what this means is, the server that the pages are coming from must be able to serve up .asp pages and only then can you use the <!--#include file = "" --> directive. Such servers most likely are running Microsoft's Internet Information Services. It seems bobwill is using pages with .htm on them, which means the server is not going to parse up the page beforehand and throw in whatever the include directive is referring to. With HTML files, there is no real easy way to include other files...and especially in this case where you really arent including other htm files, but js files. If his server supports it, he could change all his page names to .asp and then it may work.

So basically you are probably going to have to put in those couple lines of <SCRIPT src='...'></SCRIPT> includes that John said, into each page. These types of includes are 'javascript includes' that are done in the HTML and the actual js code is brought into the page once it gets down to the browser.

Now regarding the paths to your files. When John said your path should be /javascripts/ that means that the javascript directory should probably be in the root of your site. What this means is basically you should be able to get to your menu files by typing into your browser's address bar..."http://www.yourdomain.com/javascripts/milonic_src.js". If you CAN do this, and you are keeping ALL of your menu source files in that javascripts directory, you can then access those files from anywhere on your site using the path /javascripts/menuFilename.js. Therefore, the code that john gave you would do that and you would just paste that code into every .htm page. Then if any changes occur to the milonic_src, mmenudom, or your menu_data files, you can just change them in the one spot and all .htm files are looking at the same files. The / in front of the javascripts directory essentially says "start at http://www.yourdomain.com and then look for a directory called javascripts inside of it, and work from there". Get it?

I would recommend looking into your server supporting ASP. Because if it is, you then easily change the names of your pages (and links) to end with .asp and then you can just create one file which holds the lines of code to do the includes and include it into all your files (thats what I do). You dont have to change any html or anything inside of a .htm file for it to successfully by a .asp file. It just gives you the ability to do more in the page before the user gets it. But if you would rather stick to your guns with the htm files, thats fine, just follow our guidelines. The scriptpath is pretty much gone for good so you SHOULD be ok with the way we are including all the menu files, it SHOULDNT change. But as always, take it with a grain of salt because it COULD in the future.

Hope you got everything. If not, let us know!!

Poster: John
Dated: Wednesday September 24 2003 - 17:25:42 BST


Gotcha, oh great JS man from the east!

Using that exact format here on IIS servers with .htm pages, not to mention I use it on my personal site with Apache and .html. Granted, some setups may require .shtm or .shtml if the option is not set.

That's one for Arizona

Poster: Hergio
Dated: Wednesday September 24 2003 - 17:30:43 BST

Hey wait, you mean to say you got <!--#include file = "filename.html" --> to work in an html file? I did it here with IIS 5.0 on a Win2000 server and got nothing but a commented line in the output file.

Do you have your IIS setup so that you parse both asp and htm(l) files using the same ISAPI dll's?

Poster: John
Dated: Wednesday September 24 2003 - 17:36:01 BST

Absotively

I didn't set up the server, but I know they (IT) suddenly decided one day that it would improve performance if they didn't parse for SSI in non-shtm files. That would have meant 400+ pages I needed to change, and well over 1,000 links. Not happenin'. They turned the parse back on.

Poster: Hergio
Dated: Wednesday September 24 2003 - 17:40:59 BST

Then take that point back! You're in a very unique case...bobwill might not be able to do that ya know! Man, you had me goin. I thought everything I knew was bogus!

Poster: bobwill
Dated: Tuesday September 30 2003 - 17:56:58 BST

I finally got an answer about my server support and "ASP" is not supported. I did get the calls "server-relative" to work with the "/" being the root directory. I still have one thing that I want cleared up. I understand that a line of code such as "<SCRIPT language=JavaScript src="/javascripts/milonic_src.js" type=text/javascript></SCRIPT>" is what you refer to as a "Javascript Include".
Can this type of "include" address a "js" file that contains all of the following, thus only having one line of code to add to each "htm' file??

<SCRIPT language=JavaScript src="/javascripts/milonic_src.js" type=text/javascript></SCRIPT>
<script language=JavaScript>
if(ns4)_d.write("<scr"+"ipt language=JavaScript src=/javascripts/mmenuns4.js><\/scr"+"ipt>");
else _d.write("<scr"+"ipt language=JavaScript src=/javascripts/mmenudom.js><\/scr"+"ipt>");
</script>
<SCRIPT language=JavaScript src="/javascripts/relative_data.js" type=text/javascript></SCRIPT

Poster: John
Dated: Tuesday September 30 2003 - 18:30:09 BST


Semantics, I guess, but to me it's a call to a javascript file, not technically an include (which is 'usually' a file with HTML). Yes, they perform the same function (get some code and add it to the page), but I'm being picky only because the syntax is entirely different for each.

Short answer is yes, if your server understands includes.

Put...

...in a file by itself - no doctype, <header>, <body>, etc. Save it as, say, menucall.htm.

In your HTML, add the following line where you want the call to the JS to be 'included'...

Note the syntax carefully - NO space at the front end, but there is a space between htm" and -->. Also note the exact syntax may be different on your server, AND it may be necessary to change your file suffix to .shtm or .shtml. Again it depends on your server/host.

Poster: bobwill
Dated: Tuesday September 30 2003 - 18:31:02 BST

Never mind, I think I got it figured out. I created a "js" file with each line of the required code and that code was generated using the "document.write" statement. So I ended up with a "js" file that contains: Seems to work.

document.write('<SCRIPT language=JavaScript src="/javascripts/milonic_src.js" type=text/javascript></SCRIPT>');
document.write('<script language=JavaScript>');
document.write('if(ns4)_d.write("<scr"+"ipt language=JavaScript src=/javascripts/mmenuns4.js><\/scr"+"ipt>"); ');
document.write(' else _d.write("<scr"+"ipt language=JavaScript src=/javascripts/mmenudom.js><\/scr"+"ipt>"); ');
document.write('</script>');
document.write('<SCRIPT language=JavaScript src="/javascripts/relative_data.js" type=text/javascript></SCRIPT>');

Poster: Hergio
Dated: Tuesday September 30 2003 - 18:33:40 BST

Nice job bob, I actually tried that previously and I couldn't get it to work perfectly. Got little errors here and there. I kinda gave up on it, thinking there was no easy way to include js files using other js files. But nice work, glad you figured that out. See, you're already on your way to being an expert!

Poster: bobwill
Dated: Wednesday October 1 2003 - 13:52:11 BST

I did find out one more thing about the server that I am using. The system adminstrator told me that they support "PHP" type files.
Do you know what the syntax is for doing an "INCLUDE" using "PHP"??

Poster: Hergio
Dated: Wednesday October 1 2003 - 14:27:00 BST

This is regular php include syntax. But I am unsure how you would do the path structure if your menus were located somewhere back down in the root. I know you could use ../dir1/dir2/menu.js but I dont think the server relative addressing works in this case, like the /dir1/dir2/menu.js I dont think would work.

There is also an require statement you can use too. Check out http://www.phpbuilder.com/manual/function.include.php for more info. To get things to reference from the document root, there is a predefined PHP variable that allows you to do this.


Hope this helps.