Xinha Discussion Forum

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.

Can you post the URL where I can see what you've done, I don't quite follow.

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.

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

That would be great, then you can contribute it to Xinha! Probably the closest plugin to base smilie off is CharacterMap, it pops up a window and allows to insert various characters, you'rs wants to popup a window and allows to insert various images.  Should be almost identical

It's tricky at the moment, basically for sme unknown reason, back before I had even released the htmlarea-fork, let alone Xinha, I changes the toolbar to require explicit "linebreak" items to break lines in the toolbar.  I don't know why I did it, and I regret doing it because it really isn't a good idea, but I don't want to change it back just yet as the whole toolbar thing needs a rework anyway to make it easier for plugins to put stuff in sensible places.

For now, best if you define your own toolbar in the configuration object, see htmlarea.js.

Grrr, rassn frassn piece of crap.  Fixed again   And I was actually considering using sqlite on websites at one stage.  I just can't believe how damned unstable it's being.  It's not even like the data is corrupt because I did a full sql dump, fixed up the broken tables (just recreated them) and reloaded everything into a fresh database.

I can't find any mention inthe tickets at edgewall about sqlite db's getting corrupted, there were a couple about the BDB thing though.  Oh well, fingers crossed.

Now if I could just figure out why Firefox chews through CPU when accessing sites locally on this workstation...

smilie:      [ "Smiley", "smiles.gif", false, function(e) {e.execCommand("Smilie");} ],

should be

smilie:      [ "Smiley", "smiles.gif", false, function(e) {e.execCommand("_Smilie");} ],

Hi Yermo, feel free to include any (preferably working ) plugins you want in the plugins directory, just make sure there is a README or something to show what's required to run them, and then add to the example (mostly you should be able to just add a new checkbox to the example menu and it will work).

Thats fixed now.

The plugin pushes the button into the toolbar.  That whole area needs to be looked at again as it's not the best way in terms of configurability.

Yes I see, so the users would switch to html mode ("source view") and enter these tags.  Well, as I say, currently it's not possible, the editor can only deal with valid well formed HTML, that's just the way these editors (that use the browser's API for editing) work, can't be changed (short of editing the browser source code!)

What has been requested is a way to allow showing the "server code" in source view, then transforming it to something embedded in a little "shield" image's alt tag in WYSIWYG view, and of course transforming back to the server code when you click submit.

This is all well and good, but it won't happen soon (unless somebody else cares to write the plugin, it wouldn't be hard I just don't have time right now), and it will ONLY work for simple server markup, it won't be possible to do something like...

<table>
<?php foreach($blah as $foo) { ?>
<tr>
<td><?php echo $foo ?></td>
</tr>
<?php } ?>
</table>

because there is no way to transform that into valid HTML to display in WYSIWYG mode, if we tried it would turn into something like...

<table>
<img src="php.gif" alt="foreach($blah as $foo) {" />
<tr>
<td><img src="php.gif" alt="echo $foo;" /></td>
</tr>
<img src="php.gif" alt="}" />
</table>

which is obviously invalid and the browser wouldn't have a clue how to render it.

Yes, bugs take priority over branding though :)  Changing the internal object names will make us incompatable to HTMLArea, which I would like to avoid until Xinha v1.0 is out really.

Sqlite fell over (trac uses sqlite) on one of it's tables for some reason, I've restored it.

Here's a link on character encoding which may be useful in this discussion
http://www.crazysquirrel.com/compgen/form-encoding.php