On Oct 22, 2009, at 11:32 AM, Thomas Mortagne wrote:
Hi,
On Thu, Oct 22, 2009 at 10:54, Asiri Rathnayake
<asiri.rathnayake(a)gmail.com> wrote:
Hello Devs,
As I understand, If a wiki macro supports inline mode and is
executed as an
inline macro, it must be true that the output generated by the
macro does
not contain block elements (otherwise the result will not be
inline). From
the wiki macro bridge code we have the following check:
<code>
List<Block> result = xdom.getChildren();
// If in inline mode remove any top level paragraph.
if (context.isInline()) {
this.parserUtils.removeTopLevelParagraph(result);
}
</code>
This only removes the top-level paragraph block. It's possible that
inside
the content there are more block level elements, I think this is
where we
need the inline parser.
Another problem i discovered is if i have a wiki macro with macro
code:
<code>
{{velocity}}
.....
{{/velocity}}
</code>
This makes the {{velocity}} macro behave in a non-inline fashion
regardless
of the wiki macro's intentions. Further more, the paragraph block
generated
by the {{velocity}} macro is not stripped by the check I mentioned
above.
This is because the paragraph block resides inside a
MacroMarkerBlock (so it
is not a top-level paragraph).
A workaround I found for this problem is to have something like:
<code>
{{html}}{{/html}}{{velocity}}
.....
{{/velocity}}
</code>
This is only a hack to force the {{velocity}} macro ro behave in an
inline
fashion.
Now I'm wondering if we should wait for the inline parser to be
available to
fix this or do some custom hacking to get rid of the block elements
generated while executing in inline mode. wdyt?
I depends what priority we put in inline parser but for now it's not
at the top of the list. In the meantime since it sounds too much of a
pain for wiki macros use case a workaround you could use is to make
the found macro in the XDOM inline by calling
MacroBlock#setInline(true) (to be added) before launching
transformations.
ok I'm fine with this even though it make them no monger immutable but
since the children/parent/params can already be modified, why not.
The issue with inline parser is that having inline
parser now mean
create a totally new parser from scratch and support 2 different
parsers instead of one for each syntax which mean at least xwiki/2.0
and xhtml/1.0 (and soon 2.1 syntax). (Even if inline parser is a lot
easier to do than "normal" parser and we can maybe reuse some parts in
XHTML parser). The difficult part is not really to do xwiki/2.0 inline
parser but the fact that it's just one syntax among others.
Now since we starting to have too many use cases for inline parser
maybe we should put it at the top of the list. We did not done it
until now because of the duplicate thing waiting for a genius idea i
guess ;)
yep that's the reason :)
I would me +0.5 to start working on inline parser api
and quickly do a
duplicate based xwiki/2.0 implementation (and use some remove top
paragraph workaround for others syntaxes implementations) waiting for
a better generic way at WikiModel level.
WDYT ?
I remember Mikhail was ok to add inline parser notion to wikimodel; he
even wanted to work on it but it's a big change so he never got to do
it...
I'm ok that we work on it but we'd need to reuse a common javacc
grammar.
Thanks
-Vincent