Xinha Discussion Forum

not from that little, did you follow the newbie guide?  does the example work for you?

As yermo has said, he has talked to me about forking.  I have no objection, nor could I have without being a little hypocritical, to yermo forking.  But that said, there has to be a reason for the fork, something to differentiate the two, and as it is, I don't really see that there is enough to differentiate the two and think that a fork would just confuse matters.

I'm not keen on the idea of the Xinha source requiring anything other than javascript, I'm also not keen on it requiring preprocessing prior to use - the reason for this is because I like to be able to just svn update to a specific revision in my production systems.

I'm also not keen on having a large source code explosion (yermo has mentioned the code is about 300% larger now) because of the extra debugging messages - the way I work when debugging javascript code is a combination of reading the source, temporary messages, and venkman to step through and examine the stack when things get tricky.  As for using these messages to "get aquainted" with the code, I dunno, maybe it's just me but I find when I'm inheriting code that it's easy enough to simply read it provided it's nicly formatted (getting code without linebreaks is an entirely different thing), tackling changes one bit at a time you soon get to know how the system works.

Yermo's work on commenting the system in his branch is good, unfortunatly his code reorganisation has been done in only a handful of very large commits, so we pretty much "start from scratch" in regards to revision history goes should it be adopted as Xinha.

As far as the unified backend goes, well, I'm in two minds - yes it's a good idea and it could be useful in some cases, but there are some problems with yermo's PHP code{1} and I don't think it addresses a method of centrally configuring the backends - which really is what I think the main advantages of "unification" would be.

I'm not a fan of the coding style that yermo has used (particularly the brace style and the fact that he is indenting the braces, and the content of the braces to the same indent level, which is rather peculiar) and should this branch be adopted, as we don't have good history on the changes anyway, I would be changing that back to BSD style, sorry yermo, but your style is just plain weird - I've never seen anybody else do that. 

(PS: The suggestion in htmlarea.js for developers to use jedit is simply that it is what I use and consitency helps to reduce spurious differences.  I find the code folding and block outlining in jedit to be very very helpful but of course YMMV, use vi for all I care, just don't introduce spurious changes or soft-tab of greater than 2-spaces)

Yermo's version also requires "configuring" per install, this is done (from INSTALL.txt) by

which means that in it's current incarnation yermo's branch is unusable (although you could do it manually) for the implementor developer putting Xinha to use if you don't at least have a PHP interpreter, even if you won't use any php plugins.

I would be very against this, there should be no reason that a configure script is required, the xinha package should just drop in, if a plugin needs configuring then so be it, but the xinha core shouldn't care (or should work it out itself) where it's installed etc.  It seems that the only thing that the configure script really does is insert some paths to the php backend - but you can trivially figure out what the URL and path to the backend is using PHP on the fly, so why bother?

Aside from the code, yermo and I have differing opinions on development models, I want many developers so things can proceed rapidly at the expense of some stability, yermo wants few developers so things can remain as stable as possible at the expense of some development.

To cut to the chase, I don't think that yermo is going to be happy to turn development of his branch over to the rest of us, he wants tight control over it; which is fine of course, he has hacked and slashed it into something he wants and would like to keep it that way.

So what I think we should do is..

1. We incorporate the idea of the unified backend (but minus the extra cruft of the debugging messages and such - KISS should be at work here), plugins can be moved to the unified backend gradually there is no hurry provided the unified backend doesn't get in the way of regular operation.
2. We do a bit of a copy & paste job on the function header comments that yermo has written inserting them into the appropriate places in the trunk.
3. Any re-organisation that yermo has done that has significant merit can be incorporated - unfortunatly this will be tricky because of the coarse grained commits yermo has done.  Only truely useful reorganisation should be considered and committed in small increments.
4. Any bugs that yermo has fixed should be similarly patched into the trunk - again tricky because of yermo's large commits

Yermo can maintain his branch in whatever way he wants, it would be nice to see that maintained publically as a parallel branch but divergent branch of Xinha but of course that's up to him - wether he forks, publically branches, or privately branches it's all the same to me.

{1} for example require_once('../../backends/backend_conf.php'); would be problematic - one should use require_once(dirname(__FILE__) . '/../../backends/backend_conf.php'); to be reliable across installations, yermo's use of $formVars is a bit odd (particularly how he builds this from $_POST or $_GET - why not just use $_REQUEST ?)

Please use the nightly, not the latest.

Will, still have this problem?  Submit a ticket if you do.

Try posting at the nuke forums, I'm sure somebody there could help you - it should be reasonably similar to htmlarea v3.

It would require writing a new tree (currently it uses "dTree" which I found somewhere).  But would be very nice.  Yes submit a ticket, but low priority enhancement

Hmmm.  So it just stopped working sometime between FF 1.0.1 and 1.0.3 then (I'm using 1.0.1 with no problems)?  That's pretty strange.

Check the stripBaseURL config setting.

The dialog should only really be modal when it needs to be modal for whatever reason, at least that's my view.  A div over the editor (perhaps semi-opaque (-moz-opacity and the Alpha() filter for IE)) sounds like a good way of doing the modality though.

Hiding the selects under the div would work OK, but perhaps might be complicated?  Don't know, never tried it before.

xinha_editors.myEditorNameHere.whatever()

you could just make the callback optional

  if(typeof callback == 'function') callback();

then just not supply it if you don't want a callback.