PHP specific fork of Xinha

Yermo · 2005-05-08 13:36:43

(ref: Unified Backend post http://xinha.gogo.co.nz/punbb/viewtopic.php?id=205)

As mentioned elsewhere, I've been working on a "unified backend" branch to the Xinha codebase whose central goal is to route all client to server backend requests through a single entry point. The initial backend uses PHP but others could be added.

The unified_backend branch has now diverged quite a bit from the Xinha trunk. The biggest differences between the trunk and my branch are:

. the code has been reorganized and heavily hacked for formatting, comments and error messages.
. a debugging trace infrastructure has been added making tracking down problems much easier.
. the unified backend has been added and ImageManager and Linker have been hacked to use it.
. a set of server side scripts to help manage the code have been added (currently PHP and Perl).

Turn off popup blockers and you can take a look at the current development snapshot of the unified backend branch at:

http://www.formvista.com/uploaded_html/ … index.html

If you want to look at the code itself you can point your subversion client to:

svn co http://svn.xinha.python-hosting.com/bra … ed_backend xinha_ub

Because the changes are so large and the trunk and my branch are so out of sync, I'm am strongly considering forking off my branch into a separately maintained distribution possibly under another name.

I've discussed it with James (Gogo) and he doesn't have any objections. He'd like to keep Xinha backend-implementation agnostic where I'd like to move towards a more php-backend integrated approach. He suggested I post a message here to see if anyone had any thoughts.

Thanks,

-- Yermo

anzenews · 2005-05-09 06:24:45

IMHO creating a fork is not a good idea. If you do that you also split developers and users in two - which slows down development considerably (on both ends, not just for Xinha).

It would probably be better if the PHP backend was developed in such way that it would still be independent of Xinha itself. IMHO the changes in your version should be incorporated in original Xinha (or the original Xinha should be altogether replaced by your version - whichever gives better and more maintainable code) while PHP backend should be a sub-project of Xinha. I think such "official" PHP backend is a good idea - but someone else might prefer Python, Ruby or Perl backend.

I agree that original Xinha code is very difficult to understand - I have quite some experience in programming (although not in JS) and I had huge problems understanding how Xinha works. Too much legacy I suppose.

So yes, adding coments, verbose (and precise) error messages and debugging info is a very good idea. But another fork - please don't.

Just my 0.02 EUR.

niko · 2005-05-09 09:28:17

please NO fork!!!

i do of course understand merging your changes into the trunk (or the other way around however you like to call it) is a very, very hard and time-consuming job.

you (or me or others) might have to look through every commit that was done since your branching.

but imho it's worth it!

1. your debugging-messages should help improving xinha - not only your fork
2. better code organisation and more comments are important for xinha too
3. imho the unified-backend is not that important, but still its a good concept
4. why php only? you (and me too) will use (and code for) the php-backend only - if others would like to use whatever-language why shouldn't they be allowed to do so? (of course they will have to rewrite the php-files...)

please no fork

Yermo · 2005-05-09 14:26:51

anzenews wrote:

IMHO creating a fork is not a good idea. If you do that you also split developers and users in two - which slows down development considerably (on both ends, not just for Xinha).
It would probably be better if the PHP backend was developed in such way that it would still be independent of Xinha itself.

Actually as far as functionality goes, that's certainly the case right now. If anything the unified backend approach makes the client side code /more/ independent, not less.

The problem I have that makes a backend-less-version useless for me is there is no way to do any kind of configuration on the server side. Additionally, since Javascript has no __FILE__ and __LINE__ variables, I had to write a preprocessor to patch in all the file and line numbers into the debug messages.

Beyond that, the auto-generated documentation script requires both PHP and Perl command line interpreters to run.

anzenews wrote:

IMHO the changes in your version should be incorporated in original Xinha (or the original Xinha should be altogether replaced by your version - whichever gives better and more maintainable code)

Please take a look at what I've done with the unified backend if you would. I've /completely/ hacked it up. Reorganized everything. (You'll want to set tabstops to 2 when looking at it.) Add bunches of files. Add a devutils directory. Basically I've changed the flavor of it pretty extensively.

At this point my branch allows me to see what's going on pretty easily. I'd say I'm pretty well up to speed on the codebase and moving forward it would be a much more manageable branch than the trunk. (IMHO the trunk is unmaintainable).

anzenews wrote:

while PHP backend should be a sub-project of Xinha. I think such "official" PHP backend is a good idea - but someone else might prefer Python, Ruby or Perl backend.

Agreed and that's how it's set up now.

The real issue is what do we do in terms of an "official" development environment language? To work on the unified backend branch and make patches you must have a command line PHP installed. (there is a devutils directory that has an "svn commit" wrapper, another that processes debug messages and a soon-to-be-implemented script that generates a "runtime" version of Xinha with all debug trace messages and comments stripped.) The idea is you work on the debug version and "generate" a runtime when you're done.

Even if you were working on a python backend you would still need a PHP interpreter to work with the source. (Unless you wanted to rewrite all the source management scripts in Python, which seems silly).

anzenews wrote:

I agree that original Xinha code is very difficult to understand - I have quite some experience in programming (although not in JS) and I had huge problems understanding how Xinha works. Too much legacy I suppose.

Yea, me too. Be developing since age 8. (I'm 37 now) I had a hell of a time figuring out how everything worked which is why I put in the hours to try to make it more manageable. I've never had much luck with debuggers when coming up to speed on a new codebase so I do the tracemessage infrastructure thing .. every piece of code I write always includes one. I've never understood how projects manage without one.

anzenews wrote:

So yes, adding coments, verbose (and precise) error messages and debugging info is a very good idea. But another fork - please don't.
Just my 0.02 EUR.

Worth alot more these days than $0.02usd.

For my purposes, without a unified backend Xinha is worthless to me. Without trace messages and the work I've done it becomes unmaintainable for me. I've put dozens of hours into this that I don't want to lose them. The reason I decided to submit the unified backend branch was I got tired of endlessly having to patch in changes to make HTMLArea/Xinha work with my (soon to be released) formVista framework.

At this point is would be /much/ easier to merge the Xinha trunk changes into the unified backend branch. Please take a look at the branch and let me know what you think. It's not "finished" yet, but I think you need to see what I've been up to to see if you like the approach.

I'm not hell bent on forking it; actually I'd rather not. But I have specific needs that are going to be different than the general community. I don't know how to reconcile that difference.

thanks,

-- Yermo

Yermo · 2005-05-09 14:35:51

niko wrote:

please NO fork!!!

Please see the other post I just made.

I've got specific needs.

niko wrote:

i do of course understand merging your changes into the trunk (or the other way around however you like to call it) is a very, very hard and time-consuming job.

Actually, merging the trunk changes into the branch would not be all that hard. The real question is would you folks be interested in working with a codebase that's set up the way I've set it up the branch?

If you guys don't mind working with what I've built, I would be entirely open to continuing here and not create a fork. My problem is I've got to get out of the mode of having to patch up Xinha to fit it into my framework. Every time I try to integrate a new version it takes me literally two days of mods. That was getting really old which is why I started this work in the first place.

niko wrote:

you (or me or others) might have to look through every commit that was done since your branching.

I would be more than happy to do that work myself rather than bother anyone else with it.

Please take a look at the other message I posted and take a look at the unfiied backend branch to see what I've been up to. I don't think this is a decision that can be easily made without looking at my approach. I tend to do things a little bit differently than most (something I'm a bit concerned about becuase I don't want to force my approach on anyone .. but I do have certain specific needs that have to be met for the codebase to be useful for me)

niko wrote:

but imho it's worth it!
1. your debugging-messages should help improving xinha - not only your fork
2. better code organisation and more comments are important for xinha too
3. imho the unified-backend is not that important, but still its a good concept

The unified backend should make it childsplay to have multiple separate backends in different languages. it essentially abstracts out the backend so we could have identical (no-reconfiguration-necessary) front end code supporting PHP, Perl, Python, ASP, etc. on the backend.

niko wrote:

4. why php only? you (and me too) will use (and code for) the php-backend only - if others would like to use whatever-language why shouldn't they be allowed to do so? (of course they will have to rewrite the php-files...)

See the other post. The actualy backend functionality can be any language. It's more an issue of source code management scripts. To support my work, I've had to re-create a development environment (a primitive one) that does various things to the source .. configure it, generate debug file name and line numbers, pre-process "svn commit" and soon I'll include a "generate a runtime version of the code".

So in a nutshell, to /use/ Xinha in a project you don't need PHP. To work on the Xinha codebase, you do need both PHP and Perl.

niko wrote:

please no fork

This would mean we'd have to adopt my branch as the trunk and change the way you do development.

-- Yermo

niko · 2005-05-09 15:17:25

i will look at your code tomorrow.

imho gogo should make such desicions - as he is the leader of xinha....
ofcourse he shouldn't ignore our voices

Yermo · 2005-05-09 15:45:49

niko wrote:

i will look at your code tomorrow.
imho gogo should make such desicions - as he is the leader of xinha....
ofcourse he shouldn't ignore our voices

yea, I talked to him before I posted about it. He doesn't have any objections to me forking it.

I think he wants to keep Xinha completely independent of backend language (i.e. no source management scripts and the like). That's a philosophical difference from the way I need to do things for my application.

Let me know what you think about my branch. It's not "finished" but it should give you a good idea of what I've been up to.

-- Yermo

gogo · 2005-05-10 07:41:15

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

To set up the software to run please run Configure.php with the full path
to your command line PHP interpreter as in:
/usr/local/bin/php Configure.php

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 ?)

Last edited by gogo (2005-05-10 07:42:33)

niko · 2005-05-10 10:51:53

i agree gogo on almost everything he wrote.

- i worked allready in php with debug-trace-messages... imo a real debugger is much, much comfortabler (and venkman is very nice (although kind of slow sometimes))
- personally i don't like the configure-script
- personally i don't like a commit-script - although it would really not be a problem for me using it
- not everybody is using linux and commandline (yes, really *g*)
- with windows the installation will be complicated (windoof-users expect a graphical installer - not a commandline-script )
- the commit-script won't work with TortoiseSVN
- coding style is often a big problem, but changing a complete application to my own favour - is this really necessary?
- the ddtpreproc.php does not really work in conbination with subversion

i said in my first post "please no fork"... now i'm not so sure.
1. yermo won't come back to the trunk
2. gogo won't switch to yermo's branch
...so we have a fork

but we should still work together:
- yermo can examine every commit to the trunk and decide if it is a important bugfix
- gogo (and the others...) can examine every commit to the branch (although for that it would be necessary to make only small commits!)

PS: the note about jedit should be removed from htmlara.js imho - it has nothing todo with coding-style

Yermo · 2005-05-10 12:58:18

gogo wrote:

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 can understand that.

gogo wrote:

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.

I've never had much luck with that approach.

gogo wrote:

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.

Yea, work in progress. There's some ugliness there that I would, of course, clean up.

gogo wrote:

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.

Yea, that's kind of what I was concerned about. My coding style is somewhat my own.

gogo wrote:

Yermo's version also requires "configuring" per install, this is done (from INSTALL.txt) by
To set up the software to run please run Configure.php with the full path
to your command line PHP interpreter as in:
/usr/local/bin/php Configure.php
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.

Actually, on that front I wasn't clear. The idea is that each backend needs to be configured before use. If you're not using the PHP backend then you would not need to run the PHP configure script. The idea is that each backend would have it's own configure script to set things up.

gogo wrote:

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?

Unless you're pulling it in some framework where it doesn't know what the URL is.

gogo wrote:

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.

yea. that's the biggest difference I see.

gogo wrote:

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;

Actually I don't want to pull an Interactive Tools. Not tight control. I am entirely open to working with you guys on this. It's true that I need to focus on a stability.

gogo wrote:

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

I can always patch them in in small commits adhering to the coding style recommentations.

gogo wrote:

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.

Cool.

gogo wrote:

{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,

The backend assumes cwd of the plugin directory so the relative directory references work. But you're right, it's a bit ugly. There are a number of things that need to be cleaned up. Like I said, work in progress. Just looking for feedback.

gogo wrote:

yermo's use of $formVars is a bit odd (particularly how he builds this from $_POST or $_GET - why not just use $_REQUEST ?)

Old habit.

Last edited by Yermo (2005-05-10 12:59:25)

Yermo · 2005-05-10 13:16:19

niko wrote:

i agree gogo on almost everything he wrote.
- i worked allready in php with debug-trace-messages... imo a real debugger is much, much comfortabler (and venkman is very nice (although kind of slow sometimes))
- personally i don't like the configure-script
- personally i don't like a commit-script - although it would really not be a problem for me using it

I couldn't find a way to get the about box version to come out right. If you have any suggestions I'm all ears.

niko wrote:

- not everybody is using linux and commandline (yes, really *g*)
- with windows the installation will be complicated (windoof-users expect a graphical installer - not a commandline-script )

Agreed. I've considered creating a windows like installer for another PHP project I've been working on.

niko wrote:

- the commit-script won't work with TortoiseSVN
- coding style is often a big problem, but changing a complete application to my own favour - is this really necessary?

For me it was. I had virtually no dhtml experience when I started working on this. I was endlessly getting tripped up on the function() parameter calls, some of which a dozens of lines long .. so to make it easier on me, and to have a chance to look at each line of the code I reformatted it into my style, weird it may be. I just can't stand the bsd style.

niko wrote:

- the ddtpreproc.php does not really work in conbination with subversion

Can't argue with you there. It will create spurious changes.

niko wrote:

i said in my first post "please no fork"... now i'm not so sure.
1. yermo won't come back to the trunk
2. gogo won't switch to yermo's branch
...so we have a fork

Yea, it looks that way.

niko wrote:

but we should still work together:
- yermo can examine every commit to the trunk and decide if it is a important bugfix
- gogo (and the others...) can examine every commit to the branch (although for that it would be necessary to make only small commits!)

I could make it easy on you and just apply whatever bugfixes I make to the trunk according to the recommended coding style. Might be the best of both worlds.

I tend not to do well with the small commit thing. I tend to work on large pieces of code at once until I get something working, then I commit. I guess it shows that I've been "coding on my own" for a bit too long. Despite the fact that I've been coding for decades, I've been lead on every project I've been involved with. This is actually the first time I've ever tried to submit work to an existing community open source project, which is why I was concerned about coding style and approach.

So I guess the consensus is for me to run it as a fork. I haven't decided yet whether to keep it here as a branch or just manage it on one of my sites which may be easier for me. Either way I will continue to provide bug fixes and patches to the Xinha project.

Thanks for taking the time to look at my hack and slash work. The feedback is very useful and I do sincerely appreciate it.

Foxx · 2005-05-10 19:46:00

From what I've read so far, I'm kind of in the middle. One the one hand I agree with the fact that the Xinha Core should be completely independent and optimized for useage without any backend system. But on the other hand, many (in my opinion, MOST) project will somehow want to incorporate functionality which is only available on the server side (uploading of files, etc) which means the need for a good integration with backend systems is unmistakably there.

I would personally like to see Xinha being able to work as a standalone application, but also totally plugin ready and being able to provide the necesary information to whatever backend system might arise.

To be honest, aside from the fact that gogo and yermo have different view on some aspects, I don't see why there isn't a solution that satisfies both parties without making any compromises on the actual product itself.

I think from all threads I've read it has become pretty clear that Xinha in its current form is a mess coding-wise, which is mainly an inheritance of InteractiveTools.com, and in order to be able to grow it needs to be (partly) rewritten. Why not take yermo's changes (even though you don't like the coding style, it still does the same thing, yermo already indicated that optimizations are at hand), commit them to the current trunk and work from there? It has been mentioned many times that Xinha needs to be changed in order to better support plugins of ANY type, not just the unified backend.

To cut a long story short, aside from some different perspectives on how things should be done, everyone pretty much wants the same thing, a highly customizable, full featured WYSIWYG editor, so I don't see a valid reason to make another fork and divide your efforts, while working together might be more beneficial and more efficient for all parties involved.

But hey, that's just my opinion and it's late too, so I might change some things tomorrow, and I do really appreciate your efforts yermo, since I personally make use of PHP as well for file uploading and some other custom hacks for my CMS, keep it up!!

Last edited by Foxx (2005-05-10 19:48:34)

kimss · 2005-05-10 22:01:08

Hmm, if Yermo has done work in his branch that the the default Xinha branch would benefit of I would recommend the people which have access to comitting start patching away, since finnished quirks and fixes are already there. Later we can fix the coding style if its any problem, however its quick to fix this while committing anyhows. Cleaning up code, indenting lines, filling up with whitespace is typical coffe and cigarette work,

Its inpractical to have two branches where different updates are done, but aslong as we get the same updates in both branches we should be more than ok. What we need is the branches keeping track of eachother, so that we can keep track. Tracking down changes and such shouldnt be to complicated by comparing the files with WinMerge, unless as stated the coding style has changed above whitespace differences which would require some code reformatting before WinMerging.

Yermo · 2005-05-10 22:01:46

Foxx wrote:

From what I've read so far, I'm kind of in the middle. One the one hand I agree with the fact that the Xinha Core should be completely independent and optimized for useage without any backend system.

Actually, I agree as well. Unfortunately to be useful for most projects as you've mentioned, some kind of backend support would be needed.

Foxx wrote:

To be honest, aside from the fact that gogo and yermo have different view on some aspects, I don't see why there isn't a solution that satisfies both parties without making any compromises on the actual product itself.

In projects like this, disparate development styles can have a really detrimental effect I think. I can completely understand why someone might not want to work on "Yermofied" code. I have my own approach to projects like these that, unfortunately, seems not be to too many people's liking. If I had more time and wasn't running my own company, I'd be more willing to work in the confines of someone else's style, but I have to get this stuff done on a timetable that doesn't really afford me that luxury.

My coding philosophy is one of "software lasts" so I build it to optimize for maintenance and getting other people up to speed on it. It should be as easy to understand as humanly possible.

1. experience level of the person maintaining the code. i.e. the code should be functional but approachable by the "lowest cost" person possible (i.e. beginners).

2. when problems arise the code should be set up for "quick response" in fixing them. That's why I like trace messages vs. using a debugger. Granted it's verbose but it allows me to see what's wrong very quickly in the given context. It also allows me to hand the code off to someone who's never seen it before and they can come up to speed very quickly.

3. I like seeing things line up with regard to indenting. It's just the way I'm used to writing code and for me allows me to avoid errors and quickly see what's happening.

4. keep the coding style as close to "kindergarten" as possible. Again, for making it easy to understand. I tend to be very verbose and don't take even generally accepted shortcuts.

As you can see in comparison to the above, I consider performance , code size, svn issues, etc. to be secondary to the above. I guess this comes from the number of codebases I manage .. some of which are operational but haven't been modified in 5 years. In that context I end up approaching my own code as a beginner and without all this extra "stuff" it's very difficult to remember what I was doing at the time when some customer is screaming bloody murder and I have to respond as quickly as possible.

Foxx wrote:

I think from all threads I've read it has become pretty clear that Xinha in its current form is a mess coding-wise,
which is mainly an inheritance of InteractiveTools.com,

You aint' kidding. The code that James (gogo) has written is some really good work and he's done alot to improve the codebase but it's still got a long way to go.

Foxx wrote:

and in order to be able to grow it needs to be (partly) rewritten. Why not take yermo's changes (even though you don't like the coding style, it still does the same thing, yermo already indicated that optimizations are at hand), commit them to the current trunk and work from there? It has been mentioned many times that Xinha needs to be changed in order to better support plugins of ANY type, not just the unified backend.

I have a feeling my style is probably incompatible. If you have a chance, please check out the unified_backend branch and see what you think about what I've done. (tabstops set to 2)

Understand it's a work in progress, but I would be very interested to see if your reaction is more positive or negative vs. what the other voices have expressed.

Foxx wrote:

But hey, that's just my opinion and it's late too, so I might change some things tomorrow, and I do really appreciate your efforts yermo, since I personally make use of PHP as well for file uploading and some other custom hacks for my CMS, keep it up!!

I appreciate you saying that.

At present, I've registered a few domains and am planning on creating a fork. I will however endeavor to submit patches to Xinha for things that are easy to move over. (e.g. the EnterParagraphs work I'm about to start).

Maybe, once the ideas I have for this codebase are better fleshed out we may merge projects back together; then again we may diverge completely.

Yermo · 2005-05-10 22:11:26

kimss wrote:

Its inpractical to have two branches where different updates are done, but aslong as we get the same updates in both branches we should be more than ok. What we need is the branches keeping track of eachother, so that we can keep track. Tracking down changes and such shouldnt be to complicated by comparing the files with WinMerge, unless as stated the coding style has changed above whitespace differences which would require some code reformatting before WinMerging.

Well, problem is htmlarea.js, if you look at it, has all kinds of jumbled definitions:

HTMLArea.xyz ..

HTMLArea.Config ..

HTMLArea.someconstant=xx

HTMLArea.prototype.xx =

Everything was all jumbled. So I reorganized the file completely.

All HTML area "constants" and regex's at the top.

All HTMLArea.Config() related method are now grouped together, as are all HTMLArea.xyz methods and all prototypes.

Net result, diff's aren't going to work too well.

Other than adding lots and lots of trace messages all over the place, I haven't made many functional changes. I've fixed a few bugs (most notably endless loop plugin loading) and added a few tweaks to Linker.

Aside from that most of the work has been in source management scripts that make my life easier. A front end to svn commit that updates the About box with the correct revision info. A preprocessor, that I agree with wreak havoc on SVN, that patches in file and line numbers into all the debugging messages. Also, there is a server side Configure script for the PHP backend. Soon there's going to be a "build_runtime.php" script that generates "clean" code with all the comments and trace messages removed.

At this point I think I'm going to fork it to focus on the things that I need. It'll be publically available so you can pick and choose any improvements to move over to Xinha. In addition I will endeavor to patch in any bugfixes or easy to move over improvements into Xinha, time permitting.

Foxx · 2005-05-11 03:34:46

Yermo wrote:

I have a feeling my style is probably incompatible. If you have a chance, please check out the unified_backend branch and see what you think about what I've done. (tabstops set to 2)

I will see if I have some time to go through it this weekend and let you know what I think here.

Foxx

willeffects · 2005-05-13 00:16:58

does your fork work in ie?

Yermo · 2005-05-13 00:20:14

willeffects wrote:

does your fork work in ie?

yea. I haven't changed much with regard to the actual client side functioning of Xinha. I haven't tested IE support in a while but will get to that once I finish up fixing EnterParagraphs, which I'm working on now.

willeffects · 2005-05-13 02:59:29

I tested it today in IE without luck thats why I was asking. Glad to know you will take a look after you fix the much needed bad enterparagraphs

Yermo · 2005-05-13 03:02:34

willeffects wrote:

I tested it today in IE without luck thats why I was asking. Glad to know you will take a look after you fix the much needed bad enterparagraphs

Did you download from CVS or try the sample install I have up on formvista.com?

Are you trying to run the simple_sample (it's broken right now). If so, try the full_example with just a few plugins and let me know if that works for you.

What version of IE? What OS?

Do you have script debugging installed? Any error messages to report?

thanks,

-- Yermo

Last edited by Yermo (2005-05-13 03:04:03)

willeffects · 2005-05-13 03:20:56

I am on this page http://www.formvista.com/uploaded_html/ … ample.html

Default and once changing plugins has the same effect.

IE 6 SP1 on XP.

error:

line: 125
char: 2
error: invalid argument
code 0
url: ... fullexample-body.php?num=1

it loads the textarea with the data but doesnt convert it to xinha

Yermo · 2005-05-13 03:30:56

willeffects wrote:

I am on this page http://www.formvista.com/uploaded_html/ … ample.html
Default and once changing plugins has the same effect.
IE 6 SP1 on XP.
error:
line: 125
char: 2
error: invalid argument
code 0
url: ... fullexample-body.php?num=1

it loads the textarea with the data but doesnt convert it to xinha

Cool. I'll check it out and fix it. It'll take me a little bit because I want to finish up the EnterParagraphs stuff first.

thanks,

-- Yermo

anzenews · 2005-05-17 06:59:13

Maybe a bit late, but still - I have a few more cents to add...

The PHP configure script is not such a bad idea if it is done on the server (automatically). Otherwise some developers might have problems - as someone else said, not everybody has Linux (yet ).

Or, even better: I haven't checked the code but the __FILE__ and __LINE__ could be done so that the JS code works even without going through configure script (but of course without outputing the correct file/line pairs).
Sth. like:

  __FILE__='unknown'; 
  __LINE__='unknown';
  my_js_debug_function(__FILE__, __LINE__, "Some debug message.");

And then configure script could look like this:

  $filename='htmlarea.js';
  $file=file($filename);
  foreach ($file as $lineno=>$line)
  {
    $line=str_replace('__FILE__=','// disabled: __FILE__=',$line);
    $line=str_replace('__LINE__=','// disabled: __LINE__=',$line);  
    $line=str_replace('__FILE__',$filename,$line);      
    $line=str_replace('__LINE__',$lineno,$line);      
  };

If developer runs configure then he will see the file/line pairs. Otherwise this info will not be available to him - nothing we can do about it - but he will still be able to run and test the code. (both pieces of code are pseudo-code - no testing done)

As for stability / adding new features goes - I would always go with the stable approach. The only reason I migrated from HtmlArea 2 to Xinha is stability (well, apart from FireFox support). But you don't have to sacrifice one to gain the other. I like Debian approach. In Debian there is the stable version that lacks some functionality but does everything as it should, and there is unstable version that has all the functionality available - but it is not as reliable as the stable one (ok, you also have testing version somewhere in between, but that is not important in this case).

For me the stability of the code is a primary issue, and also for everyone using Xinha for commercial purposes. I really don't want to hear clients asking "why can't I see the editing buttons?" and replying "Hmmm, that is weird...". It doesn't do any good on customer relations...

The bottom line is - I agree with most points you make and I will certainly have a look at your code once I find some time. But I still think the everyone would benefit if you and Gogo could find a way to join projects. Community is small enough as it is. But if the goals are that different then i guess there is no choice.

Anze

Yermo · 2005-05-17 14:19:38

anzenews wrote:

Maybe a bit late, but still - I have a few more cents to add...
The PHP configure script is not such a bad idea if it is done on the server (automatically). Otherwise some developers might have problems - as someone else said, not everybody has Linux (yet ).

The Configure script should run under windows. It just generates a few files providing the location of the PHP interpreter. FAIK it's not even needed under windows since windows launches PHP based in the file extension and not the intepreter listed at the top fo the file.

anznews wrote:

Or, even better: I haven't checked the code but the __FILE__ and __LINE__ could be done so that the JS code works even without going through configure script (but of course without outputing the correct file/line pairs).

I had thought about that, however being able to quickly turn on trace messages when there's some problem, with accurate line numbers, will make supporting this alot easier; at least for me.

anznews wrote:

As for stability / adding new features goes - I would always go with the stable approach. The only reason I migrated from HtmlArea 2 to Xinha is stability (well, apart from FireFox support). But you don't have to sacrifice one to gain the other.

Agreed but it certainly makes it more difficult. It is probably, for most applications, more important to have a very solid core of functionality.

anznews wrote:

For me the stability of the code is a primary issue, and also for everyone using Xinha for commercial purposes. I really don't want to hear clients asking "why can't I see the editing buttons?" and replying "Hmmm, that is weird...". It doesn't do any good on customer relations...

It's actually that very bug that caused me to jump into development here. I had really wanted to avoid getting into the whole DOM/javascript thing because I figured it was going to be a nightmare.

anznews wrote:

The bottom line is - I agree with most points you make

It's good to hear that someone does.

anznews wrote:

and I will certainly have a look at your code once I find some time. But I still think the everyone would benefit if you and Gogo could find a way to join projects. Community is small enough as it is. But if the goals are that different then i guess there is no choice.

My big problem is I need a very particular setup for Xinha in order for it to work with my formVista business component framework. That's the motivation behind the unified backend. Prior to that I was endlessly trying to reintegrate versions of the editor. Then there are all these nasty bugs.

I still don't understand how this kind of development can be done using a debugger. The trace setup I've built has uncovered so many bugs and frightening memory leaks it's not funny. Without a trace architectures there's no way to see how it all fits together. My $0.02 worth.

So yea, I'm forking it. As opposed to just having a private fork, I figure I'll put it up in case it might be of use to anyone else. (I've registered AreaEdit.com for this purpose).

I'll probably do one more commit to the unified backend branch of Xinha to include my fixes to EnterParagraphs (which now mostly works including breaking out of list items on double enter).

anzenews · 2005-05-17 17:15:25

Yermo wrote:

anzenews wrote:
The PHP configure script is not such a bad idea if it is done on the server (automatically). Otherwise some developers might have problems - as someone else said, not everybody has Linux (yet ).
The Configure script should run under windows. It just generates a few files providing the location of the PHP interpreter. FAIK it's not even needed under windows since windows launches PHP based in the file extension and not the intepreter listed at the top fo the file.

OK, I'll rephrase: not everyone has PHP.
Some have Perl, Ruby, whatever... If someone came to me and wanted Ruby on my system just to be able to develop something I would reconsider the whole thing. But then that's me.

yermo wrote:

anzenews wrote:
Or, even better: I haven't checked the code but the __FILE__ and __LINE__ could be done so that the JS code works even without going through configure script (but of course without outputing the correct file/line pairs).
I had thought about that, however being able to quickly turn on trace messages when there's some problem, with accurate line numbers, will make supporting this alot easier; at least for me.

I agree, but why make it mandatory? It costs nothing to do it the way I proposed (I checked the code and it could easily be done this way) - but for some people it would mean a world of difference. And for quick fixes (when developing) that do not need debug trace it would be easier and faster to use "non-configured" code.

Another idea: why not use JS itself to do this? You could just include debug.js if you wanted accurate trace. See this thread:
http://groups-beta.google.com/group/com … 2e673957a3

yermo wrote:

anzenews wrote:
The bottom line is - I agree with most points you make
It's good to hear that someone does.

I think a lot of people do - those that haven't migrated to other WYSIWYG editors yet. The code in Xinha is a nightmare to learn to understand and I actually admire people working on it - I tried to fix a bug where Xinha sometimes won't go into design mode and in a couple of hours I still couldn't understand the concept of the whole thing so I gave up.
Stability is a primary issue if you use something for commercial purposes - though to be fair Xinha is a very young project and it could evolve in a stable and very useable tool. This is also the reason I am still using it. I see a lot of activity and this gives me hope that sometime the core bugs will be fixed. If they are fixed in the near future in your fork I will be glad to switch and even post bug fixes if the code is maintainable. I personally don't care if some thing is set by using panel, button, dropdown list or a popup window - as long as it works as expected.

yermo wrote:

My big problem is I need a very particular setup for Xinha in order for it to work with my formVista business component framework. That's the motivation behind the unified backend. Prior to that I was endlessly trying to reintegrate versions of the editor. Then there are all these nasty bugs.

That doesn't sound like the right reason for making a unified backend. I was using HtmlArea2 and am now using Xinha without the need to make a lot of changes in my own CMS. From time to time I just take a new version an put it over the old one - and that's it. But I made a choice not to change Xinha sources - all configuration must be made externally. And of course, I only use core Xinha without PHP plugins. It is unstable enough as it is...

yermo wrote:

I still don't understand how this kind of development can be done using a debugger. The trace setup I've built has uncovered so many bugs and frightening memory leaks it's not funny. Without a trace architectures there's no way to see how it all fits together. My $0.02 worth.

Debugger helps - but you still need trace to find the things that are timing-dependent (debugger doesn't help you there) and when getting an "It doesn't work!" call from a client (unless you are willing to teach clients how to use a debugger ). The framework could be easily adopted / changed so that the trace would be automatically saved on the server everytime something goes *really* wrong (or when the client hits some "report an error" button).

yermo wrote:

So yea, I'm forking it. As opposed to just having a private fork, I figure I'll put it up in case it might be of use to anyone else. (I've registered AreaEdit.com for this purpose).

At least you will get more bug reports...

Anze

Xinha Discussion Forum

Announcement

#1 2005-05-08 13:36:43

PHP specific fork of Xinha

#2 2005-05-09 06:24:45

Re: PHP specific fork of Xinha

#3 2005-05-09 09:28:17

Re: PHP specific fork of Xinha

#4 2005-05-09 14:26:51

Re: PHP specific fork of Xinha

#5 2005-05-09 14:35:51

Re: PHP specific fork of Xinha

#6 2005-05-09 15:17:25

Re: PHP specific fork of Xinha

#7 2005-05-09 15:45:49

Re: PHP specific fork of Xinha

#8 2005-05-10 07:41:15

Re: PHP specific fork of Xinha

#9 2005-05-10 10:51:53

Re: PHP specific fork of Xinha

#10 2005-05-10 12:58:18

Re: PHP specific fork of Xinha

#11 2005-05-10 13:16:19

Re: PHP specific fork of Xinha

#12 2005-05-10 19:46:00

Re: PHP specific fork of Xinha

#13 2005-05-10 22:01:08

Re: PHP specific fork of Xinha

#14 2005-05-10 22:01:46

Re: PHP specific fork of Xinha

#15 2005-05-10 22:11:26

Re: PHP specific fork of Xinha

#16 2005-05-11 03:34:46

Re: PHP specific fork of Xinha

#17 2005-05-13 00:16:58

Re: PHP specific fork of Xinha

#18 2005-05-13 00:20:14

Re: PHP specific fork of Xinha

#19 2005-05-13 02:59:29

Re: PHP specific fork of Xinha

#20 2005-05-13 03:02:34

Re: PHP specific fork of Xinha

#21 2005-05-13 03:20:56

Re: PHP specific fork of Xinha

#22 2005-05-13 03:30:56

Re: PHP specific fork of Xinha

#23 2005-05-17 06:59:13

Re: PHP specific fork of Xinha

#24 2005-05-17 14:19:38

Re: PHP specific fork of Xinha

#25 2005-05-17 17:15:25

Re: PHP specific fork of Xinha

Board footer