Yet More Questions: getParentElement() generates fully qualified links

Yermo · 2005-03-12 19:10:51

So I'm fighting a losing battle with Xinha links always coming out fully qualified in FireFox under Linux.

For some reason, the current Xinha version insists on inserting fully qualified links. To demonstrate highlight a section of text, click the link icon, enter "/test.html", and click OK.

Now look at the source; you should see a fully qualified http://blah.com/test.html link. As far as I can tell this is being generated by the section of code in htmlarea.js:2777:

this._popupDialog("link.html", function(param) {
    if (!param)
      return false;
    var a = link;
    if (!a) try {
      editor._doc.execCommand("createlink", false, param.f_href);

      a = editor.getParentElement();

      // for debugging ....

      alert( a.href + " param was " + param.f_href );
...

The param.f_href that's passed in has the correct link location but if you check a.href after getParentElement() it contains the fully qualified link (with the domain name).

Unfortunately for my application this is a Big Problem(tm).

I'm guessing when createLink (via editor._doc.execCommand(..), returns, the current selection contains the newly created link. This is why getParentElement() is being used to retrieve it?

I'm guessing that the browser is generating the fully qualified link ... but why? Something in the configuration of it?

I've verified that that old HTMLArea beta code did not have this behavior; but it looks like it's making the same execCommand() call ...

-- Yermo

Yermo · 2005-03-12 19:22:31

Sometimes you have to phrase a question to know what to look for. It looks like my problems come from htmlarea.js:

HTMLArea.prototype.outwardHtml = function(html)
{
  html = html.replace(/<(\/?)b(\s|>|\/)/ig, "<$1strong$2");
  html = html.replace(/<(\/?)i(\s|>|\/)/ig, "<$1em$2");

  // Figure out what our server name is, and how it's referenced
  var serverBase = location.href.replace(/(https?:\/\/[^\/]*)\/.*/, '$1') + '/';

  // IE puts this in can't figure out why
  html = html.replace(/https?:\/\/null\//g, serverBase);

  // Make semi-absolute links to be truely absolute
  //  we do this just to standardize so that special replacements knows what
  //  to expect

  html = html.replace(/((href|src|background)=[\'\"])\/+/ig, '$1' + serverBase);

  html = this.outwardSpecialReplacements(html);

  html = this.fixRelativeLinks(html);
  return html;
}

Why the second html.replace() to make all the links fully qualified? That makes any content generated using Xinha non-portable (in my case I'm copying databases with content from live servers to test servers, changing the domain name ... and have to have all the content links "just work")

I would /really/ like semi-absolute links to remain semi-absolute so that content is portable.

Thanks,

-- Yermo

Yermo · 2005-03-12 21:05:25

Just when you thought it was safe.

In the Linker plugin, under FireFox, if you select an existing link it will display in the Dialog on the right as a fully qualified domain name. I think if it's a local link it should drop the hostname part; again to make content portable between sites.

Is there a better way to do this?
in linker.js around line 145:

else
  {
  // Normal
  // 2005-03-12 YmL: if it's a local link, strip out the hostname and protocol.

  if ( a.hostname == this.editor._doc.location.hostname )
    {

    // need to pull out the pathname and query_variables part. Unfortunately 
    // a.pathname doesn't contain any query variables so we have to do a replace

    var tmpString = new String( a.href );
    inputs.href = tmpString.replace(/.*?\/\/.*?(\/.*)$/, "$1");

   }
  else
   {

   // since we've got non-fully-qualified URLs we need to strip out the MSIE
   // annoying http://null/ bug ...

  var someString = new String( a.href );

  inputs.href   = someString.replace(/https?:\/\/null\//g, "/");
   }

 inputs.target = a.target;
 }

I need links local to a site not to include the host and port number for the business platform I'm working on (called MOBIE).

Are handling relative links in this fashion something that other people would be interested in?

Last edited by Yermo (2005-03-12 22:21:53)

gogo · 2005-03-13 13:02:01

I believe that this all extends from a problem in IE, where by IE will make any link a full URI (ie including http:// ) wether you want it or not, at least if I'm remembering correctly.

I wanted at some stage to standardize that between the browsers so I must have made the links absolute - it's not a problem for me because I have "special replacements" run on the outgoing html to turn them into relative links where appropriate. But obviously it's something that should be changed really.

If you can come up with a good way of fixing that, I'm ok with it.

Edit: by fixing it I mean making links relative or absolute within server. Of course, relative to what is the question, I guess a "destination URL" would have to be passed in via config so that relative urls could be calculated from that.

Yermo · 2005-03-13 14:33:06

gogo wrote:

But obviously it's something that should be changed really.
If you can come up with a good way of fixing that, I'm ok with it.
Edit: by fixing it I mean making links relative or absolute within server. Of course, relative to what is the question, I guess a "destination URL" would have to be passed in via config so that relative urls could be calculated from that.

Yea, for the completely general case that's probably a good way of doing it. For my purposes having the URL's be relative to the DOCUMENT_ROOT solves my problem.

Unfortunately, there are alot of places where one has to tweak the URL for display, because you're right. IE changes it ... sometimes to http://null/ ...

We probably want some centralized fixupURL() method .. because we need it in the status bar of the linker, in the source, in the input field in the linker, etc. Once all urls are run through that central method we can easily modify it's behavior.

Again, I appreciate all the help. I'm slowly coming up to speed. The weird way javascript works is starting to make some sense. It'll be a little while yet before I'm confident enough to start committing large changes. (which is why you haven't seen alot of commits from me. I'm still struggling with the language a bit; I know what i want to do but have trouble finding the right methods, etc.)

Last edited by Yermo (2005-03-13 14:38:55)

niko · 2005-03-14 05:19:07

isn't this function the stripBaseURL-function?

use these settings:
// specify a base href for relative links
this.baseHref = null;

// we can strip the base href out of relative links to leave them relative, reason for this
// especially if you don't specify a baseHref is that mozilla at least (& IE ?) will prefix
// the baseHref to any relative links to make them absolute, which isn't what you want most the time.
this.stripBaseHref = true;

(i'm sorry if you are talking about something completely different )

irobotst · 2005-03-16 12:32:02

We had a problem with firefox. We wanted to use allways the complete link, but when we moved an image in firefox by drag'n drop he was allways changing the links to relative links. Thats not the problem, but he changed the links like ../../../subfolder2 and mostly he has forgotten to add the first subfolder1 (../../subfolder1/subfolder2). This behavior was with HTMLArea3.0, I couldn't test it with xinha yet.

Xinha Discussion Forum

Announcement

#1 2005-03-12 19:10:51

Yet More Questions: getParentElement() generates fully qualified links

#2 2005-03-12 19:22:31

Re: Yet More Questions: getParentElement() generates fully qualified links

#3 2005-03-12 21:05:25

Re: Yet More Questions: getParentElement() generates fully qualified links

#4 2005-03-13 13:02:01

Re: Yet More Questions: getParentElement() generates fully qualified links

#5 2005-03-13 14:33:06

Re: Yet More Questions: getParentElement() generates fully qualified links

#6 2005-03-14 05:19:07

Re: Yet More Questions: getParentElement() generates fully qualified links

#7 2005-03-16 12:32:02

Re: Yet More Questions: getParentElement() generates fully qualified links

Board footer