PHP specific fork of Xinha

Yermo · 2005-05-17 18:26:31

anzenews wrote:

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.

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.

anzenews wrote:

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.

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

anznews wrote:

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

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

anznews wrote:

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.

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.

anznews wrote:

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.

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.

anznews wrote:

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

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

anznews wrote:

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

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.

anznews wrote:

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

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

anzenews · 2005-05-17 19:38:10

Yermo wrote:

(Or you can rewrite the script that processes the line numbers in whatever language or you can deal with the line numbers being incorrect).

If line numbers are incorrect that is no problem - but with the way it is now I think the users will be getting errors saying that __FILE__ and __LINE__ are not specified. So it would be nice if they were assigned some arbitrary values ('unknown') for those developers who don't care about tracing framework. The assignments should of course be stripped out by the preprocessor - they are not needed if we are running it.

Yermo wrote:

anzenews wrote:
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
Seems kind of ugly to me. I think I prefer the preprocessor approach .. less error prone I think.

Yeah, I agree - but it is platform independent.

I will keep an eye on this thread, so when the project is close to being stable enough for testing, let us know - I will be glad to check it out. From everything you wrote I think it could make a nice substitute / supplement to Xinha. It definitely goes with what I would want in a WYSIWYG editor.

Anze

Yermo · 2005-05-17 22:54:59

anznews wrote:

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.

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

anzenews · 2005-05-18 03:38:47

Yermo wrote:

Trace messages rock. I think I've finally fixed this bug in a way that will actually work reliably (keep fingers crossed).
...
This was my #1 reliability issue with Xinha under FireFox ...

Great!

I have a few others though and I'm sure that new bugs will surface in time - but it's nice to see some reliability issues solved. By the way, Xinha would benefit from hints on this solution too...

Another thing: it would be nice to have an option for clients to send bug reports (with trace) to the developer. This way if something goes wrong the client only clicks "Send trace to server" and this is it - the developer can (hopefully) solve the problem without trying to reproduce a bug on his own computer. Some bugs are timing-related and difficult to reproduce. Of course, the trace should be sent for the things that have already happened - the system should keep last N messages and rotate them and when client hits "send to server" the messages should be sent. I don't know if I'm making any sense, it's too early in the morning for me. %-)

Anze

Yermo · 2005-05-18 14:02:10

anzenews wrote:

Yermo wrote:
Trace messages rock. I think I've finally fixed this bug in a way that will actually work reliably (keep fingers crossed).
...
This was my #1 reliability issue with Xinha under FireFox ...
Great!
I have a few others though and I'm sure that new bugs will surface in time - but it's nice to see some reliability issues solved. By the way, Xinha would benefit from hints on this solution too...

Already been working with Gogo on it.

http://xinha.gogo.co.nz/punbb/viewtopic … 1579#p1579

What other bugs are you seeing that you want addressed? (Other than EnterParagraphs stuff)?

anznews wrote:

Another thing: it would be nice to have an option for clients to send bug reports (with trace) to the developer. This way if something goes wrong the client only clicks "Send trace to server" and this is it

Yes, for the debugging enabled version of AreaEdit (if the trace window is turned on) I'm hoping to make something like this happen. What complicates things is that you don't know what state the browser is in .. depending on the particular bug things can get tricky.

anznews wrote:

- the developer can (hopefully) solve the problem without trying to reproduce a bug on his own computer. Some bugs are timing-related and difficult to reproduce. Of course, the trace should be sent for the things that have already happened - the system should keep last N messages and rotate them and when client hits "send to server" the messages should be sent.

Actually I would prefer seeing the entire trace from the beginning when the editor was started ... so what I would probably want to do is give clients a way, as part of a customer support call, a way to turn on the "debugging version" which pops up the trace. Let them reproduce it that way and then send the report.

In our experience, when tracking down the weirdest of errors this kind of tracing tends to work best interactively. Having customer just send random traces with a few messages probably won't help much (at least for me). I also find that I am most successful in tracking these things down when I can walk a customer through the specifics of a test so I can get a good trace.

BTW, if I have my way there will be no more timing problems in this codebase. I'm in the process of getting rid of all the setTimeout() calls I can.

anznews wrote:

I don't know if I'm making any sense, it's too early in the morning for me. %-)
Anze

I think we're both thinking the same way. We both clearly have important customers that need to be supported and are running into the same problems.

anzenews · 2005-05-18 19:20:38

Yermo wrote:

What other bugs are you seeing that you want addressed? (Other than EnterParagraphs stuff)?

I was trying to use Xinha for entering articles. Besides having titles (h1 and h2 tags) and normal text I also wanted to have "framed text" - quotations for example. Basically divs with class="quotation" css. It was impossible to do that without getting some weird results from time to time. It is quite some time ago so I don't know what I have tried, but I did spend quite some time on this problem and I know I have tried Stylist plugin. I ended up using h4 tag for quotations and setting an appropriate CSS to display it as I wish - not the most elegant solution but at least it works (I hope - since the project has been put on hold I have no feedback if there are any problems using it).

Yermo wrote:

BTW, if I have my way there will be no more timing problems in this codebase. I'm in the process of getting rid of all the setTimeout() calls I can.

Nice! This should make code more deterministic.

Yermo wrote:

anzenews wrote:
I don't know if I'm making any sense, it's too early in the morning for me. %-)
Anze
I think we're both thinking the same way. We both clearly have important customers that need to be supported and are running into the same problems.

Exactly.
I could use Xinha on many more CMS input forms but I choose normal text without HTML whenever possible - because I don't want something that sometimes doesn't work.

Anze

Yermo · 2005-05-18 20:00:35

anzenews wrote:

Yermo wrote:
What other bugs are you seeing that you want addressed? (Other than EnterParagraphs stuff)?
I was trying to use Xinha for entering articles. Besides having titles (h1 and h2 tags) and normal text I also wanted to have "framed text" - quotations for example. Basically divs with class="quotation" css. It was impossible to do that without getting some weird results from time to time. It is quite some time ago so I don't know what I have tried, but I did spend quite some time on this problem and I know I have tried Stylist plugin. I ended up using h4 tag for quotations and setting an appropriate CSS to display it as I wish - not the most elegant solution but at least it works (I hope - since the project has been put on hold I have no feedback if there are any problems using it).

Hmm. By default the EnterParagraphs plugin is turned on which will mess things up pretty badly. Do a search for mozParaHandler and set to "built-in". You might notice less weird behavior. (Actually in my fork I've fallen back to making the default "built-in" which means the browser's internal handler will dictate the behavior on enter key press. Getting EnterParagraphs to work in all cases is going to be a ridiculous amount of work.

Aside from that the only thing I can think of is some mishandling in HTMLArea.getHTMLWrapper() which does do some search and replacing.

I also haven't had too much luck with the stylist plugin but I haven't played with it much.

anznews wrote:

Yermo wrote:
anzenews wrote:
I don't know if I'm making any sense, it's too early in the morning for me. %-)
Anze
I think we're both thinking the same way. We both clearly have important customers that need to be supported and are running into the same problems.
Exactly.
I could use Xinha on many more CMS input forms but I choose normal text without HTML whenever possible - because I don't want something that sometimes doesn't work.
Anze

Yea, I built a set of discussion forum components for my framework and ended up making them plain text as well for the same reason.

However, with these recent fixes I'm probably going to try enabling the editor to see how it goes.

I should have an installable AreaEdit package put together before too long ... although allergy season here on the US east coast is making things go a bit slowly.

anzenews · 2005-05-19 09:44:18

Yermo wrote:

Hmm. By default the EnterParagraphs plugin is turned on which will mess things up pretty badly. Do a search for mozParaHandler and set to "built-in". You might notice less weird behavior. (Actually in my fork I've fallen back to making the default "built-in" which means the browser's internal handler will dictate the behavior on enter key press. Getting EnterParagraphs to work in all cases is going to be a ridiculous amount of work.
Aside from that the only thing I can think of is some mishandling in HTMLArea.getHTMLWrapper() which does do some search and replacing.
I also haven't had too much luck with the stylist plugin but I haven't played with it much.

I must admit I'm not completely sure what worked and what not. I know that I have tried setting mozParaHandler to different values and also tried different ways of doing the same thing, but it's been a few months since then and I kind of gave up on the problem.
The project I needed this for is currently on hold and when I have the need to do more than just bold & italic text I will try Xinha / AreaEdit again (instead of HtmlArea2) - but until then I figured I won't dig into Xinha sources as they were too complicated to understand. If that changes with AreaEdit (from what I've seen you're on good way - shame about the writing style but I can adopt to that) I will just check the sources and fix anything that bothers me (and send bug fixes of course ).
It's not plugins that worry me - none of them are essential to me - but the core should be as robust as possible.

Let us know when sources are stable enough to start checking them out for real.

Yermo wrote:

I should have an installable AreaEdit package put together before too long ... although allergy season here on the US east coast is making things go a bit slowly.

Sorry to hear that - I hope it passes soon.

Anze

Yermo · 2005-05-19 12:55:09

anzenews wrote:

If that changes with AreaEdit (from what I've seen you're on good way - shame about the writing style but I can adopt to that)

<laugh> Yea, old habits.

anzenews wrote:

I will just check the sources and fix anything that bothers me (and send bug fixes of course ).
It's not plugins that worry me - none of them are essential to me - but the core should be as robust as possible.

Yea, that's the goal.

At this point I've given up on the EnterParagraphs plugin for the time being. I just don't have enough time to fix it for every case; but I will go back to it at some point. I'd really like MSIE and Gecko to generate the same HTML. For now I'm telling my users to just use FireFox; for the moment I'm in a position to do that but that won't last for too long.

anznews wrote:

Let us know when sources are stable enough to start checking them out for real.

Wilco.

gogo · 2005-05-19 13:08:02

At this point I've given up on the EnterParagraphs plugin for the time being. I just don't have enough time to fix it for every case; but I will go back to it at some point. I'd really like MSIE and Gecko to generate the same HTML.

Don't forget the reason for EP (and dom_checkInsertP) in the first place isn't just to get Moz and IE to produce the same code, it's to get Moz to produce code that's usefully manipulable with CSS

Yermo · 2005-05-19 13:20:12

gogo wrote:

At this point I've given up on the EnterParagraphs plugin for the time being. I just don't have enough time to fix it for every case; but I will go back to it at some point. I'd really like MSIE and Gecko to generate the same HTML.
Don't forget the reason for EP (and dom_checkInsertP) in the first place isn't just to get Moz and IE to produce the same code, it's to get Moz to produce code that's usefully manipulable with CSS

Yea, I agree. But in order to be useful I need to have onENTER appear to the enduser as if it were just a linebreak as we had discussed. (using stylesheet entries). Without that my users will cry foul.

For it to work for me I'd have to recreate EnterParagraphs for MSIE to do the same thing. I'm afraid I don't have the time for it right now. I've already spent much longer coming up to speed on this codebase than I had planned for.

I'll have to tell my users to use FireFox, which in my case I can get away with for the moment. I will have to address this at some point before too long; primarily because my business partner really wants to control things from stylesheets (our paying users could care less.)

Enterparagraphs was such a painful piece of code to work through. At least I got it to the point where it's almost working. It should be easier for someone to pick up and run with the version of unified_backend than the trunk. I put alot of work in trying to make the code more understandable, at least for me.

gogo · 2005-05-19 13:36:45

For it to work for me I'd have to recreate EnterParagraphs for MSIE to do the same thing.

I suspect that you have no chance of doing that. IE's selection and range interfaces are pretty lack lustre as I remember. Even without any documentation for Gecko's selection object it's easier to work with than IE.

Yermo · 2005-05-19 14:13:15

gogo wrote:

For it to work for me I'd have to recreate EnterParagraphs for MSIE to do the same thing.
I suspect that you have no chance of doing that. IE's selection and range interfaces are pretty lack lustre as I remember. Even without any documentation for Gecko's selection object it's easier to work with than IE.

Yea, that's kind of what I am afraid of.

Maybe the answer is to try to map CNTRL-ENTER onto EnterParagraphs and in the MSIE case try to switch the ENTER behavior to CNTRL-ENTER and visa versa ... anyone who really wants <p> tags is probably advanced enough to learn how to hit CNTRL-ENTER .. whereas users who really just want a line break are probably not advanced enough to know anything about the underyling markup.

(Have you checked out O'reilly's Dynamic HTML the Definitive Reference book? Without it I would never have been able to come up to speed on this stuff. It's a very good reference that details all the differences between NS, DOM and IE on an interface by interface basis ...)

gogo · 2005-05-19 14:54:31

Have you checked out O'reilly's Dynamic HTML the Definitive Reference book? Without it I would never have been able to come up to speed on this stuff. It's a very good reference that details all the differences between NS, DOM and IE on an interface by interface basis ..

Nope, never had a book on JS or DHTML or anything, google is my best friend

Yermo · 2005-05-19 14:59:14

gogo wrote:

Have you checked out O'reilly's Dynamic HTML the Definitive Reference book? Without it I would never have been able to come up to speed on this stuff. It's a very good reference that details all the differences between NS, DOM and IE on an interface by interface basis ..
Nope, never had a book on JS or DHTML or anything, google is my best friend

You are a braver man than I.

Xinha Discussion Forum

Announcement

#26 2005-05-17 18:26:31

Re: PHP specific fork of Xinha

#27 2005-05-17 19:38:10

Re: PHP specific fork of Xinha

#28 2005-05-17 22:54:59

Re: PHP specific fork of Xinha

#29 2005-05-18 03:38:47

Re: PHP specific fork of Xinha

#30 2005-05-18 14:02:10

Re: PHP specific fork of Xinha

#31 2005-05-18 19:20:38

Re: PHP specific fork of Xinha

#32 2005-05-18 20:00:35

Re: PHP specific fork of Xinha

#33 2005-05-19 09:44:18

Re: PHP specific fork of Xinha

#34 2005-05-19 12:55:09

Re: PHP specific fork of Xinha

#35 2005-05-19 13:08:02

Re: PHP specific fork of Xinha

#36 2005-05-19 13:20:12

Re: PHP specific fork of Xinha

#37 2005-05-19 13:36:45

Re: PHP specific fork of Xinha

#38 2005-05-19 14:13:15

Re: PHP specific fork of Xinha

#39 2005-05-19 14:54:31

Re: PHP specific fork of Xinha

#40 2005-05-19 14:59:14

Re: PHP specific fork of Xinha

Board footer