[xwiki-devs] [VOTE] Change of behavior for the HTML macro when wiki=true
Hi, After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input: {{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}} And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros. Current Result ============ Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding: {{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}} 3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result. Proposed change ============== Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is. When run on our example this would give (same steps 1) and 2)): 3) wiki parser executes and generate XDOM. Render it using the special renderer Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have: {{html wiki=true}} <!--hello--> {{/html}} you'll get some strikethrough. So you'll need to write instead: {{html wiki=true}} <!~-~-hello~-~-> {{/html}} WDYT? Here's my +1 Thanks -Vincent
+1 On Mon, May 4, 2009 at 15:25, Vincent Massol <[email protected]> wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
Here's my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
As using these kinds of things and even if I'm not committer, I'm +1 for the wiki rendering in depth for {{html}}. Also seems quite normal to escape special wiki chars when wiki=true... as far as everything is explained in the syntax help ;) On Mon, May 4, 2009 at 3:25 PM, Vincent Massol <[email protected]> wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
Here's my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
As an aside wiki=true, clean=false will not fail anymore if the html isn't valid xml. -Vincent On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
Here's my +1
Thanks -Vincent
+1 Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
Here's my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
+1 -- Sergiu Dumitriu http://purl.org/net/sergiu/
After trying to implement it I've found the following caveats: * if the user wants an html comment he needs to escape the -- * if the user wants a NL he'll need to enter <br/> * if the user wants a paragraph he'll need to enter <p>...</p> * And the most problematic one IMO: the user needs to be very careful about new lines since: <table> <tr> <td> * [[listitem]] </td> </tr> </table> is very different from <table> <tr> <td> * [[listitem]] </td> </tr> </table> In the first case the </td>, </tr> and </table> and continuation of the list item written in wiki syntax since the wiki parser accepts multiline content... hence you'll get in XHTML: <table><tbody><tr><td><ul><li><!--startwikilink:listitem--><span class="wikicreatelink"><a href="/xwiki/bin/view/listitem? parent=xwiki:Space.Page"><span class="wikigeneratedlinkcontent">Page</ span></a></span><!--stopwikilink--></td></tr></tbody></table></li></ul> which is completely invalid. The same applies for: {{macro/}} </td> vs {{macro/}} </td> in the first case the macro is inline and will generate inline content and in the second case it's standalone. Still trying to figure out a best solution but I don't see one right now... If you have any idea, shoot! Thanks -Vincent On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
Here's my +1
Thanks -Vincent
no better idea... a very special case to remind in the syntax help to my mind... Pascal On Tue, May 5, 2009 at 9:40 AM, Vincent Massol <[email protected]> wrote:
After trying to implement it I've found the following caveats:
* if the user wants an html comment he needs to escape the -- * if the user wants a NL he'll need to enter <br/> * if the user wants a paragraph he'll need to enter <p>...</p> * And the most problematic one IMO: the user needs to be very careful about new lines since:
<table> <tr> <td> * [[listitem]] </td> </tr> </table>
is very different from
<table> <tr> <td> * [[listitem]]
</td> </tr> </table>
In the first case the </td>, </tr> and </table> and continuation of the list item written in wiki syntax since the wiki parser accepts multiline content... hence you'll get in XHTML:
<table><tbody><tr><td><ul><li><!--startwikilink:listitem--><span class="wikicreatelink"><a href="/xwiki/bin/view/listitem? parent=xwiki:Space.Page"><span class="wikigeneratedlinkcontent">Page</ span></a></span><!--stopwikilink--></td></tr></tbody></table></li></ul>
which is completely invalid.
The same applies for:
{{macro/}} </td>
vs
{{macro/}}
</td>
in the first case the macro is inline and will generate inline content and in the second case it's standalone.
Still trying to figure out a best solution but I don't see one right now...
If you have any idea, shoot!
Thanks -Vincent
On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
Here's my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
no better idea... a very special case to remind in the syntax help to my mind...
Just committed the new behavior. Would be great if some users/devs could verify it works on their use cases. Thanks -Vincent
Pascal
On Tue, May 5, 2009 at 9:40 AM, Vincent Massol <[email protected]> wrote:
After trying to implement it I've found the following caveats:
* if the user wants an html comment he needs to escape the -- * if the user wants a NL he'll need to enter <br/> * if the user wants a paragraph he'll need to enter <p>...</p> * And the most problematic one IMO: the user needs to be very careful about new lines since:
<table> <tr> <td> * [[listitem]] </td> </tr> </table>
is very different from
<table> <tr> <td> * [[listitem]]
</td> </tr> </table>
In the first case the </td>, </tr> and </table> and continuation of the list item written in wiki syntax since the wiki parser accepts multiline content... hence you'll get in XHTML:
<table><tbody><tr><td><ul><li><!--startwikilink:listitem--><span class="wikicreatelink"><a href="/xwiki/bin/view/listitem? parent=xwiki:Space.Page"><span class="wikigeneratedlinkcontent">Page</ span></a></span><!--stopwikilink--></td></tr></tbody></table></li></ ul>
which is completely invalid.
The same applies for:
{{macro/}} </td>
vs
{{macro/}}
</td>
in the first case the macro is inline and will generate inline content and in the second case it's standalone.
Still trying to figure out a best solution but I don't see one right now...
If you have any idea, shoot!
Thanks -Vincent
On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
Here's my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I will try to compile it and deploy it on my website... To be quicker, what module have you modified? regards Pascal On Tue, May 5, 2009 at 4:58 PM, Vincent Massol <[email protected]> wrote:
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
no better idea... a very special case to remind in the syntax help to my mind...
Just committed the new behavior. Would be great if some users/devs could verify it works on their use cases.
Thanks -Vincent
Pascal
On Tue, May 5, 2009 at 9:40 AM, Vincent Massol <[email protected]> wrote:
After trying to implement it I've found the following caveats:
* if the user wants an html comment he needs to escape the -- * if the user wants a NL he'll need to enter <br/> * if the user wants a paragraph he'll need to enter <p>...</p> * And the most problematic one IMO: the user needs to be very careful about new lines since:
<table> <tr> <td> * [[listitem]] </td> </tr> </table>
is very different from
<table> <tr> <td> * [[listitem]]
</td> </tr> </table>
In the first case the </td>, </tr> and </table> and continuation of the list item written in wiki syntax since the wiki parser accepts multiline content... hence you'll get in XHTML:
<table><tbody><tr><td><ul><li><!--startwikilink:listitem--><span class="wikicreatelink"><a href="/xwiki/bin/view/listitem? parent=xwiki:Space.Page"><span class="wikigeneratedlinkcontent">Page</ span></a></span><!--stopwikilink--></td></tr></tbody></table></li></ ul>
which is completely invalid.
The same applies for:
{{macro/}} </td>
vs
{{macro/}}
</td>
in the first case the macro is inline and will generate inline content and in the second case it's standalone.
Still trying to figure out a best solution but I don't see one right now...
If you have any idea, shoot!
Thanks -Vincent
On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
Here's my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On May 5, 2009, at 5:01 PM, Pascal Voitot wrote:
I will try to compile it and deploy it on my website...
To be quicker, what module have you modified?
xwiki-xml xwiki-rendering-api xwiki-rendering-macro-html You can also wait for a snapshot build at http://maven.xwiki.org Thanks -Vincent
regards Pascal
On Tue, May 5, 2009 at 4:58 PM, Vincent Massol <[email protected]> wrote:
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
no better idea... a very special case to remind in the syntax help to my mind...
Just committed the new behavior. Would be great if some users/devs could verify it works on their use cases.
Thanks -Vincent
Pascal
On Tue, May 5, 2009 at 9:40 AM, Vincent Massol <[email protected]> wrote:
After trying to implement it I've found the following caveats:
* if the user wants an html comment he needs to escape the -- * if the user wants a NL he'll need to enter <br/> * if the user wants a paragraph he'll need to enter <p>...</p> * And the most problematic one IMO: the user needs to be very careful about new lines since:
<table> <tr> <td> * [[listitem]] </td> </tr> </table>
is very different from
<table> <tr> <td> * [[listitem]]
</td> </tr> </table>
In the first case the </td>, </tr> and </table> and continuation of the list item written in wiki syntax since the wiki parser accepts multiline content... hence you'll get in XHTML:
<table><tbody><tr><td><ul><li><!--startwikilink:listitem--><span class="wikicreatelink"><a href="/xwiki/bin/view/listitem? parent=xwiki:Space.Page"><span class="wikigeneratedlinkcontent">Page</ span></a></span><!--stopwikilink--></td></tr></tbody></table></ li></ ul>
which is completely invalid.
The same applies for:
{{macro/}} </td>
vs
{{macro/}}
</td>
in the first case the macro is inline and will generate inline content and in the second case it's standalone.
Still trying to figure out a best solution but I don't see one right now...
If you have any idea, shoot!
Thanks -Vincent
On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
Here's my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, May 5, 2009 at 5:04 PM, Vincent Massol <[email protected]> wrote:
On May 5, 2009, at 5:01 PM, Pascal Voitot wrote:
I will try to compile it and deploy it on my website...
To be quicker, what module have you modified?
xwiki-xml xwiki-rendering-api xwiki-rendering-macro-html
You can also wait for a snapshot build at http://maven.xwiki.org
I love compiling, this is a hobby ;););)
Thanks -Vincent
regards Pascal
On Tue, May 5, 2009 at 4:58 PM, Vincent Massol <[email protected]> wrote:
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
no better idea... a very special case to remind in the syntax help to my mind...
Just committed the new behavior. Would be great if some users/devs could verify it works on their use cases.
Thanks -Vincent
Pascal
On Tue, May 5, 2009 at 9:40 AM, Vincent Massol <[email protected]> wrote:
After trying to implement it I've found the following caveats:
* if the user wants an html comment he needs to escape the -- * if the user wants a NL he'll need to enter <br/> * if the user wants a paragraph he'll need to enter <p>...</p> * And the most problematic one IMO: the user needs to be very careful about new lines since:
<table> <tr> <td> * [[listitem]] </td> </tr> </table>
is very different from
<table> <tr> <td> * [[listitem]]
</td> </tr> </table>
In the first case the </td>, </tr> and </table> and continuation of the list item written in wiki syntax since the wiki parser accepts multiline content... hence you'll get in XHTML:
<table><tbody><tr><td><ul><li><!--startwikilink:listitem--><span class="wikicreatelink"><a href="/xwiki/bin/view/listitem? parent=xwiki:Space.Page"><span class="wikigeneratedlinkcontent">Page</ span></a></span><!--stopwikilink--></td></tr></tbody></table></ li></ ul>
which is completely invalid.
The same applies for:
{{macro/}} </td>
vs
{{macro/}}
</td>
in the first case the macro is inline and will generate inline content and in the second case it's standalone.
Still trying to figure out a best solution but I don't see one right now...
If you have any idea, shoot!
Thanks -Vincent
On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we should change the way the HTML macro handle its content when wiki=true. For ex take the following input:
{{velocity}} ... {{html wiki="true"}} <form> $xwiki.includeForm("XWiki.MyClassSheet") <br /> <p> <input type="submit" name="submit" value="Create this new Workpackage" /> </p> </form> {{/html}} ... {{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code which thus generate {{html}} macros.
Current Result ============
Right now here's what happens: 1) velocity macro is executed and $xwiki.includeForm executes 2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki="true"}} <form> {{html}}...<someTag>...</someTag>{{/html}} </form> {{/html}}
3) After velocity has finished executing the velocity macro calls the wiki parser on the result and thus the top level HTML macro executes 4) since wiki=true the content is given to a SAX parser and each XML tag content is given to the wiki parser. Thus "{{html}}...", "..." and "{{/html}}" will be parser by the wiki parser separately (because <someTag> is valid XML), thus generating non expected content as a result.
Proposed change ==============
Modify the HTML behavior so that the wiki parser executes first (instead of the SAX parser) and render the result using a special renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the special renderer
Note that this means that if in HTML your write content that has a meaning in some wiki syntax you'll need to escape it. For example if you have:
{{html wiki=true}} <!--hello--> {{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}} <!~-~-hello~-~-> {{/html}}
WDYT?
Here's my +1
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Just a quick question, I have recompiled my server with your last commits and when I write this page: {{velocity}} {{html wiki="true"}} #warning("(% style='font-size: 130%;' %)blablabla") {{/html}} {{/velocity}} I get the following exception... Can you confirm it works on your test server? It would confirm I have a problem on my server... thanks Pascal org.xwiki.rendering.macro.MacroExecutionException: Failed to parse HTML content [<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><div class="warningmessage"><span class="messagetype">Warning: </span>(% style='font-size: 130%;' %)blablabla</div></html> ] at org.xwiki.rendering.internal.macro.html.HTMLMacro.parseXHTML(HTMLMacro.java:215) at org.xwiki.rendering.internal.macro.html.HTMLMacro.execute(HTMLMacro.java:175) at org.xwiki.rendering.internal.macro.html.HTMLMacro.execute(HTMLMacro.java:61) at org.xwiki.rendering.internal.transformation.MacroTransformation.transformOnce(MacroTransformation.java:169) at org.xwiki.rendering.internal.transformation.MacroTransformation.transform(MacroTransformation.java:113) at org.xwiki.rendering.internal.transformation.DefaultTransformationManager.performTransformations(DefaultTransformationManager.java:72) at com.xpn.xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java:5123) at com.xpn.xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java:5096) at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:531) at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:472) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:295) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at org.xwiki.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:178) at org.xwiki.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:143) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:108) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1611) at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:124) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:226) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1124) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:145) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:295) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:334) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126) at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:103) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:295) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:880) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:746) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522) Caused by: java.lang.ClassCastException: org.xwiki.rendering.renderer.printer.XHTMLWikiPrinter at org.xwiki.rendering.internal.renderer.printer.WikiWriter.getWikiPrinter(WikiWriter.java:46) at org.xwiki.rendering.internal.renderer.printer.WikiWriter.write(WikiWriter.java:93) at org.dom4j.io.XMLWriter.writeString(XMLWriter.java:1266) at org.dom4j.io.XMLWriter.write(XMLWriter.java:492) at org.xwiki.rendering.renderer.printer.XMLWikiPrinter.printXML(XMLWikiPrinter.java:80) at org.xwiki.rendering.renderer.printer.XHTMLWikiPrinter.printXML(XHTMLWikiPrinter.java:64) at org.xwiki.rendering.internal.renderer.chaining.XHTMLChainingRenderer.onWord(XHTMLChainingRenderer.java:338) at org.xwiki.rendering.listener.chaining.AbstractChainingListener.onWord(AbstractChainingListener.java:682) at org.xwiki.rendering.listener.chaining.BlockStateChainingListener.onWord(BlockStateChainingListener.java:855) at org.xwiki.rendering.listener.chaining.AbstractChainingListener.onWord(AbstractChainingListener.java:682) at org.xwiki.rendering.block.WordBlock.traverse(WordBlock.java:53) at org.xwiki.rendering.block.AbstractFatherBlock.traverse(AbstractFatherBlock.java:68) at org.xwiki.rendering.internal.macro.html.XMLBlockConverterHandler.characters(XMLBlockConverterHandler.java:146) at org.xml.sax.helpers.XMLFilterImpl.characters(XMLFilterImpl.java:564) at org.wikimodel.wem.xhtml.filter.XHTMLWhitespaceXMLFilter.sendCharacters(XHTMLWhitespaceXMLFilter.java:406) at org.wikimodel.wem.xhtml.filter.XHTMLWhitespaceXMLFilter.sendCharacters(XHTMLWhitespaceXMLFilter.java:400) at org.wikimodel.wem.xhtml.filter.XHTMLWhitespaceXMLFilter.sendPreviousContent(XHTMLWhitespaceXMLFilter.java:245) at org.wikimodel.wem.xhtml.filter.XHTMLWhitespaceXMLFilter.flushContent(XHTMLWhitespaceXMLFilter.java:279) at org.wikimodel.wem.xhtml.filter.XHTMLWhitespaceXMLFilter.endElement(XHTMLWhitespaceXMLFilter.java:173) at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546) at org.wikimodel.wem.xhtml.filter.AccumulationXMLFilter.endElement(AccumulationXMLFilter.java:69) at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546) at org.wikimodel.wem.xhtml.filter.DTDXMLFilter.endElement(DTDXMLFilter.java:70) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11NonValidatingConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XML11NonValidatingConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333) at org.wikimodel.wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333) at org.wikimodel.wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333) at org.wikimodel.wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48) at org.xwiki.rendering.internal.macro.html.HTMLMacro.parseXHTML(HTMLMacro.java:212) ... 70 more On Tue, May 5, 2009 at 5:07 PM, Pascal Voitot <[email protected]>wrote:
On Tue, May 5, 2009 at 5:04 PM, Vincent Massol <[email protected]> wrote:
On May 5, 2009, at 5:01 PM, Pascal Voitot wrote:
I will try to compile it and deploy it on my website...
To be quicker, what module have you modified?
xwiki-xml xwiki-rendering-api xwiki-rendering-macro-html
You can also wait for a snapshot build at http://maven.xwiki.org
I love compiling, this is a hobby ;););)
Thanks -Vincent
regards Pascal
On Tue, May 5, 2009 at 4:58 PM, Vincent Massol <[email protected]> wrote:
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
no better idea... a very special case to remind in the syntax help to my mind...
Just committed the new behavior. Would be great if some users/devs could verify it works on their use cases.
Thanks -Vincent
Pascal
On Tue, May 5, 2009 at 9:40 AM, Vincent Massol <[email protected]> wrote:
After trying to implement it I've found the following caveats:
* if the user wants an html comment he needs to escape the -- * if the user wants a NL he'll need to enter <br/> * if the user wants a paragraph he'll need to enter <p>...</p> * And the most problematic one IMO: the user needs to be very careful about new lines since:
<table> <tr> <td> * [[listitem]] </td> </tr> </table>
is very different from
<table> <tr> <td> * [[listitem]]
</td> </tr> </table>
In the first case the </td>, </tr> and </table> and continuation of the list item written in wiki syntax since the wiki parser accepts multiline content... hence you'll get in XHTML:
<table><tbody><tr><td><ul><li><!--startwikilink:listitem--><span class="wikicreatelink"><a href="/xwiki/bin/view/listitem? parent=xwiki:Space.Page"><span class="wikigeneratedlinkcontent">Page</ span></a></span><!--stopwikilink--></td></tr></tbody></table></ li></ ul>
which is completely invalid.
The same applies for:
{{macro/}} </td>
vs
{{macro/}}
</td>
in the first case the macro is inline and will generate inline content and in the second case it's standalone.
Still trying to figure out a best solution but I don't see one right now...
If you have any idea, shoot!
Thanks -Vincent
On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
> Hi, > > After discussing with Thomas we've reached the conclusion that we > should change the way the HTML macro handle its content when > wiki=true. > For ex take the following input: > > {{velocity}} > ... > {{html wiki="true"}} > <form> > $xwiki.includeForm("XWiki.MyClassSheet") > <br /> > <p> > <input type="submit" name="submit" value="Create this new > Workpackage" /> > </p> > </form> > {{/html}} > ... > {{/velocity}} > > And assume that MyClassSheet has some $doc.display() velocity code > which thus generate {{html}} macros. > > Current Result > ============ > > Right now here's what happens: > 1) velocity macro is executed and $xwiki.includeForm executes > 2) MyClassSheet generate {{html}} macro content thus yielding: > > {{html wiki="true"}} > <form> > {{html}}...<someTag>...</someTag>{{/html}} > </form> > {{/html}} > > 3) After velocity has finished executing the velocity macro calls > the wiki parser on the result and thus the top level HTML macro > executes > 4) since wiki=true the content is given to a SAX parser and each > XML > tag content is given to the wiki parser. Thus "{{html}}...", "..." > and "{{/html}}" will be parser by the wiki parser separately > (because <someTag> is valid XML), thus generating non expected > content as a result. > > Proposed change > ============== > > Modify the HTML behavior so that the wiki parser executes first > (instead of the SAX parser) and render the result using a special > renderer that prints the special symbols and text as is. > > When run on our example this would give (same steps 1) and 2)): > > 3) wiki parser executes and generate XDOM. Render it using the > special renderer > > Note that this means that if in HTML your write content that has a > meaning in some wiki syntax you'll need to escape it. For > example if > you have: > > {{html wiki=true}} > <!--hello--> > {{/html}} > > you'll get some strikethrough. So you'll need to write instead: > > {{html wiki=true}} > <!~-~-hello~-~-> > {{/html}} > > WDYT? > > Here's my +1 > > Thanks > -Vincent >
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On May 6, 2009, at 2:31 PM, Pascal Voitot wrote:
Just a quick question, I have recompiled my server with your last commits and when I write this page:
{{velocity}} {{html wiki="true"}} #warning("(% style='font-size: 130%;' %)blablabla") {{/html}} {{/velocity}}
I get the following exception...
Can you confirm it works on your test server? It would confirm I have a problem on my server...
yes works fine here. Thanks -Vincent
thanks Pascal
org.xwiki.rendering.macro.MacroExecutionException: Failed to parse HTML content [<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><div class="warningmessage"><span class="messagetype">Warning: </span>(% style='font-size: 130%;' %)blablabla</div></html>
] at org .xwiki .rendering.internal.macro.html.HTMLMacro.parseXHTML(HTMLMacro.java: 215) at org .xwiki .rendering.internal.macro.html.HTMLMacro.execute(HTMLMacro.java:175) at org .xwiki .rendering.internal.macro.html.HTMLMacro.execute(HTMLMacro.java:61)
at org .xwiki .rendering .internal .transformation .MacroTransformation.transformOnce(MacroTransformation.java:169) at org .xwiki .rendering .internal .transformation .MacroTransformation.transform(MacroTransformation.java:113)
at org .xwiki .rendering .internal .transformation .DefaultTransformationManager .performTransformations(DefaultTransformationManager.java:72) at com .xpn .xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java: 5123)
at com .xpn .xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java: 5096) at com .xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java: 531) at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:472)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.velocity.util.introspection.UberspectImpl $VelMethodImpl.invoke(UberspectImpl.java:295) at org .apache .velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245)
at org .apache .velocity.runtime.parser.node.ASTReference.execute(ASTReference.java: 203) at org .apache .velocity.runtime.parser.node.ASTReference.render(ASTReference.java: 294) at org .apache .velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318)
at org .xwiki .velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java: 178) at org .xwiki .velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java: 143) at com .xpn .xwiki .render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:108)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1611) at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:124) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:226) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
at org .apache .struts .action.RequestProcessor.processActionPerform(RequestProcessor.java: 431) at org .apache.struts.action.RequestProcessor.process(RequestProcessor.java: 236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java: 1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java: 432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1124) at com .xpn .xwiki .wysiwyg .server.filter.ConversionFilter.doFilter(ConversionFilter.java:145) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115)
at com .xpn .xwiki .web .SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java: 295) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115) at com .xpn .xwiki .web .SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java: 112)
at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 361) at org .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 417)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:334) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126) at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:103) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115)
at com .xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java: 68) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115) at com .xpn .xwiki .web .SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java: 295)
at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115) at com .xpn .xwiki .web .SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java: 112) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 361) at org .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 417) at org .mortbay .jetty .handler .ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org .mortbay .jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 152) at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 535) at org.mortbay.jetty.HttpConnection $RequestHandler.content(HttpConnection.java:880) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:746)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 409)
at org.mortbay.thread.QueuedThreadPool $PoolThread.run(QueuedThreadPool.java:522) Caused by: java.lang.ClassCastException: org.xwiki.rendering.renderer.printer.XHTMLWikiPrinter at org .xwiki .rendering .internal.renderer.printer.WikiWriter.getWikiPrinter(WikiWriter.java: 46)
at org .xwiki .rendering .internal.renderer.printer.WikiWriter.write(WikiWriter.java:93) at org.dom4j.io.XMLWriter.writeString(XMLWriter.java:1266) at org.dom4j.io.XMLWriter.write(XMLWriter.java:492) at org .xwiki .rendering .renderer.printer.XMLWikiPrinter.printXML(XMLWikiPrinter.java:80)
at org .xwiki .rendering .renderer.printer.XHTMLWikiPrinter.printXML(XHTMLWikiPrinter.java:64) at org .xwiki .rendering .internal .renderer .chaining.XHTMLChainingRenderer.onWord(XHTMLChainingRenderer.java:338) at org .xwiki .rendering .listener .chaining .AbstractChainingListener.onWord(AbstractChainingListener.java:682)
at org .xwiki .rendering .listener .chaining .BlockStateChainingListener.onWord(BlockStateChainingListener.java: 855) at org .xwiki .rendering .listener .chaining .AbstractChainingListener.onWord(AbstractChainingListener.java:682)
at org.xwiki.rendering.block.WordBlock.traverse(WordBlock.java:53) at org .xwiki .rendering .block.AbstractFatherBlock.traverse(AbstractFatherBlock.java:68) at org .xwiki .rendering .internal .macro .html .XMLBlockConverterHandler.characters(XMLBlockConverterHandler.java: 146)
at org.xml.sax.helpers.XMLFilterImpl.characters(XMLFilterImpl.java: 564) at org .wikimodel .wem .xhtml .filter .XHTMLWhitespaceXMLFilter .sendCharacters(XHTMLWhitespaceXMLFilter.java:406) at org .wikimodel .wem .xhtml .filter .XHTMLWhitespaceXMLFilter .sendCharacters(XHTMLWhitespaceXMLFilter.java:400)
at org .wikimodel .wem .xhtml .filter .XHTMLWhitespaceXMLFilter .sendPreviousContent(XHTMLWhitespaceXMLFilter.java:245) at org .wikimodel .wem .xhtml .filter .XHTMLWhitespaceXMLFilter.flushContent(XHTMLWhitespaceXMLFilter.java: 279)
at org .wikimodel .wem .xhtml .filter .XHTMLWhitespaceXMLFilter.endElement(XHTMLWhitespaceXMLFilter.java: 173) at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java: 546) at org .wikimodel .wem .xhtml .filter.AccumulationXMLFilter.endElement(AccumulationXMLFilter.java: 69)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java: 546) at org .wikimodel .wem.xhtml.filter.DTDXMLFilter.endElement(DTDXMLFilter.java:70) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl $FragmentContentDispatcher.dispatch(Unknown Source) at org .apache .xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org .apache.xerces.parsers.XML11NonValidatingConfiguration.parse(Unknown Source) at org .apache.xerces.parsers.XML11NonValidatingConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333) at org .wikimodel .wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333) at org .wikimodel .wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
at org .wikimodel .wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48) at org .xwiki .rendering.internal.macro.html.HTMLMacro.parseXHTML(HTMLMacro.java: 212) ... 70 more
On Tue, May 5, 2009 at 5:07 PM, Pascal Voitot <[email protected]>wrote:
On Tue, May 5, 2009 at 5:04 PM, Vincent Massol <[email protected]> wrote:
On May 5, 2009, at 5:01 PM, Pascal Voitot wrote:
I will try to compile it and deploy it on my website...
To be quicker, what module have you modified?
xwiki-xml xwiki-rendering-api xwiki-rendering-macro-html
You can also wait for a snapshot build at http://maven.xwiki.org
I love compiling, this is a hobby ;););)
Thanks -Vincent
regards Pascal
On Tue, May 5, 2009 at 4:58 PM, Vincent Massol <[email protected]> wrote:
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
no better idea... a very special case to remind in the syntax help to my mind...
Just committed the new behavior. Would be great if some users/devs could verify it works on their use cases.
Thanks -Vincent
Pascal
On Tue, May 5, 2009 at 9:40 AM, Vincent Massol <[email protected] > wrote:
> After trying to implement it I've found the following caveats: > > * if the user wants an html comment he needs to escape the -- > * if the user wants a NL he'll need to enter <br/> > * if the user wants a paragraph he'll need to enter <p>...</p> > * And the most problematic one IMO: the user needs to be very > careful > about new lines since: > > <table> > <tr> > <td> > * [[listitem]] > </td> > </tr> > </table> > > is very different from > > <table> > <tr> > <td> > * [[listitem]] > > </td> > </tr> > </table> > > In the first case the </td>, </tr> and </table> and > continuation of > the list item written in wiki syntax since the wiki parser > accepts > multiline content... hence you'll get in XHTML: > > <table><tbody><tr><td><ul><li><!--startwikilink:listitem--><span > class="wikicreatelink"><a href="/xwiki/bin/view/listitem? > parent=xwiki:Space.Page"><span > class="wikigeneratedlinkcontent">Page</ > span></a></span><!--stopwikilink--></td></tr></tbody></table></ > li></ > ul> > > which is completely invalid. > > The same applies for: > > {{macro/}} > </td> > > vs > > {{macro/}} > > </td> > > in the first case the macro is inline and will generate inline > content > and in the second case it's standalone. > > Still trying to figure out a best solution but I don't see one > right > now... > > If you have any idea, shoot! > > Thanks > -Vincent > > On May 4, 2009, at 3:25 PM, Vincent Massol wrote: > >> Hi, >> >> After discussing with Thomas we've reached the conclusion >> that we >> should change the way the HTML macro handle its content when >> wiki=true. >> For ex take the following input: >> >> {{velocity}} >> ... >> {{html wiki="true"}} >> <form> >> $xwiki.includeForm("XWiki.MyClassSheet") >> <br /> >> <p> >> <input type="submit" name="submit" value="Create this new >> Workpackage" /> >> </p> >> </form> >> {{/html}} >> ... >> {{/velocity}} >> >> And assume that MyClassSheet has some $doc.display() velocity >> code >> which thus generate {{html}} macros. >> >> Current Result >> ============ >> >> Right now here's what happens: >> 1) velocity macro is executed and $xwiki.includeForm executes >> 2) MyClassSheet generate {{html}} macro content thus yielding: >> >> {{html wiki="true"}} >> <form> >> {{html}}...<someTag>...</someTag>{{/html}} >> </form> >> {{/html}} >> >> 3) After velocity has finished executing the velocity macro >> calls >> the wiki parser on the result and thus the top level HTML macro >> executes >> 4) since wiki=true the content is given to a SAX parser and >> each >> XML >> tag content is given to the wiki parser. Thus "{{html}}...", >> "..." >> and "{{/html}}" will be parser by the wiki parser separately >> (because <someTag> is valid XML), thus generating non expected >> content as a result. >> >> Proposed change >> ============== >> >> Modify the HTML behavior so that the wiki parser executes first >> (instead of the SAX parser) and render the result using a >> special >> renderer that prints the special symbols and text as is. >> >> When run on our example this would give (same steps 1) and 2)): >> >> 3) wiki parser executes and generate XDOM. Render it using the >> special renderer >> >> Note that this means that if in HTML your write content that >> has a >> meaning in some wiki syntax you'll need to escape it. For >> example if >> you have: >> >> {{html wiki=true}} >> <!--hello--> >> {{/html}} >> >> you'll get some strikethrough. So you'll need to write instead: >> >> {{html wiki=true}} >> <!~-~-hello~-~-> >> {{/html}} >> >> WDYT? >> >> Here's my +1 >> >> Thanks >> -Vincent
On Wed, May 6, 2009 at 2:45 PM, Vincent Massol <[email protected]> wrote:
On May 6, 2009, at 2:31 PM, Pascal Voitot wrote:
Just a quick question, I have recompiled my server with your last commits and when I write this page:
{{velocity}} {{html wiki="true"}} #warning("(% style='font-size: 130%;' %)blablabla") {{/html}} {{/velocity}}
I get the following exception...
Can you confirm it works on your test server? It would confirm I have a problem on my server...
yes works fine here.
Thanks, I will clean and recompile from scratch...
Thanks -Vincent
thanks Pascal
org.xwiki.rendering.macro.MacroExecutionException: Failed to parse HTML content [<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><div class="warningmessage"><span class="messagetype">Warning: </span>(% style='font-size: 130%;' %)blablabla</div></html>
] at org .xwiki .rendering.internal.macro.html.HTMLMacro.parseXHTML(HTMLMacro.java: 215) at org .xwiki .rendering.internal.macro.html.HTMLMacro.execute(HTMLMacro.java:175) at org .xwiki .rendering.internal.macro.html.HTMLMacro.execute(HTMLMacro.java:61)
at org .xwiki .rendering .internal .transformation .MacroTransformation.transformOnce(MacroTransformation.java:169) at org .xwiki .rendering .internal .transformation .MacroTransformation.transform(MacroTransformation.java:113)
at org .xwiki .rendering .internal .transformation .DefaultTransformationManager .performTransformations(DefaultTransformationManager.java:72) at com .xpn .xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java: 5123)
at com .xpn .xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java: 5096) at com .xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java: 531) at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:472)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.velocity.util.introspection.UberspectImpl $VelMethodImpl.invoke(UberspectImpl.java:295) at org .apache .velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245)
at org .apache .velocity.runtime.parser.node.ASTReference.execute(ASTReference.java: 203) at org .apache .velocity.runtime.parser.node.ASTReference.render(ASTReference.java: 294) at org .apache .velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318)
at org .xwiki .velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java: 178) at org .xwiki .velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java: 143) at com .xpn .xwiki .render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:108)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1611) at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:124) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:226) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115)
at org .apache .struts .action.RequestProcessor.processActionPerform(RequestProcessor.java: 431) at org .apache.struts.action.RequestProcessor.process(RequestProcessor.java: 236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java: 1196)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:
432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1124) at com .xpn .xwiki .wysiwyg .server.filter.ConversionFilter.doFilter(ConversionFilter.java:145) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115)
at com .xpn .xwiki .web .SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java: 295) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115) at com .xpn .xwiki .web .SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java: 112)
at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 361) at org .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 417)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:334) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126) at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:103) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115)
at com .xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java: 68) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115) at com .xpn .xwiki .web .SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java: 295)
at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115) at com .xpn .xwiki .web .SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java: 112) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1115)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 361) at org .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 417) at org .mortbay .jetty .handler .ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org .mortbay .jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 152) at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 535) at org.mortbay.jetty.HttpConnection $RequestHandler.content(HttpConnection.java:880) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:746)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 409)
at org.mortbay.thread.QueuedThreadPool $PoolThread.run(QueuedThreadPool.java:522) Caused by: java.lang.ClassCastException: org.xwiki.rendering.renderer.printer.XHTMLWikiPrinter at org .xwiki .rendering .internal.renderer.printer.WikiWriter.getWikiPrinter(WikiWriter.java: 46)
at org .xwiki .rendering .internal.renderer.printer.WikiWriter.write(WikiWriter.java:93) at org.dom4j.io.XMLWriter.writeString(XMLWriter.java:1266) at org.dom4j.io.XMLWriter.write(XMLWriter.java:492) at org .xwiki .rendering .renderer.printer.XMLWikiPrinter.printXML(XMLWikiPrinter.java:80)
at org .xwiki .rendering .renderer.printer.XHTMLWikiPrinter.printXML(XHTMLWikiPrinter.java:64) at org .xwiki .rendering .internal .renderer .chaining.XHTMLChainingRenderer.onWord(XHTMLChainingRenderer.java:338) at org .xwiki .rendering .listener .chaining .AbstractChainingListener.onWord(AbstractChainingListener.java:682)
at org .xwiki .rendering .listener .chaining .BlockStateChainingListener.onWord(BlockStateChainingListener.java: 855) at org .xwiki .rendering .listener .chaining .AbstractChainingListener.onWord(AbstractChainingListener.java:682)
at org.xwiki.rendering.block.WordBlock.traverse(WordBlock.java:53) at org .xwiki .rendering .block.AbstractFatherBlock.traverse(AbstractFatherBlock.java:68) at org .xwiki .rendering .internal .macro .html .XMLBlockConverterHandler.characters(XMLBlockConverterHandler.java: 146)
at org.xml.sax.helpers.XMLFilterImpl.characters(XMLFilterImpl.java: 564) at org .wikimodel .wem .xhtml .filter .XHTMLWhitespaceXMLFilter .sendCharacters(XHTMLWhitespaceXMLFilter.java:406) at org .wikimodel .wem .xhtml .filter .XHTMLWhitespaceXMLFilter .sendCharacters(XHTMLWhitespaceXMLFilter.java:400)
at org .wikimodel .wem .xhtml .filter .XHTMLWhitespaceXMLFilter .sendPreviousContent(XHTMLWhitespaceXMLFilter.java:245) at org .wikimodel .wem .xhtml .filter .XHTMLWhitespaceXMLFilter.flushContent(XHTMLWhitespaceXMLFilter.java: 279)
at org .wikimodel .wem .xhtml .filter .XHTMLWhitespaceXMLFilter.endElement(XHTMLWhitespaceXMLFilter.java: 173) at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java: 546) at org .wikimodel .wem .xhtml .filter.AccumulationXMLFilter.endElement(AccumulationXMLFilter.java: 69)
at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java: 546) at org .wikimodel .wem.xhtml.filter.DTDXMLFilter.endElement(DTDXMLFilter.java:70) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl $FragmentContentDispatcher.dispatch(Unknown Source) at org .apache .xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org .apache.xerces.parsers.XML11NonValidatingConfiguration.parse(Unknown Source) at org .apache.xerces.parsers.XML11NonValidatingConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333) at org .wikimodel .wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333) at org .wikimodel .wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
at org .wikimodel .wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48) at org .xwiki .rendering.internal.macro.html.HTMLMacro.parseXHTML(HTMLMacro.java: 212) ... 70 more
On Tue, May 5, 2009 at 5:07 PM, Pascal Voitot <[email protected]>wrote:
On Tue, May 5, 2009 at 5:04 PM, Vincent Massol <[email protected]> wrote:
On May 5, 2009, at 5:01 PM, Pascal Voitot wrote:
I will try to compile it and deploy it on my website...
To be quicker, what module have you modified?
xwiki-xml xwiki-rendering-api xwiki-rendering-macro-html
You can also wait for a snapshot build at http://maven.xwiki.org
I love compiling, this is a hobby ;););)
Thanks -Vincent
regards Pascal
On Tue, May 5, 2009 at 4:58 PM, Vincent Massol <[email protected]> wrote:
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
> no better idea... > a very special case to remind in the syntax help to my mind...
Just committed the new behavior. Would be great if some users/devs could verify it works on their use cases.
Thanks -Vincent
> Pascal > > On Tue, May 5, 2009 at 9:40 AM, Vincent Massol <[email protected] > > > wrote: > >> After trying to implement it I've found the following caveats: >> >> * if the user wants an html comment he needs to escape the -- >> * if the user wants a NL he'll need to enter <br/> >> * if the user wants a paragraph he'll need to enter <p>...</p> >> * And the most problematic one IMO: the user needs to be very >> careful >> about new lines since: >> >> <table> >> <tr> >> <td> >> * [[listitem]] >> </td> >> </tr> >> </table> >> >> is very different from >> >> <table> >> <tr> >> <td> >> * [[listitem]] >> >> </td> >> </tr> >> </table> >> >> In the first case the </td>, </tr> and </table> and >> continuation of >> the list item written in wiki syntax since the wiki parser >> accepts >> multiline content... hence you'll get in XHTML: >> >> <table><tbody><tr><td><ul><li><!--startwikilink:listitem--><span >> class="wikicreatelink"><a href="/xwiki/bin/view/listitem? >> parent=xwiki:Space.Page"><span >> class="wikigeneratedlinkcontent">Page</ >> span></a></span><!--stopwikilink--></td></tr></tbody></table></ >> li></ >> ul> >> >> which is completely invalid. >> >> The same applies for: >> >> {{macro/}} >> </td> >> >> vs >> >> {{macro/}} >> >> </td> >> >> in the first case the macro is inline and will generate inline >> content >> and in the second case it's standalone. >> >> Still trying to figure out a best solution but I don't see one >> right >> now... >> >> If you have any idea, shoot! >> >> Thanks >> -Vincent >> >> On May 4, 2009, at 3:25 PM, Vincent Massol wrote: >> >>> Hi, >>> >>> After discussing with Thomas we've reached the conclusion >>> that we >>> should change the way the HTML macro handle its content when >>> wiki=true. >>> For ex take the following input: >>> >>> {{velocity}} >>> ... >>> {{html wiki="true"}} >>> <form> >>> $xwiki.includeForm("XWiki.MyClassSheet") >>> <br /> >>> <p> >>> <input type="submit" name="submit" value="Create this new >>> Workpackage" /> >>> </p> >>> </form> >>> {{/html}} >>> ... >>> {{/velocity}} >>> >>> And assume that MyClassSheet has some $doc.display() velocity >>> code >>> which thus generate {{html}} macros. >>> >>> Current Result >>> ============ >>> >>> Right now here's what happens: >>> 1) velocity macro is executed and $xwiki.includeForm executes >>> 2) MyClassSheet generate {{html}} macro content thus yielding: >>> >>> {{html wiki="true"}} >>> <form> >>> {{html}}...<someTag>...</someTag>{{/html}} >>> </form> >>> {{/html}} >>> >>> 3) After velocity has finished executing the velocity macro >>> calls >>> the wiki parser on the result and thus the top level HTML macro >>> executes >>> 4) since wiki=true the content is given to a SAX parser and >>> each >>> XML >>> tag content is given to the wiki parser. Thus "{{html}}...", >>> "..." >>> and "{{/html}}" will be parser by the wiki parser separately >>> (because <someTag> is valid XML), thus generating non expected >>> content as a result. >>> >>> Proposed change >>> ============== >>> >>> Modify the HTML behavior so that the wiki parser executes first >>> (instead of the SAX parser) and render the result using a >>> special >>> renderer that prints the special symbols and text as is. >>> >>> When run on our example this would give (same steps 1) and 2)): >>> >>> 3) wiki parser executes and generate XDOM. Render it using the >>> special renderer >>> >>> Note that this means that if in HTML your write content that >>> has a >>> meaning in some wiki syntax you'll need to escape it. For >>> example if >>> you have: >>> >>> {{html wiki=true}} >>> <!--hello--> >>> {{/html}} >>> >>> you'll get some strikethrough. So you'll need to write instead: >>> >>> {{html wiki=true}} >>> <!~-~-hello~-~-> >>> {{/html}} >>> >>> WDYT? >>> >>> Here's my +1 >>> >>> Thanks >>> -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Marius Dumitru Florea -
Pascal Voitot -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol