Hi Jerome,
Jerome Velociter wrote:
> On 11/11/09 1:10 PM, Marius Dumitru Florea wrote:
>> Hi,
>>
>> Bubulina wrote:
>>> Hello,
>>> I found this link :
>>> http://code.xwiki.org/xwiki/bin/view/Modules/WysiwygEditorModule. It is an
>>> useful one, but if i wanna edit more than one html element(in this case
>>> textarea that has the id="demo") then it does now what to do.
>>> i tried making an array of "hookedIds" but that does not help either.
>>> my case scenario is something like this:
>>> "i have a table with multiple<input type="text" .. or textarea . they are
>>> grouped in a table(which had an id..thinking that if all elements are
>>> integrated in an table that has an id i am doing a step forward..quess not).
>>> each field has an id because when i press Edit i wanna edit all those
>>> elements from the table, except some labels lets say. So, folowing the
>>> example from the link above i tried, made a table, created input types and
>>> labels. just like a normal table. i gave ids to all the elements that i
>>> wanna edit later on. then when i call the editor on load in javascript, i
>>> have this variable there:hookId. this one can receive only one id?. my scope
>>> is to add as many ids as i need to so that when i press the edit button to
>>> be ablet to edit those "
>> You need to instantiate as many editors as text-areas-to-be-replaced you
>> have. In other words, each WYSIWYG editor instance replaces just one
>> text area. That's why when you configure a WYSIWYG editor instance you
>> specify just one hook id. So if you have:
>>
>> <textarea id="foo"></textarea>
>> <textarea id="bar"></textarea>
>>
>> in order to replace both you have to wrote something like:
>>
>> Wysiwyg.onModuleLoad(function() {
>> new WysiwygEditor({hookId:'foo'});
>> new WysiwygEditor({hookId:'bar'});
>> });
>>
>> Of course, it's more elegant if you mark all text areas to be replaced
>> with a CSS class like:
>>
>> <textarea id="foo" class="richtextarea"></textarea>
>> <textarea id="bar" class="richtextarea"></textarea>
>>
>> and then have:
>>
>> Wysiwyg.onModuleLoad(function() {
>> $$('.richtextarea').each(function(textArea) {
>> new WysiwygEditor({hookId:textArea.id});
>> });
>> });
>
> Maybe we could offer that by default in xwiki.js, WDYT ?
>
> Would be interesting in the case we would force the displayer of
> textarea object properties to add the CSS class when the XWiki class is
> configured to use the WYSIWYG.
>
The problem is that I need to prepare the editor input on the server and
thus I need to know what properties are edited on the server. This
constraint comes from the fact that the WYSIWYG editor syntax (HTML) is
different from the storage syntax (xwiki/2.0). I can't just take the
value of the plain HTML text area on the client because:
* the value needs to be in the storage syntax in case the JavaScript is
disabled
* I have to load the full HTML content (not just the body or a fragment)
in order to have the JavaScript and stylesheet extensions applied in
edit mode (that's why I'm using the wysiwyginput.vm template).
> (note I'd rather make the selector $$('textarea.rich') FWIW)
Right.
Thanks,
Marius
>
> Jerome.
>> Note that in case you want to edit properties of XWiki objects then it's
>> easier to use the wysiwyg_editProperties velocity macro.
>>
>> Hope this helps,
>> Marius
>>
>>> this is a long shot, but it's my best idea yet. if you think there is
>>> something wrong in the logic, please tell me. did anybody ran into such
>>> stuff?
>>> thank you
>> _______________________________________________
>> users mailing list
>> users@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
