cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <>
Subject Re: sharing microsoft experience
Date Fri, 30 Nov 2001 10:51:23 GMT
Bertrand Delacretaz wrote:

>I don't know enough about the Mozilla code to be positive about this, but 
>maybe there are other code bases that would be better suited to creating an 
>XML content editor - Amaya, Swing, OpenOffice, others?
Well, I am currently working on using OpenOffice as an XML content 
editor, and sadly I must agree that it will never be able to live up to 
*all* the needs that an XML content editor will have to fullfill, but it 
can be considered a migration option while there is no such tool freely 
available. I recently had a look into a Win32-binary version Amaya and 
was kind of scared away by several issues (instable, uncomfortable UI, etc).

About more than half a year ago, I tried writing an extension for the 
EditorKit concept in Swing; this concept drives the HTML editing 
component that is readily available in Swing, so you'd only need an 
XMLEditorKit as a basis. I used XML (Xerces, I believe) + CSS (Batiks 
CSS parser) for controlling the WYSIWYG, and was already able to see 
content, but then stumbled across several issues. First of all, the 
EditorKit concept then started to break all the lines of a document anew 
whenever a single line had to be broken, which turned editing documents 
longer than 4-5 pages into a flickering nightmare. When writing lengthy 
content into it, at a certain point of content length (roughly around 
32768 bytes), linebreaking suddenly vanished for the whole document, 
generating a loooong single line.

I am pretty sure that the concept itself is worth the effort, but I 
haven't been able to spot the mistakes, and after a month of 
bug-hunting, I got a bit frustrated and stopped working on it. Hmm, I 
just remember that main speed issues have arisen due to massive object 
creation and destruction all the time (even when typing a single 
character) and so could be solved using Avalon components such as pools 
I did not know enough about then... If it is of interest, I can have a 
look whether I have this code still around and donate it.

There is another point in favor of Mozilla; as the UI is 
Javascript-based, slight modifications and additions for users are 
easily done compared to a static compiled C/C++, UNO-based (roughly 
COM-alike) system like OpenOffice. For example, when users start to 
require comfortable linking capabilities, linking from their newly 
written document into the corporate archive or databases for refering to 
diagrams and citing reports, it can be easily done using Mozilla to load 
an RDF data file from Cocoon into certain Mozilla components and adding 
some Javascript and XUL around it.

Best regards,


To unsubscribe, e-mail:
For additional commands, email:

View raw message