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 _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

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?

> 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 >>

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.