[xwiki-devs] [Proposal] Introduce new Raw event/block in rendering to replace the current XML events/blocks
Hi, We've had an interesting discussion with Thomas about the need to introduce a new onRawText() event in the rendering module to replace the current begin/endXML() events. Here's the need (discovered by Ludovic): * In some cases we want to inject rendered content directly in the renderer's output. For example there are some cases where we want to inject HTML directly (in order to bypass parsing) What we propose: * Remove the current XML events * Add a onRawText(Syntax syntax) event and a corresponding RawBlock block. A raw text is text injected directly in the rendered output without any parsing/modification. Note that the content depends completely on the rendered used hence the Syntax parameter. * Add a new {{raw syntax="syntaxId"}} macro so that users can inject content in the few cases where it's needed * Modify the HTML Macro to use RawBlock blocks instead of XMLBlock. Also add a new "clean=true|false" parameter (defaut is to clean). When clean = true, we pass the content to the HTML cleaner. <Implementation note>We still need to parse the content when wiki=true. We generate RawBlock blocks when we have startElement/ endElement/CDATA/Comment xml parser events.</Implementation note> This solves a number of issues: * We have a generic way to inject rendered content directly for the special cases when it's needed (ex: the user really wants to inject invalid HTML such as META tags in the body content) * We remove the XML events which were a bit weird to have in the first place. Note that we'll probably need to add some new events in the future such as one for demarcating a set of blocks (which would translate in DIV or SPAN in the XHTML renderer for example). This is needed for example for the Box Macro which is currently using XMLBlock but that's not completely correct. WDYT? Thanks -Vincent
+1 obviously On Thu, Apr 16, 2009 at 20:25, Vincent Massol <[email protected]> wrote:
Hi,
We've had an interesting discussion with Thomas about the need to introduce a new onRawText() event in the rendering module to replace the current begin/endXML() events.
Here's the need (discovered by Ludovic): * In some cases we want to inject rendered content directly in the renderer's output. For example there are some cases where we want to inject HTML directly (in order to bypass parsing)
What we propose: * Remove the current XML events * Add a onRawText(Syntax syntax) event and a corresponding RawBlock block. A raw text is text injected directly in the rendered output without any parsing/modification. Note that the content depends completely on the rendered used hence the Syntax parameter. * Add a new {{raw syntax="syntaxId"}} macro so that users can inject content in the few cases where it's needed * Modify the HTML Macro to use RawBlock blocks instead of XMLBlock. Also add a new "clean=true|false" parameter (defaut is to clean). When clean = true, we pass the content to the HTML cleaner.
<Implementation note>We still need to parse the content when wiki=true. We generate RawBlock blocks when we have startElement/ endElement/CDATA/Comment xml parser events.</Implementation note>
This solves a number of issues: * We have a generic way to inject rendered content directly for the special cases when it's needed (ex: the user really wants to inject invalid HTML such as META tags in the body content) * We remove the XML events which were a bit weird to have in the first place.
Note that we'll probably need to add some new events in the future such as one for demarcating a set of blocks (which would translate in DIV or SPAN in the XHTML renderer for example). This is needed for example for the Box Macro which is currently using XMLBlock but that's not completely correct.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Apr 16, 2009, at 8:25 PM, Vincent Massol wrote:
Hi,
We've had an interesting discussion with Thomas about the need to introduce a new onRawText() event in the rendering module to replace the current begin/endXML() events.
Here's the need (discovered by Ludovic): * In some cases we want to inject rendered content directly in the renderer's output. For example there are some cases where we want to inject HTML directly (in order to bypass parsing)
What we propose: * Remove the current XML events * Add a onRawText(Syntax syntax) event and a corresponding RawBlock block. A raw text is text injected directly in the rendered output without any parsing/modification. Note that the content depends completely on the rendered used hence the Syntax parameter. * Add a new {{raw syntax="syntaxId"}} macro so that users can inject content in the few cases where it's needed * Modify the HTML Macro to use RawBlock blocks instead of XMLBlock. Also add a new "clean=true|false" parameter (defaut is to clean). When clean = true, we pass the content to the HTML cleaner.
<Implementation note>We still need to parse the content when wiki=true. We generate RawBlock blocks when we have startElement/ endElement/CDATA/Comment xml parser events.</Implementation note>
Revised Implementation: * Always generate a single onRawText() event * In the case of wiki=true we 2 choices: ** remove this feature. I'm not sure we have any valid use cases for it ** if we keep it, then call the XHTML renderer to generate XHTML out of wiki syntax so that we can aggregate all HTML and generate a single onRawText() event -Vincent
This solves a number of issues: * We have a generic way to inject rendered content directly for the special cases when it's needed (ex: the user really wants to inject invalid HTML such as META tags in the body content) * We remove the XML events which were a bit weird to have in the first place.
Note that we'll probably need to add some new events in the future such as one for demarcating a set of blocks (which would translate in DIV or SPAN in the XHTML renderer for example). This is needed for example for the Box Macro which is currently using XMLBlock but that's not completely correct.
WDYT?
Thanks -Vincent
Vincent Massol wrote:
On Apr 16, 2009, at 8:25 PM, Vincent Massol wrote:
Hi,
We've had an interesting discussion with Thomas about the need to introduce a new onRawText() event in the rendering module to replace the current begin/endXML() events.
Here's the need (discovered by Ludovic): * In some cases we want to inject rendered content directly in the renderer's output. For example there are some cases where we want to inject HTML directly (in order to bypass parsing)
What we propose: * Remove the current XML events * Add a onRawText(Syntax syntax) event and a corresponding RawBlock block. A raw text is text injected directly in the rendered output without any parsing/modification. Note that the content depends completely on the rendered used hence the Syntax parameter. * Add a new {{raw syntax="syntaxId"}} macro so that users can inject content in the few cases where it's needed * Modify the HTML Macro to use RawBlock blocks instead of XMLBlock. Also add a new "clean=true|false" parameter (defaut is to clean). When clean = true, we pass the content to the HTML cleaner.
<Implementation note>We still need to parse the content when wiki=true. We generate RawBlock blocks when we have startElement/ endElement/CDATA/Comment xml parser events.</Implementation note>
Revised Implementation: * Always generate a single onRawText() event * In the case of wiki=true we 2 choices: ** remove this feature. I'm not sure we have any valid use cases for it ** if we keep it, then call the XHTML renderer to generate XHTML out of wiki syntax so that we can aggregate all HTML and generate a single onRawText() event
-Vincent
This solves a number of issues: * We have a generic way to inject rendered content directly for the special cases when it's needed (ex: the user really wants to inject invalid HTML such as META tags in the body content) * We remove the XML events which were a bit weird to have in the first place.
Note that we'll probably need to add some new events in the future such as one for demarcating a set of blocks (which would translate in DIV or SPAN in the XHTML renderer for example). This is needed for example for the Box Macro which is currently using XMLBlock but that's not completely correct.
WDYT?
I agree that we need a mechanism for entering raw content, but: - I don't think that it applies only to HTML. - I don't agree that it should be used instead of (or as the base for) the current HTML macro - what's the relation to the verbatim syntax? Could this be just one parameterized macro, with escapeXml as a parameter? -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi Sergiu, On Apr 21, 2009, at 8:53 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
On Apr 16, 2009, at 8:25 PM, Vincent Massol wrote:
Hi,
We've had an interesting discussion with Thomas about the need to introduce a new onRawText() event in the rendering module to replace the current begin/endXML() events.
Here's the need (discovered by Ludovic): * In some cases we want to inject rendered content directly in the renderer's output. For example there are some cases where we want to inject HTML directly (in order to bypass parsing)
What we propose: * Remove the current XML events * Add a onRawText(Syntax syntax) event and a corresponding RawBlock block. A raw text is text injected directly in the rendered output without any parsing/modification. Note that the content depends completely on the rendered used hence the Syntax parameter. * Add a new {{raw syntax="syntaxId"}} macro so that users can inject content in the few cases where it's needed * Modify the HTML Macro to use RawBlock blocks instead of XMLBlock. Also add a new "clean=true|false" parameter (defaut is to clean). When clean = true, we pass the content to the HTML cleaner.
<Implementation note>We still need to parse the content when wiki=true. We generate RawBlock blocks when we have startElement/ endElement/CDATA/Comment xml parser events.</Implementation note>
Revised Implementation: * Always generate a single onRawText() event * In the case of wiki=true we 2 choices: ** remove this feature. I'm not sure we have any valid use cases for it ** if we keep it, then call the XHTML renderer to generate XHTML out of wiki syntax so that we can aggregate all HTML and generate a single onRawText() event
-Vincent
This solves a number of issues: * We have a generic way to inject rendered content directly for the special cases when it's needed (ex: the user really wants to inject invalid HTML such as META tags in the body content) * We remove the XML events which were a bit weird to have in the first place.
Note that we'll probably need to add some new events in the future such as one for demarcating a set of blocks (which would translate in DIV or SPAN in the XHTML renderer for example). This is needed for example for the Box Macro which is currently using XMLBlock but that's not completely correct.
WDYT?
I agree that we need a mechanism for entering raw content, but: - I don't think that it applies only to HTML.
I doesn't. The idea is to have a {{raw}} macro as mentioned above. The html macro would only be an alias for it for the "xhtml/1.0" syntax parameter.
- I don't agree that it should be used instead of (or as the base for) the current HTML macro
Can you explain why you don't think it's good? (since I'm convinced it is right now for the reasons highlighted above)
- what's the relation to the verbatim syntax? Could this be just one parameterized macro, with escapeXml as a parameter?
Verbatim is independent of the renderer. Raw isn't. Note sure what you mean with escapeXml (I don't see the relationship with xml). Thanks -Vincent
Vincent Massol wrote:
> Hi Sergiu,
>
> On Apr 21, 2009, at 8:53 PM, Sergiu Dumitriu wrote:
>
>> Vincent Massol wrote:
>>> On Apr 16, 2009, at 8:25 PM, Vincent Massol wrote:
>>>
>>>> Hi,
>>>>
>>>> We've had an interesting discussion with Thomas about the need to
>>>> introduce a new onRawText() event in the rendering module to replace
>>>> the current begin/endXML() events.
>>>>
>>>> Here's the need (discovered by Ludovic):
>>>> * In some cases we want to inject rendered content directly in the
>>>> renderer's output. For example there are some cases where we want to
>>>> inject HTML directly (in order to bypass parsing)
>>>>
>>>> What we propose:
>>>> * Remove the current XML events
>>>> * Add a onRawText(Syntax syntax) event and a corresponding RawBlock
>>>> block. A raw text is text injected directly in the rendered output
>>>> without any parsing/modification. Note that the content depends
>>>> completely on the rendered used hence the Syntax parameter.
>>>> * Add a new {{raw syntax="syntaxId"}} macro so that users can inject
>>>> content in the few cases where it's needed
>>>> * Modify the HTML Macro to use RawBlock blocks instead of XMLBlock.
>>>> Also add a new "clean=true|false" parameter (defaut is to clean).
>>>> When clean = true, we pass the content to the HTML cleaner.
>>>>
>>>> <Implementation note>We still need to parse the content when
>>>> wiki=true. We generate RawBlock blocks when we have startElement/
>>>> endElement/CDATA/Comment xml parser events.</Implementation note>
>>> Revised Implementation:
>>> * Always generate a single onRawText() event
>>> * In the case of wiki=true we 2 choices:
>>> ** remove this feature. I'm not sure we have any valid use cases
>>> for it
>>> ** if we keep it, then call the XHTML renderer to generate XHTML out
>>> of wiki syntax so that we can aggregate all HTML and generate a
>>> single
>>> onRawText() event
>>>
>>> -Vincent
>>>
>>>> This solves a number of issues:
>>>> * We have a generic way to inject rendered content directly for the
>>>> special cases when it's needed (ex: the user really wants to inject
>>>> invalid HTML such as META tags in the body content)
>>>> * We remove the XML events which were a bit weird to have in the
>>>> first place.
>>>>
>>>> Note that we'll probably need to add some new events in the future
>>>> such as one for demarcating a set of blocks (which would translate
>>>> in DIV or SPAN in the XHTML renderer for example). This is needed
>>>> for example for the Box Macro which is currently using XMLBlock but
>>>> that's not completely correct.
>>>>
>>>> WDYT?
>> I agree that we need a mechanism for entering raw content, but:
>> - I don't think that it applies only to HTML.
>
> I doesn't. The idea is to have a {{raw}} macro as mentioned above. The
> html macro would only be an alias for it for the "xhtml/1.0" syntax
> parameter.
Yes, I was just making it clearer, since you always referred to onXml
events and HTML content.
>> - I don't agree that it should be used instead of (or as the base for)
>> the current HTML macro
>
> Can you explain why you don't think it's good? (since I'm convinced it
> is right now for the reasons highlighted above)
What are the reasons? I saw only this:
> Here's the need (discovered by Ludovic):
> * In some cases we want to inject rendered content directly in the
> renderer's output. For example there are some cases where we want to
> inject HTML directly (in order to bypass parsing)
This means that sometimes ("in some cases") we want to force some
invalid XHTML inside the document. But I don't agree that by default we
should accept anything the user provides, and that we shouldn't try to
force as much as possible the users to write valid XHTML. That's why I
think that the html macro should continue to clean and validate the
markup, and another macro should simply dump the passed content in the
resulting HTML.
>> - what's the relation to the verbatim syntax? Could this be just one
>> parameterized macro, with escapeXml as a parameter?
>
> Verbatim is independent of the renderer. Raw isn't.
>
> Note sure what you mean with escapeXml (I don't see the relationship
> with xml).
Normal content: <, > and & generate special symbol events, which are
escaped in the HTML renderer.
Verbatim with escapeXml=false: <, > and & are treated as normal
characters, which get printed as-is by the HTML renderer.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Apr 22, 2009, at 12:49 AM, Sergiu Dumitriu wrote:
> Vincent Massol wrote:
>> Hi Sergiu,
>>
>> On Apr 21, 2009, at 8:53 PM, Sergiu Dumitriu wrote:
>>
>>> Vincent Massol wrote:
>>>> On Apr 16, 2009, at 8:25 PM, Vincent Massol wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We've had an interesting discussion with Thomas about the need to
>>>>> introduce a new onRawText() event in the rendering module to
>>>>> replace
>>>>> the current begin/endXML() events.
>>>>>
>>>>> Here's the need (discovered by Ludovic):
>>>>> * In some cases we want to inject rendered content directly in the
>>>>> renderer's output. For example there are some cases where we
>>>>> want to
>>>>> inject HTML directly (in order to bypass parsing)
>>>>>
>>>>> What we propose:
>>>>> * Remove the current XML events
>>>>> * Add a onRawText(Syntax syntax) event and a corresponding
>>>>> RawBlock
>>>>> block. A raw text is text injected directly in the rendered output
>>>>> without any parsing/modification. Note that the content depends
>>>>> completely on the rendered used hence the Syntax parameter.
>>>>> * Add a new {{raw syntax="syntaxId"}} macro so that users can
>>>>> inject
>>>>> content in the few cases where it's needed
>>>>> * Modify the HTML Macro to use RawBlock blocks instead of
>>>>> XMLBlock.
>>>>> Also add a new "clean=true|false" parameter (defaut is to clean).
>>>>> When clean = true, we pass the content to the HTML cleaner.
>>>>>
>>>>> <Implementation note>We still need to parse the content when
>>>>> wiki=true. We generate RawBlock blocks when we have startElement/
>>>>> endElement/CDATA/Comment xml parser events.</Implementation note>
>>>> Revised Implementation:
>>>> * Always generate a single onRawText() event
>>>> * In the case of wiki=true we 2 choices:
>>>> ** remove this feature. I'm not sure we have any valid use cases
>>>> for it
>>>> ** if we keep it, then call the XHTML renderer to generate XHTML
>>>> out
>>>> of wiki syntax so that we can aggregate all HTML and generate a
>>>> single
>>>> onRawText() event
>>>>
>>>> -Vincent
>>>>
>>>>> This solves a number of issues:
>>>>> * We have a generic way to inject rendered content directly for
>>>>> the
>>>>> special cases when it's needed (ex: the user really wants to
>>>>> inject
>>>>> invalid HTML such as META tags in the body content)
>>>>> * We remove the XML events which were a bit weird to have in the
>>>>> first place.
>>>>>
>>>>> Note that we'll probably need to add some new events in the future
>>>>> such as one for demarcating a set of blocks (which would translate
>>>>> in DIV or SPAN in the XHTML renderer for example). This is needed
>>>>> for example for the Box Macro which is currently using XMLBlock
>>>>> but
>>>>> that's not completely correct.
>>>>>
>>>>> WDYT?
>>> I agree that we need a mechanism for entering raw content, but:
>>> - I don't think that it applies only to HTML.
>>
>> I doesn't. The idea is to have a {{raw}} macro as mentioned above.
>> The
>> html macro would only be an alias for it for the "xhtml/1.0" syntax
>> parameter.
>
> Yes, I was just making it clearer, since you always referred to onXml
> events and HTML content.
>
>>> - I don't agree that it should be used instead of (or as the base
>>> for)
>>> the current HTML macro
>>
>> Can you explain why you don't think it's good? (since I'm convinced
>> it
>> is right now for the reasons highlighted above)
>
> What are the reasons? I saw only this:
>
>> Here's the need (discovered by Ludovic):
>> * In some cases we want to inject rendered content directly in the
>> renderer's output. For example there are some cases where we want to
>> inject HTML directly (in order to bypass parsing)
>
> This means that sometimes ("in some cases") we want to force some
> invalid XHTML inside the document. But I don't agree that by default
> we
> should accept anything the user provides, and that we shouldn't try to
> force as much as possible the users to write valid XHTML. That's why I
> think that the html macro should continue to clean and validate the
> markup, and another macro should simply dump the passed content in the
> resulting HTML.
The default would always be to clean the provided HTML (clean=true by
default) as in mentioned in:
>>>>> * Modify the HTML Macro to use RawBlock blocks instead of
>>>>> XMLBlock.
>>>>> Also add a new "clean=true|false" parameter (defaut is to clean).
>>>>> When clean = true, we pass the content to the HTML cleaner.
So by default you'll have the exact same behavior as now. The idea is
only to change the underlying implementation since we don't want to
have too many duplicated events in our listener interface (no need for
begin/endXML + onRaw). Actually the begin/endXML have always been a
hack that I didn't like. I had to introduce them since I couldn't see
any other solution. Now the notion of injecting raw rendering content
into the renderers is a more general use case than begin/endXML and is
much more logical. So I really like it since it rationalize our HTML
injection with the HTML macro for ex.
>>> - what's the relation to the verbatim syntax? Could this be just one
>>> parameterized macro, with escapeXml as a parameter?
>>
>> Verbatim is independent of the renderer. Raw isn't.
>>
>> Note sure what you mean with escapeXml (I don't see the relationship
>> with xml).
>
> Normal content: <, > and & generate special symbol events, which are
> escaped in the HTML renderer.
>
> Verbatim with escapeXml=false: <, > and & are treated as normal
> characters, which get printed as-is by the HTML renderer.
ok but I really don't like this. Verbatim is supposed to contain
source content and not rendered content. Again it won't work with the
other renderers (input content is independent of the renderer, raw
content isn't). We would just reintroduce the problem we had with
begin/endXML but this time in the onVerbatim event.
Thanks
-Vincent
participants (3)
-
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol