4 May
2009
4 May
'09
3:25 p.m.
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
4 May
4 May
3:38 p.m.
+1
On Mon, May 4, 2009 at 15:25, Vincent Massol <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
3:39 p.m.
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 <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:48 p.m.
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
3:51 p.m.
New subject: [xwiki-devs] [VOTE] Change of behavior for the HTML macro when wiki=true
+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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:05 p.m.
New subject: [xwiki-devs] [VOTE] Change of behavior for the HTML macro when wiki=true
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/
5 May
5 May
9:40 a.m.
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
4:16 p.m.
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 <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:58 p.m.
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 <vincent(a)massol.net>
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:01 p.m.
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 <vincent(a)massol.net> 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 <vincent(a)massol.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:04 p.m.
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 <vincent(a)massol.net>
wrote:
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 <vincent(a)massol.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:07 p.m.
On Tue, May 5, 2009 at 5:04 PM, Vincent Massol <vincent(a)massol.net> wrote:
On May 5, 2009, at 5:01 PM, Pascal Voitot wrote:
I love compiling, this is a hobby ;););)
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 <vincent(a)massol.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 <vincent(a)massol.net>
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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6 May
6 May
2:31 p.m.
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
<pascal.voitot.dev(a)gmail.com>wrote;wrote:
On Tue, May 5, 2009 at 5:04 PM, Vincent Massol <vincent(a)massol.net> wrote:
On May 5, 2009, at 5:01 PM, Pascal Voitot wrote:
I love compiling, this is a hobby ;););)
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 <vincent(a)massol.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
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 <vincent(a)massol.net>
> 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
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:45 p.m.
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
<pascal.voitot.dev(a)gmail.com>wrote;wrote:
>
>
> On Tue, May 5, 2009 at 5:04 PM, Vincent Massol <vincent(a)massol.net>
> 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 <vincent(a)massol.net>
>>> 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 <vincent(a)massol.net
>>>>> >
>>>>> 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
2:48 p.m.
On Wed, May 6, 2009 at 2:45 PM, Vincent Massol <vincent(a)massol.net> wrote:
On May 6, 2009, at 2:31 PM, Pascal Voitot wrote:
Thanks, I will clean and recompile from scratch...
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
> <pascal.voitot.dev(a)gmail.com>wrote;wrote:
>
>>
>>
>> On Tue, May 5, 2009 at 5:04 PM, Vincent Massol <vincent(a)massol.net>
>> 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
<vincent(a)massol.net>
>>>> 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
<vincent(a)massol.net
>>>>>> >
>>>>>> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5665
days inactive
5667
days old
14 comments
5 participants
participants (5)
-
Marius Dumitru Florea -
Pascal Voitot -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol