View Complete Thread | FoxWeb Forum Home
Date:    Msg ID:   
From:    Thread:   

Thanks for the reply to "Trying to use.FWX with Netscape Server".  That fixed one of the issues.  I have gotten .fwx files to be processed by FoxWeb.  I'm still getting some errors there, but I think I can see my way through those.  

Of greater concern is the formation of URLs to our existing scripts.  We've got eight years' worth of systems that use URL's of this format with FoxWeb 1.29:

"/foxweb/" is just foxweb.exe renamed without the extension.  I did that out of paranoia back in '97 or so because seeing .exe in the URL just made me nervous.  Ahh...youth.  Anyway, I can fix that issue one way or another.  (at worst, a web server redirect)  I expect I can do this in such a way that existing links will work.

"PreviousWork" is the function name in the program file "/db/pub/pub" .  /db is a root folder on the hard drive.

So now I've installed Foxweb 2.6 on our edit server.  The URL above does not work with this version.  It seems the only way I can get that page to work is with a URL like this:

(If this link doesn't work for you, that mean's I'm still experimenting with other options.  You should get "Please Telephone KET", or better yet, a list of lessons)
I've left the .exe on the current foxweb.exe distribution, as it doesn't work at all without.  As I said, I realize now I was kinda stupid for doing that, and I can deal with that.  

What would be a MAJOR burden is the change in the logical path.  In v1.x, the path to the program followed the "@".  Now the docs say the script_path comes before the procedure name and "@", and and that the script_name comes after the "@".  Is this correct?  Or have I been doing it wrong for all these years and it just happened to work despite my ignorance?

Is there a fix for this under v2.6?  I've tried setting "Full paths in URLs" both ways, and found I need it on for "/db/pub" to work.  However, that still doesn't allow the old-style URL's to work.

Changing the URLs to the new syntax would introduce several problems:

  • I've got code that parses the URL for access level (public, student, teacher, etc.) that authenticates users, selects appropriate templates, and decides various code branches.  Most of that is centralized in fw_enter.prg, so it wouldn't be too bad to fix that.  There are a sprinkling of other programs that would be affected as well...they would take a fair amount of work to ferret out.
  • I'd have to change all my dynamic links to use the new syntax.  Fortunately, nearly all are written by my own URL() function, so that's probably a one-stop fix. 
  • Links from hundreds of flat files on our site would need to be changed.  That's what interns are for, I suppose.
  • Links from other sites...two years from now they still would not all be fixed.  This of course drives the search engine rankings.  Go search Google for "German distance learning", "physics distance learning", "latin distance learning", or "humanities distance learning", etc. and you'll generally find us in the #1 slot.  Search for "Distance Learning" and we're usually in the top 25.  You can certainly appreciate my apprehension at changing absolutely anything that will reduce the pagerank of any of our pages. changing our URL's mandatory to upgrade to 2.6?  Or have I just plain missed something in the docs?  I really, really don't want to change all our URL's if I can avoid it.  Even if there is a performance penalty, I'll take it.  Losing backward compatibility would seriously hinder upgrading the product.  That is a shame, as I'm eager to upgrade to VFP 8.0

Looking forward to your reply,



David Hempy
Internet Database Administrator
Kentucky Educational Television
(859)258-7164  -  (800)333-9764