[opencms-dev] Re: OpenCms editor integration

[Anil Patel]

Alex,
I am close to release the Editor. We had some last minute problem in WYS... 
Editor. Most of them are fixed, It will take a day or two to update the 
document and test it little more.
I will look into details of forwarded mail.

Regards
Anil K Patel
Aditisoft Inc
www.aditisoft.com







>From: "Alexander Kandzior" <a.kandzior at alkacon.com>
>To: "Anil Patel" <toanilpatel at hotmail.com>
>Subject: OpenCms editor integration
>Date: Wed, 19 Feb 2003 12:42:15 +0100
>
>Hi Anil,
>
>how are things going? I know you are still working on that editor
>applet. I have recently been contacted by another guy who said he has
>finished an extended Ekit integration in OpenCms and asked about the
>best way to integrate that.
>
>As we have mailed about this in the past I thought I forward this to you
>as well. Let me know what you are think of this.
>
>Here's how I envision the OpenCms "editor interface":
>
>A new folder is added to the OpenCms VFS, for example:
>
>/system/workplace/editors
>
>This folders has subfolders, for example:
>
>/system/workplace/editors/msdhtml
>/system/workplace/editors/ledit
>/system/workplace/editors/textarea
>/system/workplace/editors/ekit
>/system/workplace/editors/{whatever}
>
>Properties attached to the folders control the "nice name" of the editor
>and provide further information, e.g. if the editor is a WYSIWYG
>solution, a source coide editor, or both. We might use the opportunity
>to further extend the editor catogorization to code editors with Syntax
>highlighting e.g for JSP or XML.
>
>In case the properties provide a "nice name", we actually put a locale
>key here to allow translated names. Same with other properties that
>require localization.
>
>The OpenCms "User preferences" dialog is extended. A new option allows
>the user to select an editor for each editor category available. So
>initially, we would have "WYSIWYG" and "Text" editor categories. If we
>add more categories later, there might be "JSP" or "XML" editors to
>select as already mentioned.
>
>If a user selects the edit option on a page in the OpenCms workplace
>explorer, his prefered editor is opened. If we have more categories
>later, the "best matching" category is selected, so if a user opens a
>JSP, first choice would be a JSP editor, secound choice a plain text
>editor. This selection is done by the server depending on the user
>preferences. We might also use the opportunity and put a browser
>detection in that process as well, so that only editors supported by the
>client of end user are actually opened. All this selection and browser
>detection logic will be done server side.
>
>It should be possible to configure a editor list of options for each
>system independently. This could be done in opencms properties and might
>look like this:
>
>editor.html-wysiwyg: msdhtml, textarea
>editor.html-source: ledit, textarea
>editor.jsp: ledit, textarea
>etc.
>
>User preferences allow a user to put his selection in front of this
>chain. If an editor is opened, only editors that work in the current
>users client are taken into account. The fallback (textarea) works on
>all clients.
>
>The browser detection which is important in this process should also be
>configurable in opencms.properties, e.g. like this:
>
>browser.type.msie		{some-regular-expression}
>browser.tyoe.mozilla	{some-regular-expression}
>
>For client browser detection, this rules are applied in the given order
>and the first match is then used as clients browser interanlly. The
>information about the client browser is made available in a Java API
>extension of the OpenCms core as well. That way it can be used to
>control dyanmic page output, too.
>
>The configuration of the supported editors per browser in
>opencms.properties might look like this:
>
>browser.supported-editors.html-wysiwyg.msie: mshtml
>browser.supported-editors.html-source.msie: ledit
>browser.supported-editors.jsp.msie: ledit
>
>These are only initial thoughts while typing this message. Nothing here
>has been thought about very much.
>
>Each editor will have a set of files in his directory (see above). The
>main functionality is always provided in a file called e.g.
>"editor.html". If an editor requires additional files to work, these are
>added to it's directory as well, so for the e.g. for current editor we
>will have a lot of files in it's directory because subdialogs like
>"color selection", "table creation" and "linking" are all separate
>files. I envision that java applet based editors for example will have a
>lot less files. On the main "editor.html" file the data exchange
>functionality is implemented.
>
>The data exchange functionality for the editors and OpenCms will be
>thoroughly reworked to become an editor independend exchange protocol.
>Editors will need to implement only this protocol to be able to
>integrate with OpenCms in general. We will have a basic server side
>"master editor class (or interface?)" that handles this protocol and
>creates the pages on the server. If an editor requires further server
>side functionality, it can extend or implement that class / interface
>and add further functionality. The "editor.html" mentioned above can
>then be a JSP, an XMLTemplate, a VelocityTemplate or whatever that uses
>this class to communicate with the editor. The intrinsic datails of this
>communication are left to the implementor of the new editor as long as
>he uses that "master editor class (or interface?)". A simple integration
>example is provided which uses a HTML Textform on the client for editor
>integrators to start with.
>
>
>Alexander Kandzior
>
>-------------------
>
>Alkacon Software
>Alexander Kandzior
>Eugen-Langen-Str. 8
>50968 Koeln, DE
>
>Tel: +49 (0)221 3797540
>Fax: +49 (0)221 3797541
>Email: a.kandzior at alkacon.com
>
>http://www.alkacon.com


_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail