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/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
