Marius Dumitru Florea wrote:
Hi Ludovic,
You're right about the list. We can have more than one WYSIWYG instance on a page and thus we might need to convert all the associated form fields.
However, the value of WYSIWYG (if you see the WYSIWYG as an HTML text area) can be obtained in two ways:
* on the client side, using JavaScript like: var wysiwygValue = document.getElementById('wysiwygID').value; In this case the value will be HTML code. I don't think is possible to have the value as wiki code, synchronized with the current WYSIWYG display due to the asynchronous request to the server to retrieve the conversion. Of course, the conversion could be done independently afterwards, if needed.
* on the server side, after submitting the container form, using Velocity or Java like: request.getParameter("wysiwygName"); In this case the value can be wiki code if we use a servlet filter or change XWikiAction as Ludovic suggested. Right now I'm more into the servlet filter because I don't know much about XWikiAction and it seems more natural to me to separate the code.
WDYT?
I agree with Marius here, it is better to separate concerns. XWikiAction is starting to get big already, and we don't want to add even more responsibilities to it.
I think the filter should be transparent, meaning that inside the platform, once the request was filtered, it should be impossible to see that there was some HTML content received from the client. All the platform needs is the wiki code, and that's what it should find in the (filtered) request.
Now, how to determine which fields must be processed? Is it safe to assume that all fields can be successfully filtered, as the filter should not alter non wysiwyg-html source? Should we keep in the form a list of fields that should be filtered? I'd say the former is better, so we should make sure the filter is safe and never breaks non-html source.
Here's how I did it: each instance of the new WYSIWYG editor injects, among other things, an input hidden in the container HTML page for storing the name of the wrapped HTML form field. So in the end the generated HTML page could contain something like: <input name="wysiwyg_field" value="XWiki.ArticleClass_0_content" />. In the conversion filter, after the form has been submitted, I retrieve the list of wysiwyg fields with request.getParameterValues("wysiwyg_field"). Thanks for the reply. Marius
Hi Marius,
Indeed it's more efficient to handle the conversion on the server side. However, we need to have something quite generic if we want to be able to use the wysiwyg in complex cases. A good approach would be to store a field with the list of wysiwyg to convert.
However a filter directly in XWikiAction might be better than a servlet filter as it could allow us to avoid configuration.
Ludovic
Marius Dumitru Florea wrote:
Hi devs,
I'm trying to integrate the new WYSIWYG editor into XWiki's page editing mechanism and I'm having an issue regarding how the edited content is being submitted.
Right now (correct me if I'm wrong) when the user clicks "Save & View" the edit form is submitted having a "content" field filled with the result of converting editor's HTML output to XWiki syntax. Two things should be noted: * the conversion takes place on the client side, in JavaScript code; * the save action, on the server side, expects XWiki code, not (X)HTML.
In the case of the new WYSIWYG editor, converting the (X)HTML to XWiki on the client side is out of discussion. I must use the new rendering module, which is written in Java. In order to smoothly integrate the new editor I have to make sure the save action gets the XWiki code it expects.
Asynchronously retrieving the result of the conversion before submitting the edit form is tricky due to the fact that the user can click "Save & View" before the response arrives.
In light of this, Sergiu suggested me the following 2 solutions:
A) Retrieve the conversion synchronously This would be easy if GWT would allow it. Instead I'd have to write error-prone code using timeout to wait for the response and then release the form submit.
B) Use a servlet filter I'd have to write a servlet filter that detects the save action, determines the editor (wysiwyg, new_wysiwyg, wiki etc.) and the syntax of the submitted content (XWiki by default, XHTML for the new editor) and makes the conversion, if needed.
I prefer the second solution. WDYT?
Regards, Marius
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs