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, Michael --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
