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