Javascript OO question: configuration prototypes

Yermo · 2005-03-10 19:33:30

I think I'm missing something obvious. I'm working on separating out reliance on _editor_url from the ImageManager, Linker and SpellChecker plugins.

Linker is by far the best designed, so I'll focus my question on it. In the linker. js file you have:

HTMLArea.Config.prototype.Linker = { 'backend' : _editor_url + 'plugins/Linker/scan.php' }

The object model in Javascript isn't making much sense to me. If I understand this correctly the Linker properties are being added to every HTMLArea.Config object per the prototype call? And this can happen even after the HTMLArea.Config object exists?

The simple case would be to just define a global variable _backend_url and set it to _editor_url if it's not separately defined.

However, it would be cool to specify a separate backend_url for each plugin, for flexibility. So ideally I"m guessing one would want to be able to access the Config object for Linker from the calling page and set some defaults overriding the prototype.Linker properties defined above.

I guess what I'm looking for is defining some plugin level property from the example page to demonstrate how you would like per-plugin configuration variables passed in .... just defining a global _backend_url akin to _editor_url seems really kludgey to me.

-- Yermo

gogo · 2005-03-11 01:15:57

Yermo wrote:

HTMLArea.Config.prototype.Linker = { 'backend' : _editor_url + 'plugins/Linker/scan.php' }
The object model in Javascript isn't making much sense to me. If I understand this correctly the Linker properties are being added to every HTMLArea.Config object per the prototype call? And this can happen even after the HTMLArea.Config object exists?

Correct, think of prototype as dynamically modifying the class definition itself, example..

<script langage="Javascript">
  var x = [ ];
  var y = [ ];

  // We can of course set object properties (arrays are objects of course)
  y.sayHello = function() { alert('Bugger off'); } // Set an object method

  // And we can dynamically change the definition of the "Array" class
  Array.prototype.sayHello = function() { alert('hello'); } // Dynamically add a class method

  // When you request a property (or method), JS will look for an object one first, and then use the default one if it doesn't exist
  x.sayHello(); // This will use the prototype, because the object doesn't have one
  y.sayHello(); // This will use the object's own one

  // we can change the prototype any time
  Array.prototype.sayHello = y.sayHello; // Now change the prototyped one to be the same as y's object one
  x.sayHello(); // Now x is a bad tempered as y was (still using the prototype)

  // And we can set object specific methods/properties any time
  x.sayHello = function() { alert('hello'); }; // set an object method for x now to make him happy again
  x.sayHello(); // x is in a good mood
  y.sayHello(); // y is not
</script>

however, there is a slight gotcha with the way I have prototyped the configs in,

  // But NOTE, once you get "into" the prototype through accessing a property of an object that doesn't exist 
  // (and does in the prototype) then you are modifying the prototype.
  Array.prototype.someData = { 'a' : 'a', 'b' : 'b'}
  x.someData.a = 'b'; // because someData is coming from the prototype, we are really setting Array.prototype.someData.a 
  alert(y.someData.a); // shown here, y.someData.a == 'b', because it's the prototype

it means that if you naievly do

editor.config.Linker.backend = 'foo'

you will infact change all the Linker.backend values in all editors on the page to foo, because config.Linker is being accessed through the prototype. Of course, that might be what was required anyway. To get around that you need to duplicate the Linker config object into the specifc config object (ie make it an object property you are modifying) before changing them..

editor.config.Linker = HTMLArea.cloneObject(editor.config.Linker)
editor.config.Linker.backend = 'aspecialbackendjustforthisone';

as it so happens however, the way of creating the editors shown in the example (which is the preferred way really) uses HTMLArea.makeEditors to, err, make the editors, and this method happens to conveniently assign each editor a (deep) copy of the default config object using cloneObject, so that you shouldn't need to do the above And by that time all the plugins are loaded and have prototyped thier default config values into the main configuration, so each editor gets a pristine default config all to themselves which they can modify without affecting other editors on the page.

I guess what I'm looking for is defining some plugin level property from the example page to demonstrate how you would like per-plugin configuration variables passed in .... just defining a global _backend_url akin to _editor_url seems really kludgey to me.

Indeed, my preference is for plugin configuration to be put in an object within the config object, as I have done for linker.

niko · 2005-03-11 02:46:03

...so i learned something new about javascript today
thanks!

(as i'm only a try 'n error javascript-coder i only know very little features about this full-features object-orientated-language )

Yermo · 2005-03-11 02:50:03

gogo wrote:

editor.config.Linker = HTMLArea.cloneObject(editor.config.Linker)
editor.config.Linker.backend = 'aspecialbackendjustforthisone';
as it so happens however, the way of creating the editors shown in the example (which is the preferred way really) uses HTMLArea.makeEditors to, err, make the editors, and this method happens to conveniently assign each editor a (deep) copy of the default config object using cloneObject, so that you shouldn't need to do the above And by that time all the plugins are loaded and have prototyped thier default config values into the main configuration, so each editor gets a pristine default config all to themselves which they can modify without affecting other editors on the page.
I guess what I'm looking for is defining some plugin level property from the example page to demonstrate how you would like per-plugin configuration variables passed in .... just defining a global _backend_url akin to _editor_url seems really kludgey to me.
Indeed, my preference is for plugin configuration to be put in an object within the config object, as I have done for linker.

thank you very much for taking the time to answer that. Unfortunately I think I'm still missing something. I believe I'm getting hung up on the order of object creation.

In full-example_body.html, you've got HTMLArea.makeEditors( .. ) which seems to do some actual work.

Now after makeEditors() let's say I go in and change some

editor.Config.Linker.backend = "foo".

For the Linker plugin I see that would work because Linker.backend isn't referred to until much later. However, it seems like plugins could be written that use their config values during construction; which means one might not be able to always change those values after the fact. It'll depend on how the plugins are developed, right? Or am I missing something with how all this works.

I guess I'm wanting to see a method for passing in plugin default value overrides when everything gets created ... but maybe that is not the "javascript way" ... it feels somehow unnatural to go in after the object is created and "backpatch" new values into it ....

Maybe a specific example will highlight my conceptual cramp:

If I wanted to, for instance, change:

HTMLArea.Config.prototype.Linker = { 'backend' : _editor_url + 'plugins/Linker/scan.php' }

to

HTMLArea.Config.prototype.Linker = { 'backend' : _backend_url + 'plugins=Linker&p=scan.php' }

from the full_example_body page for every editor on the page do I loop through xinha_editors at STEP 4 and do a

xinha_editors.(some field).Config.Linker = { 'backend' : backend_url + 'plugins=Linker&p=scan.php' }

That doesn't seem clean at all .... I must be missing something.

Yermo · 2005-03-11 22:04:17

I think I've found my mental cramp.

In the case of the Linker plugin it looks like the callback is getting invoked when the editor loads so I'm guessing the plugin doesn't actually get invoked until the HTML.startEditors() call?

Thus you can safely set parameters into your plugins before that point.

I mistakenly thought the plugins were getting "invoked" at STEP 3 ... which would make setting/overriding parameters in them after the fact problematic.

gogo · 2005-03-12 12:02:59

Yermo wrote:

I think I've found my mental cramp.
In the case of the Linker plugin it looks like the callback is getting invoked when the editor loads so I'm guessing the plugin doesn't actually get invoked until the HTML.startEditors() call?
Thus you can safely set parameters into your plugins before that point.
I mistakenly thought the plugins were getting "invoked" at STEP 3 ... which would make setting/overriding parameters in them after the fact problematic.

Bingo LoadPlugin() only does just that, loads the main javascript file(s), the realwork of a plugin doesn't begin until it's registered to an editor with registerPlugin, which is a method of an editor object.

gogo · 2005-03-12 12:08:59

Yermo wrote:

That doesn't seem clean at all .... I must be missing something.

You'd do that in the default config first, in step 3.

xinha_config.Linker.backend = 'whatever';

then in step 4 that is used a default config, when you get the editors out the other end they have deep-copies of the default config which you can tailor individually for each editor in step 4 before you "start" the editors in step 5.

Plugins shouldn't work with the config values until they are registered to a plugin at the earliest (they will see the default values then), preferably not until the editor has been generated (the plugin object will have an onGenerate() method called on it when the editor it is registered to gets generated).

Yermo · 2005-03-12 14:19:59

gogo wrote:

Plugins shouldn't work with the config values until they are registered to a plugin at the earliest (they will see the default values then), preferably not until the editor has been generated (the plugin object will have an onGenerate() method called on it when the editor it is registered to gets generated).

Ah! Ok. That is much cleaner than it at first appeared (I figured I must have been missing something).

That gives me what I need. Thanks!

Yermo · 2005-03-16 16:09:18

gogo wrote:

Yermo wrote:
That doesn't seem clean at all .... I must be missing something.
You'd do that in the default config first, in step 3.
xinha_config.Linker.backend = 'whatever';

this is a duplicate of another post I made ... but I was researching through old posts to see if I missed something.

I'm running into a problem. For some reason any properties I'm setting in xinha_config are getting lost due in htmlarea.js HTML.makeEditors(). (I'm trying to set pageStyle ...) so I do a

xinha_config.pageStyle = "p.someStyle { margin: 0px;}";

in the calling page Then in HTMLArea.makeEditors.

HTMLArea.makeEditors = function(editor_names, default_config, plugin_names)
{

alert( "default config is : " + default_config.pageStyle ) ;

  if(typeof default_config == 'function')
  {
  alert( "FUNCTION" );

    default_config = default_config();
  }

Anything I add to xinha_config is getting overwritten and I don't understand why; so pageStyle gets lost as soon as the:

default_config = default_config();

gets executed.

Any insights would be greatly appreciated.

Thanks,

-- Yermo

Xinha Discussion Forum

Announcement

#1 2005-03-10 19:33:30

Javascript OO question: configuration prototypes

#2 2005-03-11 01:15:57

Re: Javascript OO question: configuration prototypes

#3 2005-03-11 02:46:03

Re: Javascript OO question: configuration prototypes

#4 2005-03-11 02:50:03

Re: Javascript OO question: configuration prototypes

#5 2005-03-11 22:04:17

Re: Javascript OO question: configuration prototypes

#6 2005-03-12 12:02:59

Re: Javascript OO question: configuration prototypes

#7 2005-03-12 12:08:59

Re: Javascript OO question: configuration prototypes

#8 2005-03-12 14:19:59

Re: Javascript OO question: configuration prototypes

#9 2005-03-16 16:09:18

Re: Javascript OO question: configuration prototypes

Board footer