On Sat, Apr 2, 2016 at 4:25 PM, Vincent Massol <vincent(a)massol.net> wrote:
On 02 Apr 2016, at 16:21, Vincent Massol
<vincent(a)massol.net> wrote:
On 02 Apr 2016, at 16:13, Vincent Massol <vincent(a)massol.net> wrote:
On 02 Apr 2016, at 15:38, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
One issue we have ATM is that the xhtml/1.0 parser requires valid XHTML but the xhtml/1.0
renderer generates invalid XHTML (it generates fragments only). This causes
https://jira.xwiki.org/browse/XWIKI-13278 for example.
I’m proposing to:
* Modify "xhtml/1.0" renderer to generate valid XHTML (i.e. xml declaration +
doctype + html element)
* Introduce a new "xhtmlfragment/1.0” renderer
* Have annotated versions of both for the WYSIWYG editor
WDYT?
Several points:
* The change above could be rationalized as fixing a bug since it’s not normal that an
XHTML/1.0 renderer would generate invalid XHTML
* It’s potentially going to break some scripts. For example if you have in a custom vm:
$services.rendering.render($panelUix.execute(), "xhtml/1.0”)
Thus if we want to make sure that we don’t break backward compatibility we should
instead:
* Deprecate the “xhtml/1.0” renderer
* Introduce 2 new renderers instead of one: “xhtmlfull/1.0” and “xhtmlfragment/1.0”
* The problem is that this is not going to work nicely since it would mean we would also
need to have parsers for those and the admins would need to decide which syntax to allow
in his wiki amongst: xhtmlfull/1.0, xhtml/1.0, html/4.01, xhtmlfragment/1.0. That’s a lot
to choose from…
So we have 2 real choices I think:
* Do as I suggested above but break backward compat in some places (we need to assess
more precisely where it would break)
* Or instead make the xhtml/1.0 parser support reading fragments. The advantage with this
is that it won’t break backward compat. The cons is that it’s quite hard to implement
since we have a stream/reader as input and there are plenty of ways to write xhtml. But we
could decide that we only support the following use case:
** Read the first char and if it’s not ‘<‘ then add declaration + doctype + html
** If the first char is ‘<‘ then don’t add anything
Right now I’m going to try implementing this. Let me know what you think.
I’ve thought about another possibility. Implement a "xhtml/1.1” parser/renderer
instead. It could also comply with XHTML 1.1.
We would “deprecate” the xhtml/1.0 syntax and favor using the 1.1 version.
This seems the best to me, wdyt? We’ve already added an html/5.0 renderer recently FTR.
To be clear this would mean:
* Introduce "xhtml/1.1" parser and renderer
* Introduce a “xhtmlfragment/1.1” renderer
We mostly moved to html 5 in XWiki UI so I don't see any value for
XWiki in adding more xhtml/* renderers.
Another option is to do the same but with xhtml/5.0 (especially since we’ve introduced
html/5.0 already).
A cleaner but a bit more expensive alternative is to refactor
renderers/parsers (maybe just renderers first) to filters which among
other things support configuration (technically similar to macros).
This mean you could easily set a boolean to indicate you want a
fragment or complete document, and many other things. Since filters
would still implement org.xwiki.rendering.listener.Listener interface
in practice it's usually easy to reimplement existing APIs without
breaking them.
This is something we need to do at some point anyway.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne