On Oct 22, 2009, at 11:32 AM, Thomas Mortagne wrote: > Hi, > > On Thu, Oct 22, 2009 at 10:54, Asiri Rathnayake > <[email protected]> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
