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