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?
Thanks.
- Asiri
Hi,
The XWiki project is now fully set up on Nemo here:
http://nemo.sonarsource.org/components/index/XWIKI
Comments:
* Since our junit test no longer fail with memory issue they've added
back test coverage stats. Link to platform: http://nemo.sonarsource.org/project/index/178319
* They've just added the "Commented LOC" stat feature which shows the
number of lines of commented code. We shouldn't have any commented out
code so we'll need to gradually reduce this too.
* The test coverage don't count integration and functional tests, i.e.
if a unit tests tests code from another module the coverage is not
taken into account. Thus all our rendering tests in xwiki-rendering-
tests are not taken into account (they cover 90% of the rendering api
code...).
* Since they've added the unit tests the tech debt has gone down a
lot. I'll ask them why.
Thanks
-Vincent
On 10/19/2009 11:27 AM, vmassol (SVN) wrote:
> Author: vmassol
> Date: 2009-10-19 11:27:22 +0200 (Mon, 19 Oct 2009)
> New Revision: 24562
>
> Modified:
> platform/core/branches/xwiki-core-2.0/xwiki-core/pom.xml
> Log:
> XWIKI-4496: Unit tests need more heap space
>
> * Isolate tests.
>
> Merged from trunk (rev 24561)
>
> Modified: platform/core/branches/xwiki-core-2.0/xwiki-core/pom.xml
> ===================================================================
> --- platform/core/branches/xwiki-core-2.0/xwiki-core/pom.xml 2009-10-19 09:23:06 UTC (rev 24561)
> +++ platform/core/branches/xwiki-core-2.0/xwiki-core/pom.xml 2009-10-19 09:27:22 UTC (rev 24562)
> @@ -819,6 +819,14 @@
> </dependencies>
> <build>
> <plugins>
> +<plugin>
> +<groupId>org.apache.maven.plugins</groupId>
> +<artifactId>maven-surefire-plugin</artifactId>
> +<configuration>
> +<!-- Prevent Out Of Memory errors resulting from tests that do no free up the memory correctly -->
> +<forkMode>pertest</forkMode>
Does this affect performace? As in longer time to run the tests?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
Should we release 2.0.2 earlier than planned?
Right now it's planned for the 2nd of nov but we have 2 important
regressions and people are starting to upgrade to 2.0.1
* regression 1: office import doesn't work in multiwiki mode
* regression 2: a table followed by a block with params doesn't render
correctly (exception)
Thus I'm proposing that we release 2.0.2 tomorrow (Thomas is ok to do
it).
We have the following issues already fixed in 2.0.2:
http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10010…
Here's my +1
Thanks
-Vincent
Hi everyone,
It seems the code section in Xwiki page can display html tags with color
which is cool, but it seems it can not recognize Java code and display it
with color. If it can display all sort of codes with colors it will be
perfect.
Thanks.
-Leon