22 Apr
2009
22 Apr
'09
9:03 a.m.
On Apr 22, 2009, at 12:49 AM, Sergiu Dumitriu wrote:
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
Vincent Massol wrote:
What are the reasons? I saw only this:
The default would always be to clean the provided HTML (clean=true by
default) as in mentioned in:
Hi Sergiu,
On Apr 21, 2009, at 8:53 PM, Sergiu Dumitriu wrote:
Yes, I was just making it clearer, since you always referred to onXml
events and HTML content.
Vincent Massol wrote:
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. 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
Can you explain why you don't think it's good? (since I'm convinced
it
is right now for the reasons highlighted above) 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. >>>> * 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).