[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Visiting a locked page adds |[PATCH] Visiting a locked
|page to list of work |page adds page to list of
| |work
------- Additional Comments From [EMAIL PROTECTED] 2007-01-25 12:10 -------
I've fixed FCKedit, and the problem with Forms and oneForm editors. It does not
look from the code that TinyMCE is stopping users from editing checked out
documents. Some one familiar with that code will have to fix it.
thanks for the heads-up, i'll try and look into it. the tinymce java
code was copied more or less verbatim from the wyona module. i have
never updated it, so the blame is mine...
but i wonder: why should every editor implement its own java handler,
its own "insert link" and "insert image" gizmos? i think we really need
an editor abstraction with generic implementations for all these
features, or else our editors will always be in different states of
brokenness... wdyt?
let's see, what would an editor abstraction module be like?
first it needs a sitemap with a hook for editor-specific pre-processing.
i think the tinymce module is a reasonable approach: delegate the
rendering of the document to the publication and/or doctype sitemap, and
add some editor-specific stuff afterwards.
then it must provide a generic Editor.java, which should do the following:
* check out the document
* receive updates
* perform validation
* delegate editor-specific post-processing/cleanup to module editorFOO.
* check in the document. the actual writing of the file should be
delegated to the repository imnsho, no direct file operations!
and of course we will need generic usecases to insert links and images.
i need to check how the other editors do it, but the most simple and
straightforward approach seems to be this:
* open a new window with javascript where the usecase runs.
* return a link or a structure with image data in a generic format to
the calling window.
each editorFOO module must then implement a handler for this generic
format that tweaks it according to the editor's needs.
moreover, we would need to change image references from
lenya-document:... to some valid local file link before passing them to
the editor, so that it can do proper wysiwyg, and change them back upon
saving. which can be a little tricky.
i'll try and cook something up in the tinymce module and throw it at you
guys for review, and maybe then we can work it into a usable generic
module that all other editors can use. in the mean time, your comments
regarding an editor abstraction are most welcome.
andreas, where should the actual saving be implemented? my gut feeling
says that our editor code should just throw an xml tree somewhere and
not be concerned with file operations or streams. but which lenya
component should handle that xml tree and store it? i'm not too familiar
with the DAV upload handler - can we simply use it for all editors?
jörn
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
