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