Re: [xwiki-users] Corrupted WYSIWYG TextArea Property

2011-11-23 Thread Ashtar Communications 
Hi,

answers are below:

On Tue, Nov 22, 2011 at 11:41 PM, Marius Dumitru Florea
mariusdumitru.flo...@xwiki.com wrote:
 Hi Aaron,

 On Tue, Nov 22, 2011 at 5:36 PM, Ashtar Communications
 ashtarcommunicati...@gmail.com wrote:
 Marius,

 Thank you for the feedback - I will start by replacing the code for
 the delete button with yours, and hopefully this will avoid at least
 one scenario for corrupting the objects. I am confident there is
 another mechanism for corruption to occur, and I still don't know what
 it is.

 I am not sure whether users are pasting directly or using the paste
 button on the toolbar, but I suspect that the vast majority are just
 pasting directly. I can try and encourage them to use the toolbar, but
 I am sure that many will continue to just paste directly and click
 save...

 I have included the errors from the server log below - I do not know
 whether or not these HTML rendering errors are directly tied to the
 corruption or are a byproduct. That is, I can only reliably
 reproduce the html rendering error on pages which already contain
 corrupted objects. I will continue to do my best to come up with a
 consistent way to reproduce the corruption error.

 The HTML rendering error seems totally random - for example, the below
 errors are from a page which contains already corrupted objects, where
 if I go to Inline mode and then immediately press Save and View it
 gives me the HTML rendering error ~75% of the time. The listed object
 number in the error also changes each time, seemingly at random -
 sometimes it is one object, sometimes two. And the other 25% of the
 time, the page saves as normal with no errors. I am doing nothing
 except clicking the button repeatedly - there is no other change.

 I do not know much about what the logs below are telling me...When the
 error occurs, I see two separate events in Lilith:

 ***EVENT 1**
 Message:

 Can't find descriptor for the component [role =
 [org.xwiki.rendering.renderer.PrintRendererFactory] hint = [default]]

 This can happen only if the syntax parameter passed to
 DefaultHTMLConverter.fromHTML(html, syntax) is null. Since
 ConversionFilter takes the syntax from a request parameter we can
 deduce that the syntax parameter is missing from the request. At the
 same time though the RequiresHTMLConversion parameter must be
 present on the request because otherwise the HTML converter wouldn't
 be called. So this log suggests that the request has
 RequiresHTMLConversion=yourTextAreaField but misses
 yourTextAreaField_syntax=xwiki/2.0. I find this very strange because
 the WYSIWYG editor adds both parameters almost at the same time, in
 two consecutive lines of code, and the JavaScript execution can't be
 stopped by user action like clicking on a button.

 Anyway, I don't recommend clicking on the Save buttons before the
 WYSIWYG editor is fully loaded.


On some of the pages, there are a large number of objects (20-30+),
which means that it frequently takes awhile in Inline mode for all the
WYSIWYG editors to load. It is certainly possible sometimes for a user
to click save before the editors are finished loading. However, I am
still getting the exception on occasion after the page is definitely
loaded - such as waiting an hour to click save.

One option that might help is if there was a way to display the
WYSIWYG editor for only a single object at a time - this would reduce
load times on pages with a large number of objects. Is there a
convenient way to do this? Since I am using $doc.display in a loop to
display all the objects on the page, Inline mode triggers editors for
all of them simultaneously - but the object editor only displays the
editors as plain text.

Do you have any other ideas for what would result in a null parameter
being passed? For example, is there a particular kind of content in
the textbox that could cause this?

I will continue to do my best to come up with a sequence that results
in the actual corruption so that hopefully someone else can reproduce
it.


 Logger:
 org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter

 Call Location:
 org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter.fromHTML(DefaultHTMLConverter.java:123)

 Call Stack:
        at 
 org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter.fromHTML(DefaultHTMLConverter.java:123)
        at 
 org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:117)
        at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at 
 com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68)
        at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        

Re: [xwiki-users] Corrupted WYSIWYG TextArea Property

2011-11-22 Thread Marius Dumitru Florea 
On Mon, Nov 21, 2011 at 10:37 PM, Ashtar Communications
ashtarcommunicati...@gmail.com wrote:
 Marius,

 Thank you for the response. Answers to your questions follow.

 On Mon, Nov 21, 2011 at 12:06 AM, Marius Dumitru Florea
 mariusdumitru.flo...@xwiki.com wrote:
 Hi Aaron,

 On Fri, Nov 18, 2011 at 11:37 PM, Ashtar Communications
 ashtarcommunicati...@gmail.com wrote:
 Hi,

 I am having difficulty locating the source of an error where the
 contents of a TextArea property for a custom class object on a page
 ends up rendering in a WYSIWYG box as wiki syntax (as in, displaying
 the actual code in one long paragraph). Corrupt is probably not the
 right word for this, as I'm sure it's something I'm doing wrong...

 Simple explanation:
 1) User clicks a button to add a new instance of a class to the page,
 which also enters the Inline Editing mode. User pastes content into a
 WYSIWYG editor and saves the page. After save, the TextArea property
 shows up correctly in view mode with $doc.display(), with headings,
 formatting, etc...
 2) Something happens - I cannot yet reproduce it, but I'm sure the
 user is doing something.
 3) The object starts displaying the property as a single block of text
 with embedded wiki syntax, mostly what looks like custom parameters
 containing the formatting info, such as:

 (% class=MsoNoSpacing %) (% class=tagChar style=font-size: 12pt; %)

 Is this the text displayed in view mode or the value of the TextArea
 property as seen when editing the page with the Object editor? I'd
 like to know the value from the Object editor.


 It is both. In view mode, $doc.display() returns one long paragraph of
 text with wiki syntax embedded but no line breaks. Viewing the object
 in the object editor, the box renders the WYSIWYG data as a plain text

 box with the same long paragraph - but with a large number of ~ escape
 characters which do not appear in view mode.

This is an important detail. It looks like the WYSIWYG editor is
submitting wiki syntax instead of HTML, but I don't see how can this
happen because the editor converts the input wiki syntax into HTML
before it is loaded and overwrites the value of the replaced plain
text area. So if you see the content properly rendered inside the rich
text area then you know that the editor will output HTML and not wiki
syntax when you save the page.


 For objects which are not corrupted the WYSIWYG data appears in the
 object editor as wiki syntax with parameters, but with no escape
 characters and embedded line breaks - these objects look fine when in
 view mode.

 etc...
 Even in inline edit mode, the contents of the WYSIWYG box have been
 replaced with this block of code, which does not appear with the
 actual formatting - just the raw code.

 Looking into the page history, there is a version of the page saved
 right before the property becomes corrupt. So something must be
 happening to trigger the conversion of the TextArea content into wiki
 syntax, which then gets saved over the original data.

 The pages the user is using have multiple objects of the same class,
 all displaying their TextArea properties in a table. The majority of
 the time, it displays perfectly. This only applies to some objects on
 the page - though sometimes all objects on a page will simultaneously
 exhibit this behavior.

 The pages also contain buttons to create a new object, as well as a
 button to delete each object individually.

 I have one reliable method of producing this error. I used to have the
 delete this object button display while in Inline Edit mode -
 clicking it while in that mode would cause to entry to convert. I

 How can the deleted object become corrupted? I suppose you are
 referring to the other objects of the same type from the same page.
 Which one gets corrupted? All? Always all?


 When in Inline mode, clicking on the delete button fails to delete the
 object. Instead, it just returns me to view mode with the object still

Well, I tried to reproduce this but I couldn't. The delete button
submits the inline form if you don't stop the click event and so you
are taken to the preview mode, not the view mode. Using:

-8-
#set($delurl = $doc.getURL('objectremove',
classname=Sandbox.Testclassid=$objectNumberform_token=$services.csrf.getToken()xredirect=$doc.getURL()))
{{html}}input type=image onclick=Event.stop(event);
location.href='$delurl' value=Delete title=Delete
src=$xwiki.getSkinFile('icons/silk/cross.gif') /{{/html}}
-8-

I'm taken to the view mode and the specified object is deleted. None
of the remaining objects are corrupted.

 present. Clicking on the delete button in view mode will successfully
 delete the object, however.

 I have seen all the objects on the page become corrupted
 simultaneously, but it is not always all. On some pages, there are
 several dozen objects, but only 1 or 2 will be corrupted at a time.

 suppressed the button from displaying unless in view mode, which
 removed this cause of the

Re: [xwiki-users] Corrupted WYSIWYG TextArea Property

2011-11-22 Thread Ashtar Communications 
Marius,

Thank you for the feedback - I will start by replacing the code for
the delete button with yours, and hopefully this will avoid at least
one scenario for corrupting the objects. I am confident there is
another mechanism for corruption to occur, and I still don't know what
it is.

I am not sure whether users are pasting directly or using the paste
button on the toolbar, but I suspect that the vast majority are just
pasting directly. I can try and encourage them to use the toolbar, but
I am sure that many will continue to just paste directly and click
save...

I have included the errors from the server log below - I do not know
whether or not these HTML rendering errors are directly tied to the
corruption or are a byproduct. That is, I can only reliably
reproduce the html rendering error on pages which already contain
corrupted objects. I will continue to do my best to come up with a
consistent way to reproduce the corruption error.

The HTML rendering error seems totally random - for example, the below
errors are from a page which contains already corrupted objects, where
if I go to Inline mode and then immediately press Save and View it
gives me the HTML rendering error ~75% of the time. The listed object
number in the error also changes each time, seemingly at random -
sometimes it is one object, sometimes two. And the other 25% of the
time, the page saves as normal with no errors. I am doing nothing
except clicking the button repeatedly - there is no other change.

I do not know much about what the logs below are telling me...When the
error occurs, I see two separate events in Lilith:

***EVENT 1**
Message:
Can't find descriptor for the component [role =
[org.xwiki.rendering.renderer.PrintRendererFactory] hint = [default]]

Logger:
org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter

Call Location:
org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter.fromHTML(DefaultHTMLConverter.java:123)

Call Stack:
at 
org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter.fromHTML(DefaultHTMLConverter.java:123)
at 
org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:117)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:218)

Thrown:

Exception: org.xwiki.component.manager.ComponentLookupException
Message: Can't find descriptor for the component [role =
[org.xwiki.rendering.renderer.PrintRendererFactory] hint = [default]]
StackTrace:
at 
org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:377)
~[xwiki-commons-component-default-3.1.jar:na]
at 
org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:126)
~[xwiki-commons-component-default-3.1.jar:na]
at 
org.xwiki.component.internal.DefaultComponentManager.lookup(DefaultComponentManager.java:88)
~[xwiki-commons-component-default-3.1.jar:na]
at 
org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter.fromHTML(DefaultHTMLConverter.java:118)
~[xwiki-platform-wysiwyg-server-3.1.jar:na]
at 
org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:117)
[xwiki-platform-wysiwyg-server-3.1.jar:na]
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
[catalina.jar:7.0.20]
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
[catalina.jar:7.0.20]
at 
com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68)
[xwiki-platform-webdav-server-3.1.jar:na]
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
[catalina.jar:7.0.20]
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
[catalina.jar:7.0.20]
at 
org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:218)
[xwiki-platform-container-servlet-3.1.jar:na]
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
[catalina.jar:7.0.20]
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
[catalina.jar:7.0.20]
at

Re: [xwiki-users] Corrupted WYSIWYG TextArea Property

2011-11-22 Thread Marius Dumitru Florea 
Hi Aaron,

On Tue, Nov 22, 2011 at 5:36 PM, Ashtar Communications
ashtarcommunicati...@gmail.com wrote:
 Marius,

 Thank you for the feedback - I will start by replacing the code for
 the delete button with yours, and hopefully this will avoid at least
 one scenario for corrupting the objects. I am confident there is
 another mechanism for corruption to occur, and I still don't know what
 it is.

 I am not sure whether users are pasting directly or using the paste
 button on the toolbar, but I suspect that the vast majority are just
 pasting directly. I can try and encourage them to use the toolbar, but
 I am sure that many will continue to just paste directly and click
 save...

 I have included the errors from the server log below - I do not know
 whether or not these HTML rendering errors are directly tied to the
 corruption or are a byproduct. That is, I can only reliably
 reproduce the html rendering error on pages which already contain
 corrupted objects. I will continue to do my best to come up with a
 consistent way to reproduce the corruption error.

 The HTML rendering error seems totally random - for example, the below
 errors are from a page which contains already corrupted objects, where
 if I go to Inline mode and then immediately press Save and View it
 gives me the HTML rendering error ~75% of the time. The listed object
 number in the error also changes each time, seemingly at random -
 sometimes it is one object, sometimes two. And the other 25% of the
 time, the page saves as normal with no errors. I am doing nothing
 except clicking the button repeatedly - there is no other change.

 I do not know much about what the logs below are telling me...When the
 error occurs, I see two separate events in Lilith:

 ***EVENT 1**
 Message:

 Can't find descriptor for the component [role =
 [org.xwiki.rendering.renderer.PrintRendererFactory] hint = [default]]

This can happen only if the syntax parameter passed to
DefaultHTMLConverter.fromHTML(html, syntax) is null. Since
ConversionFilter takes the syntax from a request parameter we can
deduce that the syntax parameter is missing from the request. At the
same time though the RequiresHTMLConversion parameter must be
present on the request because otherwise the HTML converter wouldn't
be called. So this log suggests that the request has
RequiresHTMLConversion=yourTextAreaField but misses
yourTextAreaField_syntax=xwiki/2.0. I find this very strange because
the WYSIWYG editor adds both parameters almost at the same time, in
two consecutive lines of code, and the JavaScript execution can't be
stopped by user action like clicking on a button.

Anyway, I don't recommend clicking on the Save buttons before the
WYSIWYG editor is fully loaded.


 Logger:
 org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter

 Call Location:
 org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter.fromHTML(DefaultHTMLConverter.java:123)

 Call Stack:
        at 
 org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter.fromHTML(DefaultHTMLConverter.java:123)
        at 
 org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:117)
        at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at 
 com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68)
        at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at 
 org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:218)

 Thrown:

 Exception: org.xwiki.component.manager.ComponentLookupException
 Message: Can't find descriptor for the component [role =
 [org.xwiki.rendering.renderer.PrintRendererFactory] hint = [default]]
 StackTrace:
        at 
 org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:377)
 ~[xwiki-commons-component-default-3.1.jar:na]
        at 
 org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:126)
 ~[xwiki-commons-component-default-3.1.jar:na]
        at 
 org.xwiki.component.internal.DefaultComponentManager.lookup(DefaultComponentManager.java:88)
 ~[xwiki-commons-component-default-3.1.jar:na]
        at 
 org.xwiki.wysiwyg.server.internal.converter.DefaultHTMLConverter.fromHTML(DefaultHTMLConverter.java:118)
 ~[xwiki-platform-wysiwyg-server-3.1.jar:na]
        at 
 org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:117)
 [xwiki-platform-wysiwyg-server-3.1.jar:na]
        at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 [catalina.jar:7.0.20]
        at

Re: [xwiki-users] Corrupted WYSIWYG TextArea Property

2011-11-21 Thread Marius Dumitru Florea 
Hi Aaron,

On Fri, Nov 18, 2011 at 11:37 PM, Ashtar Communications
ashtarcommunicati...@gmail.com wrote:
 Hi,

 I am having difficulty locating the source of an error where the
 contents of a TextArea property for a custom class object on a page
 ends up rendering in a WYSIWYG box as wiki syntax (as in, displaying
 the actual code in one long paragraph). Corrupt is probably not the
 right word for this, as I'm sure it's something I'm doing wrong...

 Simple explanation:
 1) User clicks a button to add a new instance of a class to the page,
 which also enters the Inline Editing mode. User pastes content into a
 WYSIWYG editor and saves the page. After save, the TextArea property
 shows up correctly in view mode with $doc.display(), with headings,
 formatting, etc...
 2) Something happens - I cannot yet reproduce it, but I'm sure the
 user is doing something.
 3) The object starts displaying the property as a single block of text
 with embedded wiki syntax, mostly what looks like custom parameters
 containing the formatting info, such as:

 (% class=MsoNoSpacing %) (% class=tagChar style=font-size: 12pt; %)

Is this the text displayed in view mode or the value of the TextArea
property as seen when editing the page with the Object editor? I'd
like to know the value from the Object editor.

 etc...
 Even in inline edit mode, the contents of the WYSIWYG box have been
 replaced with this block of code, which does not appear with the
 actual formatting - just the raw code.

 Looking into the page history, there is a version of the page saved
 right before the property becomes corrupt. So something must be
 happening to trigger the conversion of the TextArea content into wiki
 syntax, which then gets saved over the original data.

 The pages the user is using have multiple objects of the same class,
 all displaying their TextArea properties in a table. The majority of
 the time, it displays perfectly. This only applies to some objects on
 the page - though sometimes all objects on a page will simultaneously
 exhibit this behavior.

 The pages also contain buttons to create a new object, as well as a
 button to delete each object individually.

 I have one reliable method of producing this error. I used to have the
 delete this object button display while in Inline Edit mode -
 clicking it while in that mode would cause to entry to convert. I

How can the deleted object become corrupted? I suppose you are
referring to the other objects of the same type from the same page.
Which one gets corrupted? All? Always all?

 suppressed the button from displaying unless in view mode, which
 removed this cause of the error - but there is still some other
 mechanism for generating the same behavior.

 Here's an example of the delete button code which I can use to cause
 similar behavior:


 #set($delurl = 
 /xwiki/wiki/$doc.getWiki()/objectremove/$doc.getSpace()/$doc.getName()?classname=Sandbox.TestClassclassid=$obj.getNumber()xredirect=$doc.getURL())

Unrelated to your problem, you should never build the URL manually.
Use instead $doc.getURL($actionName, $queryString).


 input
 type=image
 onclick=location.href='$delurl'
 value=Delete
 title=Delete
 style=float:right;
 src=/xwiki/resources/icons/silk/cross.gif /

 Any ideas on what's happening?

What do you mean when you say that the entry is converted when you
click on the delete button. AFAICS the delete button doesn't submit
the inline form (so any changes will be lost) and it redirects to view
mode after the object is deleted. Are you saying that the TextArea
properties are corrupted as soon as you end up in view mode after the
object has been removed? If so, then you should see in the history
that the revision that deleted the object also modified the TextArea
properties. I doubt it.

Are you using the browser back button or the edit menu to go back to
inline edit mode after deleting an object? I'm pretty sure you are
using the back button in order to not loose unsaved changes made
before clicking the delete object button. If so, then you could be
experiencing http://jira.xwiki.org/browse/XWIKI-7028 .

Hope this helps,
Marius


 Thanks much,

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

Re: [xwiki-users] Corrupted WYSIWYG TextArea Property

2011-11-21 Thread Ashtar Communications 
Marius,

Thank you for the response. Answers to your questions follow.

On Mon, Nov 21, 2011 at 12:06 AM, Marius Dumitru Florea
mariusdumitru.flo...@xwiki.com wrote:
 Hi Aaron,

 On Fri, Nov 18, 2011 at 11:37 PM, Ashtar Communications
 ashtarcommunicati...@gmail.com wrote:
 Hi,

 I am having difficulty locating the source of an error where the
 contents of a TextArea property for a custom class object on a page
 ends up rendering in a WYSIWYG box as wiki syntax (as in, displaying
 the actual code in one long paragraph). Corrupt is probably not the
 right word for this, as I'm sure it's something I'm doing wrong...

 Simple explanation:
 1) User clicks a button to add a new instance of a class to the page,
 which also enters the Inline Editing mode. User pastes content into a
 WYSIWYG editor and saves the page. After save, the TextArea property
 shows up correctly in view mode with $doc.display(), with headings,
 formatting, etc...
 2) Something happens - I cannot yet reproduce it, but I'm sure the
 user is doing something.
 3) The object starts displaying the property as a single block of text
 with embedded wiki syntax, mostly what looks like custom parameters
 containing the formatting info, such as:

 (% class=MsoNoSpacing %) (% class=tagChar style=font-size: 12pt; %)

 Is this the text displayed in view mode or the value of the TextArea
 property as seen when editing the page with the Object editor? I'd
 like to know the value from the Object editor.


It is both. In view mode, $doc.display() returns one long paragraph of
text with wiki syntax embedded but no line breaks. Viewing the object
in the object editor, the box renders the WYSIWYG data as a plain text
box with the same long paragraph - but with a large number of ~ escape
characters which do not appear in view mode.

For objects which are not corrupted the WYSIWYG data appears in the
object editor as wiki syntax with parameters, but with no escape
characters and embedded line breaks - these objects look fine when in
view mode.

 etc...
 Even in inline edit mode, the contents of the WYSIWYG box have been
 replaced with this block of code, which does not appear with the
 actual formatting - just the raw code.

 Looking into the page history, there is a version of the page saved
 right before the property becomes corrupt. So something must be
 happening to trigger the conversion of the TextArea content into wiki
 syntax, which then gets saved over the original data.

 The pages the user is using have multiple objects of the same class,
 all displaying their TextArea properties in a table. The majority of
 the time, it displays perfectly. This only applies to some objects on
 the page - though sometimes all objects on a page will simultaneously
 exhibit this behavior.

 The pages also contain buttons to create a new object, as well as a
 button to delete each object individually.

 I have one reliable method of producing this error. I used to have the
 delete this object button display while in Inline Edit mode -
 clicking it while in that mode would cause to entry to convert. I

 How can the deleted object become corrupted? I suppose you are
 referring to the other objects of the same type from the same page.
 Which one gets corrupted? All? Always all?


When in Inline mode, clicking on the delete button fails to delete the
object. Instead, it just returns me to view mode with the object still
present. Clicking on the delete button in view mode will successfully
delete the object, however.

I have seen all the objects on the page become corrupted
simultaneously, but it is not always all. On some pages, there are
several dozen objects, but only 1 or 2 will be corrupted at a time.

 suppressed the button from displaying unless in view mode, which
 removed this cause of the error - but there is still some other
 mechanism for generating the same behavior.

 Here's an example of the delete button code which I can use to cause
 similar behavior:


 #set($delurl = 
 /xwiki/wiki/$doc.getWiki()/objectremove/$doc.getSpace()/$doc.getName()?classname=Sandbox.TestClassclassid=$obj.getNumber()xredirect=$doc.getURL())

 Unrelated to your problem, you should never build the URL manually.
 Use instead $doc.getURL($actionName, $queryString).


Thank you, this is good to know.


 input
 type=image
 onclick=location.href='$delurl'
 value=Delete
 title=Delete
 style=float:right;
 src=/xwiki/resources/icons/silk/cross.gif /

 Any ideas on what's happening?

 What do you mean when you say that the entry is converted when you
 click on the delete button. AFAICS the delete button doesn't submit
 the inline form (so any changes will be lost) and it redirects to view
 mode after the object is deleted. Are you saying that the TextArea
 properties are corrupted as soon as you end up in view mode after the
 object has been removed? If so, then you should see in the history
 that the revision that deleted the object also modified the TextArea
 properties. I doubt it.

 Are

[xwiki-users] Corrupted WYSIWYG TextArea Property

2011-11-18 Thread Ashtar Communications 
Hi,

I am having difficulty locating the source of an error where the
contents of a TextArea property for a custom class object on a page
ends up rendering in a WYSIWYG box as wiki syntax (as in, displaying
the actual code in one long paragraph). Corrupt is probably not the
right word for this, as I'm sure it's something I'm doing wrong...

Simple explanation:
1) User clicks a button to add a new instance of a class to the page,
which also enters the Inline Editing mode. User pastes content into a
WYSIWYG editor and saves the page. After save, the TextArea property
shows up correctly in view mode with $doc.display(), with headings,
formatting, etc...
2) Something happens - I cannot yet reproduce it, but I'm sure the
user is doing something.
3) The object starts displaying the property as a single block of text
with embedded wiki syntax, mostly what looks like custom parameters
containing the formatting info, such as:
(% class=MsoNoSpacing %) (% class=tagChar style=font-size: 12pt; %)
etc...
Even in inline edit mode, the contents of the WYSIWYG box have been
replaced with this block of code, which does not appear with the
actual formatting - just the raw code.

Looking into the page history, there is a version of the page saved
right before the property becomes corrupt. So something must be
happening to trigger the conversion of the TextArea content into wiki
syntax, which then gets saved over the original data.

The pages the user is using have multiple objects of the same class,
all displaying their TextArea properties in a table. The majority of
the time, it displays perfectly. This only applies to some objects on
the page - though sometimes all objects on a page will simultaneously
exhibit this behavior.

The pages also contain buttons to create a new object, as well as a
button to delete each object individually.

I have one reliable method of producing this error. I used to have the
delete this object button display while in Inline Edit mode -
clicking it while in that mode would cause to entry to convert. I
suppressed the button from displaying unless in view mode, which
removed this cause of the error - but there is still some other
mechanism for generating the same behavior.

Here's an example of the delete button code which I can use to cause
similar behavior:

#set($delurl = 
/xwiki/wiki/$doc.getWiki()/objectremove/$doc.getSpace()/$doc.getName()?classname=Sandbox.TestClassclassid=$obj.getNumber()xredirect=$doc.getURL())

input
type=image
onclick=location.href='$delurl'
value=Delete
title=Delete
style=float:right;
src=/xwiki/resources/icons/silk/cross.gif /

Any ideas on what's happening?

Thanks much,

aaron
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users