Opened 15 years ago

Closed 15 years ago

#117 closed defect (fixed)

custom linked files in core javascript

Reported by: mokhet Owned by: gogo
Priority: normal Milestone:
Component: Xinha Core Version:
Severity: normal Keywords:
Cc: mokhet@…


in htmlarea.js we can find the following codes

this.helpURL  = _editor_url + "reference.html";
iframe.src = _editor_url + "popups/blank.html";
this._popupDialog("link.html", function(param) {
this._popupDialog("insert_image.html", function(param) {
this._popupDialog("insert_table.html", function(param) {
this._popupDialog("select_color.html", function(color) {
win ="fullscreen.html"), "ha_fullscreen",
case "about"    : this._popupDialog("about.html", null, this); break;

all this fonctions are hard linked to .html files, if we want to locally update one of thoses files, we have to manually update htmlarea.js which is a bad idea, cause it forces to manually check SVN updates.

I think it would be better to be allowed to update the files when configuring

think we could do it with something like that

HTMLArea.Config = function () {
  var cfg = this;

  this.hardlinked = {
   'reference': 'reference.html',
   'blank': 'blank.html',
   'link': 'link.html',
   'insert_image': 'insert_image.html',
   'insert_table': 'insert_table.html',
   'select_color': 'select_color.html',
   'fullscreen': 'fullscreen.html',
   'about': 'about.html'

Then to update for any reason link.html to my_own_link.php or link.jsp or anything else, we would just have to use the config way

var xinha_config = new HTMLArea.Config();
xinha_config.hardlinked["link"] = 'my_own_link.php';

Hope you see what i mean and that my little example didnt confused too much.

Attachments (1)

configURI.patch (4.1 KB) - added by mokhet 15 years ago.
patch for revision 59

Download all attachments as: .zip

Change History (5)

comment:1 Changed 15 years ago by niko

Instead you could write a very simple plugin that opens my_own_link.php instead of the link.html!

(Like the ImageManager? overwrites the insert-image)

comment:2 Changed 15 years ago by mokhet

it's not very user friendly to do a new plugin to change such files. A plugin for all of thoses files should be provided and in this case it is lot of pain for few needs. It's more efficient to just let anyone configure it easily from the configuration step.

What is better ?

1) Ask users to create a new plugin (kinda complex to understand at first) when they want to change a link or when a new link is added they want to update


2) ask them to update their config files to be acurate with theirs needs ?

the second solution is, at least from my side of view, the easiest way to satisfy everyone, both you (devs) and us (users).

For second argument, i'll use the fact that it is better to have only one place to stock uris locations and not have them lost somewhere in all the code.

i attach the patch i have for revision 59, my first SVN patch, hope it's not too messed :P

Changed 15 years ago by mokhet

patch for revision 59

comment:3 Changed 15 years ago by niko

i let gogo decide if he will include this patch.

comment:4 Changed 15 years ago by gogo

  • Resolution set to fixed
  • Status changed from new to closed

Looks good, committed in changeset:63

Note: See TracTickets for help on using tickets.