[xwiki-devs] New WYSIWYG integration issue
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
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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.
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/
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
On Tue, Jul 29, 2008 at 4:03 PM, Marius Dumitru Florea <[email protected]> wrote:
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.
Can't you just write an AJAX call to the renderer which include a nested callback to the save action ? I'm thinking here about how we could do it with prototype, something like : new Ajax.Request('getWikiContentURL', { onSuccess:function(){ new Ajax.Request('savePage', {} ) } } [...] ) JV.
Hi JV, I don't think I can do that because the WYSIWYG and the submit buttons on the page are separated. For me the WYSIWYG is like an HTML text area. It can be added to a form which contains other fields and possible other WYSIWYG instances. So I think it's good to have the submit buttons separated from the WYSIWYG. That being the case, the WYSIWYG cannot listen to the submit buttons and, instead of directly submitting the form, make an asynchronous call to the server for the conversion and only upon receiving the response submit the form, simply because the WYSIWYG is not aware of the submit buttons present the page. The only hook is the onsubmit event of the form, provided the WYSIWYG is inside a form, which is not always the case. So I guess I could listen to the submit event, stop it, request the conversion and trigger the real submit after I get the response (following the pattern suggested by you). But as I said, this looks to me like an error-prone code for two reasons: * the form could already have onsubmit logic/listeners * GWT doesn't provide an API for wrapping an exiting HTML form but only for creating a new one. I'd have to write this code. So you think this is better than using a filter on the server side? Thanks, Marius
On Tue, Jul 29, 2008 at 4:03 PM, Marius Dumitru Florea <[email protected]> wrote:
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.
Can't you just write an AJAX call to the renderer which include a nested callback to the save action ? I'm thinking here about how we could do it with prototype, something like : new Ajax.Request('getWikiContentURL', { onSuccess:function(){ new Ajax.Request('savePage', {} ) } } [...] )
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Jul 30, 2008 at 12:42 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi JV,
I don't think I can do that because the WYSIWYG and the submit buttons on the page are separated. For me the WYSIWYG is like an HTML text area. It can be added to a form which contains other fields and possible other WYSIWYG instances. So I think it's good to have the submit buttons separated from the WYSIWYG.
Right, I've replied too fast :)
The only hook is the onsubmit event of the form, provided the WYSIWYG is inside a form, which is not always the case. So I guess I could listen to the submit event, stop it, request the conversion and trigger the real submit after I get the response (following the pattern suggested by you). But as I said, this looks to me like an error-prone code for two reasons:
* the form could already have onsubmit logic/listeners * GWT doesn't provide an API for wrapping an exiting HTML form but only for creating a new one. I'd have to write this code.
So you think this is better than using a filter on the server side?
No, indeed. +1 with : B) Use a servlet filter. JV.
participants (4)
-
Jean-Vincent Drean -
Ludovic Dubost -
Marius Dumitru Florea -
Sergiu Dumitriu