absolute path problem

[William Starr Moake]

Another problem with absolute paths in the WYSIWYG editor I'm putting
together.

The function to toggle between WYSIWYG and HTML modes works except for
one glitch. If you use a relative path for a link, like <a
href="download. htm">Click Here</a>, the editor returns an absolute
path the second time you toggle HTML mode: <a
href="C:\Window s\Desktop\Edito r\download.htm" and even adds file:///
on the third try. This path must be manually deleted before uploading
the page to your web host, which partially defeats the purpose of a
WYSIWYG editor.

I thought I had the problem fixed when I found a hack on a javascript
forum. The poster noticed the relative path was retained if he
manually selected the source code in HTML mode, copied it and then
pasted it. So he came up with a hack to make these operations
automatic.

He said he placed this hack in the toggle script "just before it
switches back to WYSIWYG mode." I have tried inserting it between
every single line of the toggle script with no luck. First I got error
message "object expected" until I embedded it as a second function
called relpath(). Then, as I moved the hack from line to line in the
toggle script, either the editor refused to return to WYSIWYG mode or
it copied the source code into the WYSIWYG mode. I know this works if
you manually select all-copy-paste because I've tried it.

Can anyone tell me where in blazes the hack fits into the toggle
script? The hack creator has apparently abandoned the forum where he
made the original posting.

THE HACK:
function relpath() {
cmdExec('select all');cmdExec(' copy');cmdExec( 'past
e');
sTmp=iView.docu ment.body.inner Text;
iView.document. body.innerHTML= sTmp;}

THE TOGGLE FUNCTION:
function doToggleView()
{
if(viewMode == 1)
{
iHTML = iView.document. body.innerHTML;
iView.document. body.innerText = iHTML;
viewMode = 2; // Source Code
}
else
{
iText = iView.document. body.innerText;
iView.document. body.innerHTML = iText;
viewMode = 1; // WYSIWYG
}
}

[Thomas 'PointedEars' Lahn]

Re: absolute path problem

William Starr Moake wrote:
[color=blue]
> The function to toggle between WYSIWYG and HTML modes works except for
> one glitch. If you use a relative path for a link, like <a
> href="download. htm">Click Here</a>, the editor returns an absolute
> path the second time you toggle HTML mode: <a
> href="C:\Window s\Desktop\Edito r\download.htm" and even adds file:///
> on the third try. This path must be manually deleted before uploading
> the page to your web host, which partially defeats the purpose of a
> WYSIWYG editor.[/color]

Such WinDOS paths are invalid as value of the "href" attribute, even for
local HTML documents. That attribute is of type URI (see HTML 4.01
sections 12.2, 12.3, 12.4 and 13.6.1, and RFC 2396), so if the UA returns
a WinDOS path, you must convert it:

function winDOS2URI(sPat h)
{
if (/^[a-z]:/i.test(sPath))
{
sPath = "file:///" + escape(sPath.re place(/\\/g, "/"));
}

return sPath;
}

If you want to allow absolute local paths in documents to be published
online, your editor needs a pref for the local web root. If the user
wants to publish the document, you need to convert the paths:

function getRelativeFrom Absolute(sPath, sRoot)
{
return winDOS2URI(sPat h).replace(
new RegExp("^" + winDOS2URI(sRoo t) + "/?"),
"");
}

var sRemoteURI = getRelativeFrom Absolute(
theFile.absolut ePath, sLocalWebRoot);

You may have to deal with the remote web root as well.


HTH

PointedEars