Comiotto Thomas wrote:
Hi Jörn,
Also check http://neutron.wyona.org/osr-101.xhtml and the
corresponding usecase.
resp. http://neutron.wyona.org/draft-neutron-protocol-v0.html
Cheers
Michi
Cheers,
Thomas
On Jan 26, 2007, at 1:23 AM, Joern Nettingsmeier wrote:
[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
