Hello Nadia,
I think that xinha offers some nice functionalities for editors. But
what happens with MMBase CMSs that already have a big content database
with htmlarea? I see in the mail of Nico that the migration is 'not very
hard' - but how hard is that? What are the wizard.xsl's? I cannot tell
our editors to compare any wizard.xsl's... The only thing I know is that
if we upgrade to the new mmbase&xinha in the future that there is a
possibility that people will try to open an old article and that it will
not look exactly the same as it looked in the past. Then I will have to
know what to advice them - of preferably know well in advance a lot more
about the exact differences between htmlarea and xinha so that I can
understand the impact of such a change.
My main reason to propose xinha instead of TinyMCE or FCKeditor is,
because everyone is familiar with the htmlarea. Xinha does not treat the
html differently than htmlarea. Xinha is a big bug fix version of
htmlarea. Xinha is finishing the work the htmlarea people started with
In some cases Xinha reacts differently on user input than htmlarea.
How hard the migration is, will depend on how much custom code you have
in the htmlarea. The CMScontainer has extra icons to include content,
attachments and images as inline links. I rewrote this code, because
xinha has a more robust version to insert links. When you don't have
custom code in the htmlarea directory then it is a drop-in replacement.
The wizard.xsl is for rendering the html and only includes a different
htmleditor. Xinha is started with less lines of javascript code.
Will the htmlarea editor remain as an option, or is it the idea that it
is not anymore part of a future release? In this case there should be
clear guidelines for existing users on what to do when upgrading
existing sites. I think that this matter should be also posted in the
users list and maybe it's the best to involve the users as well in this
decision making.
The htmlarea will still be in the distro. 1.8 should be a stable release
where we are not allowed to remove functionality without a VERY good reason.
Based on the reaction in the other thread it is better to postpone the
decision and provide some alternatives and let the users decide which
htmleditor they like. I am a little afraid that in the end the
developers which create the application will make the decision instead
of the end-users.
Nico
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
