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/