Forum OpenACS Development: HTMLArea - Current Issues and Future Development

1: HTMLArea - Current Issues and Future Development

Posted by Richard Hamilton on 10/04/05 10:38 AM

That post was meant to have this explanitory note at the top - sorry!

I have recently been testing the current htmlArea editor that ships with OpenACS and have found quite a few things that are not quite right. Furthermore, the world has moven on and the original htmlArea project has sadly bombed since we integrated it. We are now distributing old, buggy, unsupported code in OpenACS.

So with a view to resolving this issue (since many people seem to regard the presence of an editor such as this as of vital importance to OpenACS), I have had a quick look through more than 70 editors advertised on www.htmlarea.com. I have sifted out the commercial ones and any which are either obviously years out of date, dead or just dreadful. What remains is a list of workable options with a few comments and links to the demos.

I'd be really interested to hear views. It would be good to either update the code that we already have integrated, or move to another current project. Some of the developments that have forked from the original htmlArea might offer straightforward possibilities.

2: Re: HTMLArea - Current Issues and Future Development (response to 1)

Posted by Malte Sussdorff on 10/04/05 11:44 AM

HTMLArea has been deprecated in favour for RTE in OpenACS 5.2

3: Re: HTMLArea - Current Issues and Future Development (response to 1)

Posted by Dave Bauer on 10/04/05 04:06 PM

Here are requirements we have (although RTE is pretty good) that haven't been met

1) Allow multiple richtext textareas on a single page

Well that's all i can think of right now. RTE is good because it is small and the code is simple. That is one of the most important considerations. That said, it should not be impossible to support more than one widget with a little more work if someone wants a different one.

4: Re: HTMLArea - Current Issues and Future Development (response to 1)

Posted by Richard Hamilton on 10/04/05 05:07 PM

OK, well that is interesting to know. I can see why RTE was chosen - simple, effective, functional. I agree with all of those requirements and I see that it fits them.

However, having now played with the demos for all of the editors listed in my other thread (which I will paste into this thread to keep it all together), I don't think that this is necessarily the best choice. Here's why:

1) No apparent activity since 2003 - is this going to end up discontinued as well?

2) Uses deprecated html to acheive formatting (i.e. font and style tags to mention just two).

3) Creates poorly formatted and therefore unreadable 'spagetti' html.

4) Throws errors when I use it(!) - buggy?

The three editors that seems to fit the bill most closely for the requirements stated by Malte above are:

1) aynhtml

This is simple and uncluttered, and works really well. Seems to produce really beautifully clean and readable html with inline CSS. Very nice - GPL.

2) Whizzywig - ?GPL

Basic but seems to work well and load very quickly. Produces html with inline CSS styles and supports uploading of style sheets (though implementation of oacs would need thought). Free of charge but not clear if GPL.

😟
Spagetti html using deprecated tags.

3) Areaedit (based on htmlarea codebase) - GPL

A fork from Xinha which means a fork from the original HTMLArea that we are using. In active development , simple (not ladened down with features), targeted at business users so suitable for oacs, loads quickly - seems to work well. GPL.

😟
Spagetti html using deprecated tags.

So my own assessment based on what I have seen is that aynhtml would probably be the best option, followed by Whizzywig then Areaedit and fourth place goes to RTE.

Regards
Richard

5: Re: HTMLArea - Current Issues and Future Development (response to 1)

Posted by Gustaf Neumann on 10/04/05 08:34 PM

Richard wrote: So my own assessment based on what I have seen is that aynhtml would probably be the best option, followed by Whizzywig then Areaedit and fourth place goes to RTE.

hmm, isn't aynhtml for IE only? i would not like this for our setup. Whizzywig seems indeed nice and fast. it is hard to say now, which htmlarea descendant will find the largest community and will survive. have you looked at KUPU as well?

We are interested in using a javascript-based XML editor for content creation. Has anybody experience with the bitflux editor? http://www.htmlarea.com/directory/Detailed/69.html

6: Re: HTMLArea - Current Issues and Future Development (response to 1)

Posted by Richard Hamilton on 10/04/05 10:02 PM

Well, thank you for that - I have to confess that that tiny detail passed me by! :-|

Of course, that aynhtml is IE only absolutely rules it out. What a shame, nice beautifully constructed html with CSS.

Yes I did look at Kupu, but the demo looked a bit quirky and seemed a bit 'heavy' in that it had a load of unsightly dropdown boxes on the RHS. The UI appeared over-complicated on first sight. I thought that it was probably one of the big, slow, feature-swamped beasts.

Now, after your comments, having had a second look I see that this is part of its document object model design and that it need not be made to look like the demo looks.

Originally, my tests also produced lots of deprecated html which put me off. It looked like another 'me-too' rather than a serious possibility.

But now I also see in the documentation that it claims to use CSS in preference to html for layout - maybe the current code base is ahead of the demo. Because of this 'object model' design Kupu does have the potential to be uniquely interesting.

It seems that I was too hasty! Perhaps on the strength of that I should retract my first choice and replace it with something I ruled out of my first pass!! 😉

7: Re: HTMLArea - Current Issues and Future Development (response to 1)

Posted by Richard Hamilton on 10/06/05 03:07 PM

Malte,

I have just been fixing the integration of HTMLArea on 5.1.5 so that version3rc3 will work. This code does support multiple textareas on a single page, so that is a requirement that was and is still met by HTMLArea.

Maybe Mihai Bazon would donate his code to oacs since it has met a sticky end elsewhere! 😊

The new version works very well and fixes all of the bugs that I ran into. Full screen mode works well as does the 'add image' function.

I notice that the reason for there being only one HTMLArea in an ETP application is that the default 'content' field seems to receive special treatment in the preparatory proc to ad_form. So the lack of support for this is actually an ETP 'feature' rather than an HTMLArea limitation.

8: Re: HTMLArea - Current Issues and Future Development (response to 1)

Posted by Malte Sussdorff on 10/06/05 03:27 PM

Will you commit this so we can take advantage of it in legacy sites that are pre 5.2?

9: Re: HTMLArea - Current Issues and Future Development (response to 1)

Posted by Richard Hamilton on 10/06/05 03:46 PM

Yes, just asking about that on IRC. Have agreed with daveb to commit for 5.1.5 and earlier.

We should probably support more than one anyway so could then roll into 5.2 as an option and add parameters.