Xinha Discussion Forum

Hmm. No it's not just you. I've seen the same kind of thing over here but hadn't narrowed it down to the network. I just notice over time firefox gets slower and slower especially with heavy javascript use. I had thought it was because of some threads racing or some such ... but hadn't delved into it.

Trace messages rock. I think I've finally fixed this bug in a way that will actually work reliably (keep fingers crossed). See my post:

http://xinha.gogo.co.nz/punbb/viewtopic.php?id=229

Once you see how the code all fits together it's not so bad ...

This was my #1 reliability issue with Xinha under FireFox ...

Yea, I wouldn't either. So I make a distinction in my backend version:

1. if you just want to use the fork (a.k.a. AreaEdit) but NOT do any development on the code itself and you do NOT want to use the PHP backend, then PHP is not necessary at all. (I obviously wouldn't want it to be.)

2. if you want to work on the  AreaEdit (i.e. Xinha) code itself and you want the debugging trace message line and file numbers to be correct, you will need PHP. (Or you can rewrite the script that processes the line numbers in whatever language or you can deal with the line numbers being incorrect).

3. if you want to USE the PHP backend, then you need to run Configure.php on it to set up the paths. I prefer doing it this way instead of trying to figure out the installation directory automatically. My impression is it's less error prone and using DEFINE's for those kinds of things tends to be more secure IMHO. There's nothing to say you can just edit the config file by hand instead of using Configure.

I haven't written the script yet but the concept for all this stuff is there are two "versions" of the code, a debug enabled version for development (if you are working on the AreaEdit (i.e. Xinha) code itself) and a stripped/optimized "runtime" version that you field to customer sites.

If you want to integrate the editor and not worry about it's internals you use the runtime version.

If you want to work on the editor itself you use the debugging (Trace enabled) version. (See comments below

Seems kind of ugly to me. I think I prefer the preprocessor approach .. less error prone I think.

EXACTLY!! The #1 goal for my fork of this is to make the code as self-explanatory and maintainable as possible. I personally don't like clever code. It's it's not immediatley obvious what it's doing it needs to be simplified (just IMHO).

The code still got a long way to go. The whole reason I put all the trace messages in was so that the code could tell me in excrutiating detail exactly what it was doing, what order it was doing it in and allow me to get an idea of why things aren't working.

I've also added alot of error messages. While I was at it I reorganized things to make it all easier to understand because I couldn't figure out how anything worked. I've also tried to document as much as I could. I did end up looking at each and every line of code in htmlarea.js and every plugin I've touched to get as familiar with the code as I could.

That's my main goal. This is being used in a commercial product by companies paying real money so it has to be maintainable. The level of expertise needed to work with the code has to be lowered as well .. and I think I've made good progress towards that end (because I am by no stretch of the imagination an accomplished DOM developer.) I had tried to contract Gogo to do this work but he's too busy.

I've got marketing companies using a system I've built and the HTML editor component is absolutely critical. With the way I work, code has to accomplish two primary goals:

1. it has to be understandable/maintainable by the lowest "cost" person possible which means clear simple code and when you're using some special language construct you document that as well.
2. it has to be self-diagnosing to the maximum degree possible which means permanent trace messages and good error condition handling/reporting.

"You ain't seen what I've been up to yet". I'm doing something very "different" from how web apps are usually built. More on that later.

Like i"m fond of saying to people who know what that's like "get out of my head". Ayup, exactly where i"m going with it.

Cool.

I don't have as slick a setup for managing all this stuff as Gogo has. But I do have an integrated system that supports simple forums, an issue tracker and the like. That should be coming online before too long.

I'm going to be checking in the latest round of changes to Xinha Unified_backend (once I track down this nasty mozilla exception that's popping up randomly on reload in frames ... very strange).

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.

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.

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

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.

It's good to hear that someone does.

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

Hmmm. That doesn't seem to be working for me. I'm guessing if you've got:

[code]<ul>
<li><br>
<li>
</ul>
[code]

You would tack on a new block as a nextSibling to <ul> and then collapse to that block as in something like:

[code]
<ul>
<li><br>
</li>
<p>&nbsp</p>[/code]
(I haven't gotten this to work yet). I'm guessing you would have to handle this particular case separately (i.e. an empty list should probably disappear when you hit enter on an empty node .. which is what the built-in handler does ...)

What I've got working here is detecting that I'm on an empty last <li> tag and just returning without calling stopEvent to let the browser handle it ... seems to work but it's a little unclean IMHO.

Cool. Thanks.

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

Actually, no. Do this, enter

test

on the first line of an empty document in the editor.

Press enter.

Now when you view the source you will see

<p>test</p><p>
</p>

That's clearly not correct as it should be:

<p>test</p>

In EnterParagraphs what looks like the original code would make it be:

<p>test</p><br>

but the <br> is stripped out the getHTMLWrapper.

So the questions is what should the terminal tag in a document be? (i.e. in the case of entering test by itself in a window and pressing ENTER what should the resulting HTML look like? <p>test</p>? <p>test</p><br>? something else? )

I saw one editor that always kept some tags at the very end of the document but I forget what they were .. seemed to be related to making it possible to get out of selections ...

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.

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

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.

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.

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.

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.

I can understand that.

I've never had much luck with that approach.

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

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

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.

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

yea. that's the biggest difference I see.

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.

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

Cool.

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.

Old habit.

Please see the other post I just made.

I've got specific needs.

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.

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)

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.

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.

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

-- Yermo