Hello,
I'm back on this subject, so reviving this old thread ...
2012/5/29 Sergiu Dumitriu <sergiu(a)xwiki.com>
On Tuesday, May 29, 2012, Vincent Massol
<vincent(a)massol.net> wrote:
On May 29, 2012, at 10:35 AM, Jeremie BOUSQUET wrote:
>> Do you have other examples of stuff you absolutely don't want from
XWiki Syntax 2.1?
In fact
it's easiest to list what I want : only quotes, urls and
emoticons. Everything else should be escaped / rendered as plain text.
These 3 elements can safely be interpreted from email content and
bring nicer display, and there is no risk to break anything. The
quotes ">" as they are interpreted by xwiki syntax, adequately match
the usual quotes used in email bodies. Email content (when plain text)
should remain plain text and we should not interpret it in any way,
including xwiki 2.1 syntax, except for the 3 elements above IMO.
That's why I don't want any other feature of the syntax : I don't want
to reproduce some problems you can have with mail archives like nabble
or others, that provide the possibility to include specific keywords
in emails, that only them are then able to interpret ("<raw>"). When
you go back to your standard mail client, everything gets broken or
does not display at all. For richer emails format, we should use HTML,
and this is easy to get or display with xwiki.
Then your solution is to implement a new Syntax and a new Parser for that
Syntax,
see
http://rendering.xwiki.org/xwiki/bin/view/Main/Extending
ATM it's very difficult (read close to impossible) to reuse only parts of
an
existing Syntax parser. Of course you can copy paste existing JavaCC
grammars and remove what you don't need for example, that's what I mean by
write a new Parser. It's not that hard since all you need already exists
but it's still substantial work.
Wouldn't it be enough to disable transformations (except emoticon) and
write a new renderer similar to xhtml/1.0, except that most formatting
instructions will simply be printed as plain text instead of actual xhtml
elements? Extending renderers is easier than parsers.
I am currently trying to follow this path.
To take advantage of blockquotes replacement (replacing "> " blocks), and
icon transformations, I tried to parse my email plain text content with a
xwiki/2.1 parser to generate some XDOM, then feed this to a customized
xhtml/1.0 parser.
The issue is that in this XDOM, many things already have been interpreted
by the parser (for example, "**" into Format.BOLD, etc), and so if I want
to "forget" about those formatting instructions, my customized renderer as
to put back what should be the original text (with same example, do
something like printRaw("**") ). Putting back all this, pretty much looks
like rewritting an xwiki/2.1 renderer ...
So I changed my mind, and extended the XWikiSyntaxChainingRenderer (to sort
of render most things back to what they looked like before parsing), and
overrided only the parts I wanted to generate XHTML for (for example, I
overloaded the beginQuotation(), endQuotation() and beginQuotationLine()
methods). For these overloaded parts, I used an XHTMLWikiPrinter.
Going further in my Frankenstein mood, I created my own
"ChainingPrintRenderer", joyfully mixing together both worlds
(XHTMLRenderer and AbstractXWikiSyntaxRenderer) without no real
understanding of what I was doing, and put this in the initialize() :
ListenerChain chain = new XWikiSyntaxListenerChain();
setListenerChain(chain);
// Construct the listener chain in the right order. Listeners early
in the chain are called before listeners
// placed later in the chain.
chain.addListener(this);
chain.addListener(new LookaheadChainingListener(chain, 2));
chain.addListener(new GroupStateChainingListener(chain));
chain.addListener(new BlockStateChainingListener(chain));
chain.addListener(new
ConsecutiveNewLineStateChainingListener(chain));
chain.addListener(new EmptyBlockChainingListener(chain));
chain.addListener(new MetaDataStateChainingListener(chain));
chain.addListener(new XWikiSyntaxChainingRenderer(chain,
this.linkReferenceSerializer,
this.imageReferenceSerializer));
chain.addListener(new XHTMLEmailChainingRenderer(this.linkRenderer,
this.imageRenderer, chain));
Obviously, weird manipulations of mad scientist ... As the mad scientist of
the story, I created something that lives (and seems to produce something
close to what I expected), but with bad number of legs and arms, and now
I'm not sure on how to fix it.
Currently, though generated XDOM contains what I expect (some
QuotationBlock objects), it seems beginQuotation() is never triggered,
while endQuotation() correctly occurs when supposed to be... (in fact I
checked that beginQuotation() is never called).
This is a bit too ugly to ask for help, but in case you have any idea on
how to fix this ...
I'd prefer to write a real Parser (as initially recommended by Vincent),
but was frightened when looking at the samples ;-)
Thanks
-Vincent
> About macro transformation, I'll have a deeper look at the rendering
> framework though ...
>
> Thanks,
> Jeremie
>
> 2012/5/29 Vincent Massol <vincent(a)massol.net>et>:
>>
>> On May 29, 2012, at 10:16 AM, Jeremie BOUSQUET wrote:
>>
>>> Thanks Vincent,
>>>
>>>> IMO it might be a lot simpler to just support XWiki Syntax 2.1. And
you'll get additional features too.
>>> Of course, but for this specific
use-case I don't want the additional
>>> features :)
>>> For example if someone writes "{{code}}" in a mail, I don't
want it to
>>> be interpreted when displaying the mail.
>>
>> It won't if you don't run the macro transformation as I explained in my
first reply.
>>
>>> Maybe what could do the trick would be to support 2.1 as you say, and
>>> just escape what I don't want to be interpreted, ie replace
"{{" by
>>> "~{~{", "**" by "~*~*", "[[" by
"~[~[" and so on.
>>
>> No need for this.
>>
>> Do you have other examples of stuff you absolutely don't want from
XWiki Syntax 2.1?
>>
>> Thanks
>> -Vincent
>>
>> PS: BTW, you can read
http://rendering.xwiki.org to learn more about
the
Rendering module and Transformations.
>>
>>> Thanks,
>>> Jeremie
>>>
>>> 2012/5/29 Vincent Massol <vincent(a)massol.net>et>:
>>>> Hi Jeremie,
>>>>
>>>> On May 27, 2012, at 11:52 AM, Jeremie BOUSQUET wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> For the mail archiver app, I need to output mail content in a page.
I
>>>>> used to use it with html
content, and display is directly done with
>>>>> {{html}} macro.
>>>>>
>>>>> But most messages from mailing-lists are plain-text. My first idea
was
>>>>> to use {{code}}, and this is
fine.
>>>>> But I think display could be greatly improved using specific xwiki
>>>>> syntax rendering (2.1), but for some elements only.
>>>>>
>>>>> To do so, I would like to render some text string, not applying all
>>>>> syntax elements.
>>>>>
>>>>> Let me explain : what is interesting to render is :
>>>>> - quotes (lines starting with angle brackets '>'),
>>>>> - urls (replaced by links automatically),
>>>>> - emoticons
>>>>>
>>>>> Everything else (wiki macros, ...) should NOT be rendered.
>>>>>
>>>>> Is this possible ?
>>>>> Of course I don't want to impact the way xwiki renders pages.
>>>>
>>>> Short answer: no
>>>>
>>>> We have parsers for different syntaxes so you need to pick a syntax
fully.
>>>> The only thing that can be set on
or off are the transformations
(i.e. macro executions and emoticons) since those
are executed on the XDOM.
>>>>
>>>> Longer answer: you'd need to define your syntax and write a parser
for it. Depending on your syntax it can be easy or hard. Emoticons are
already supported so you won't need to add support for this. All you'll
need from your example are recognizing quotes and urls.
>>>>
>>>> IMO it might be a lot simpler to just support XWiki Syntax 2.1. And
you'll get additional features too.
>>>
>>> Hope it helps,
>>> -Vincent
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users