Xinha Discussion Forum

The problem is that the API we use is not a standard at all it was something MS came up with and Moz *almost* copied a few years back, between IE and Gecko however it's somewhat different (contentEditable vs designMode for one) and buggy.  Theres no way of knowing what, if any, API KHTML, or Opera (or any other browser) will come up with to allow for HTML editing before time, it's just not a standard and thus an't be predicted.

We also must know the browser version in order to fix broken functionality, or even to know what functionality to expect, or what variables with the same names actually represent (IE and Gecko sometimes use the same name but different values).  Additionally, particularly in IE, some functionality is exposed but it either doesn't work or doesn't work all the time (I'm  specifically thinking of set/getAttribute DOM methods here).

I agree for DOM standard stuff, checking for functionality (or better inserting missing functionality into prototypes ourself (where possible, IE is not complete in that regard)) is better than sniffing, but in some cases it is still necessary to sniff.

Hmm, I think this would be a pretty specific implementation rather than a general-use plugin?  If you want to have a go at creating a plugin though it's quite easy, a good one for example might be the Linker plugin.

Trac, so we can track them

That'll be it!

You want to commit that? 

NB: Before you commit do a diff on the file to make sure that there are unnecessary changes (indentation changes etc) lest we end up with huge changesets for no reason.

Yeesssss.  Probably it helps if you know html to understand what Xinha is.  Basically it replaces <textarea> tags, like the one you wrote your forum posts in, with a graphical editor allowing you to for example just press the "bold" button after highlighting foobar rather than writing <bold>foobar</bold>. 

It doesn't have any file loading/saving capability, nor any capability oter than providing a graphical means to markup HTML.

Best you see the examples page: http://xinha.gogo.co.nz/cgi-bin/trac.cgi/wiki/Examples

Yes, CMS = Content Management System.  It's such a broad area, and people have lots of different definitions of it.  Some think that CMS means a PHPNuke type site (umm, blogish news/community site), but we refer to it as something wider than that, simply a web browser based system which allows the management of website content (html, images etc).

A normal HTML textarea, just like I'm typing in here, only allows plain text (which could of course be HTML "source code", or any other textual content).  Xinha, and other WYSIWYG (almost) allow one to use a more "word processer" type interface to edit (ultimatly) html source code in the textarea, displaying how it will (roughly) look on the site, instead of a whole lot of plain text source code.

Well known example, perhaps the Hotmail mail editor (I think it allows bold etc, been a while since I've used Hotmail ), to, say bold something you hightlight the something and click bold.  Behind the scenes the editor writes html code into the textarea, like

<strong>the thing you bolded</strong>

the user doesn't know that, and just as well, because most users wouldn't understand it.

That is what Xinha, and other editors do, think of it (almost) as a word processor embedded into your web browser used for editing things that the website developer provides for you to edit.

Hmm, it does sound familiar.  I'll hunt it down and have a look later.  Anybody else seen it?

I'm not a great believe in censorship.  As long as nobody gets abusive towards one another or anything, I care not what you write

I think the most widely used Windows client is TortiseSVN, it's quite easy to use - http://tortoisesvn.tigris.org/

Perhaps you would be so kind as to write a "quickstart" page in the Wiki about using TortoiseSVN to checkout the subversion source when you have worked it out, link it off the DownloadsPage if you want, feel free to upload a screenshot to better describe the process

Other SVN clients are listed at http://subversion.tigris.org/project_links.html

Thats me.  I'm "leading" the effort, however there are a number of developers who I hope will be contributing.  Developers who prove themselves capable and responsible will be given commit access to the subversion repository so they can push thier own changes, and changes submitted by other contributors without my say-so, the list already includes more than me.

Thats what the bug tracking ticket system is for.  Any bugs you want fixed, any features you think need be implemented, any patches you have to fix bugs, or add features, anything you need to get the primary developers to see really, it all should be submitted as a New Ticket - http://xinha.gogo.co.nz/cgi-bin/trac.cgi/newticket

That way we can all keep track of development and people can easily see what has been done, and more importantly, pick a ticket that they can handle to do.  The Trac system (http://xinha.gogo.co.nz/) in general allows you to keep an eye on development process, the "Timeline" feature will give an overview of new things in the Wiki and Subversion Repository (if I had time to dig into the source (in Python) I'd also like to get forum posts in the timeline, who's a Python master here?).

Great minds think alike there Chris, 1 forum means more perceived traffic   Nothing kills a project quicker than a ghost town.

Yea, I've used phpBB a good deal before, but frankly it's too heavy, and a big a target for the skript kiddies these days.  So I dipped into the freshmeat.net grabbag and chose punbb, it looked nice and clean, simple and reasonably unknown

The method is something like this, in PHP..

<?php
 $basedir  = realpath($_SERVER['BASE_DIR'] . '/path/to/wherever') . '/';
 $hash = sha1('dir=' . $basedir);
 $_SESSION[$hash] = TRUE;
?>
yourEditor.config.Linker.backend = _editor_url + 'plugins/Linker/scan.php?dir=<?php echo urlencode($basedir) ?>';

The reason for that hash in the session is so that Joe Bloggs can't just go change the directory on the url to whatever they want, you could equally as well just change the $dir = statement in scan.php and skip that whole m'larky above.

Yes.  I'm not a fan of popups, they make life more difficult.  But by the same token I know some people won't like the inline-dialog idea.  To that means I'd like to see it configurable.  I've designed the inline dialog system so that in the (not tooo distant) future it should be possible to determine if you want inline or popup dialogs with a config variable.  At least that's the idea in theory

Yes, what you need to do is have a look at scan.php and see what it returns (it just returns some a nested javascript array, nothng fancy).  Then you can write your own scan.php (or modify the existing) and set the config variable yourEditor.config.Linker.backend  appropriatly.

Sounds good, you have SVN commit, so feel free to put that in, what I'd suggest is just having a config variable Config.debug (might already be one) that turns this functionality on).

Typically, alerts, yep.  When something is bveing troublesome then I'll fire up venkman and set an appropriate breakpoint somewhere so I can examine the situation at my leisure

No I havn't, but it should work fine, give it a try and let us know how it goes   There are a number of "new" plugins for htmlarea (on the htmlarea.com forums) which I would like to distribute with Xinha or make available here as a separate download, but we really need to ask each plugin author if they are ok with that.

The downloads page has what you seek - http://xinha.gogo.co.nz/DownloadsPage

The SVN is more up to date of course, but I'll be making regular packages of the SVN as enough changes are made.  I might make an automatic nightly package also for those who want the bleeding edge without SVN.

I was more thinking splitting the core into three files

core.js
ie.js
gecko.js

core.js contains just pure JS stuff that works everywhere
ie.js is loaded by core.js when running in IE and contains method implementations that are specific to IE
gecko.js simiarly contains specifc to gecko stuff.

Plugins are left as is, just the core gets split.  Thats mostly what makes it such a big load now, all that reimplementing of stuff for one browser that the other browser supports better (equal amounts of that for each browser, neither is blameless).

I don't think it's tooo bad (and I have done the odd debugging run in venkman with it to fix problems).  Once the editor is built basically it's just updateToolbar and execCommand that do the work.  There is room for improvement though.  And I have done so in a few places.

Thats doable now using javascript compressors, at least for the core, plugins add a little.

I'd say about that.  The combined images I did would help immensly there I expect.  As you say, it's (mostly, IE seems finiky about it sometimes) a one time cost.

As regards FCK, I looked at it a while back and I found it's loads of tiny files strewn through piles of directories somewhat difficult to follow.  I don't know if (I think the guys name is Fred?) the developer based it off htmlArea originally, but if so they changed it a LOT.  I havn't played with it enough to know if it behaves better or worse than Xinha/htmlArea at all.  I don't think thier demo had table operations last time I looked.

I'm told they have "40 developers", so a force to watch I imagine.

A friend of mine (also in Christchurch) has more recently looked at FCK (and decided to stick with Xinha), I'll see if I can get him to comment here.