I think you commented out too many tests in this commit... :)
-Vincent
On Jan 31, 2009, at 7:22 PM, tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2009-01-31 19:22:16 +0100 (Sat, 31 Jan 2009)
> New Revision: 15982
>
> Modified:
> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
> java/org/xwiki/rendering/block/AbstractBlock.java
> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
> java/org/xwiki/rendering/block/Block.java
> platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-
> rendering-macro-toc/pom.xml
> platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-
> rendering-macro-toc/src/main/java/org/xwiki/rendering/internal/macro/
> toc/TocMacro.java
> platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-
> rendering-macro-toc/src/test/java/org/xwiki/rendering/
> RenderingTests.java
> Log:
> XWIKI-3174: Rename current SectionBlock to HeaderBlock and make
> SectionBlock represent the whole section content
> * improve toc macro execution based on new section block
>
> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/
> src/main/java/org/xwiki/rendering/block/AbstractBlock.java
> ===================================================================
> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
> java/org/xwiki/rendering/block/AbstractBlock.java 2009-01-31
> 18:02:32 UTC (rev 15981)
> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
> java/org/xwiki/rendering/block/AbstractBlock.java 2009-01-31
> 18:22:16 UTC (rev 15982)
> @@ -20,18 +20,18 @@
> package org.xwiki.rendering.block;
>
> import java.util.ArrayList;
> +import java.util.Collections;
> import java.util.LinkedHashMap;
> import java.util.List;
> import java.util.Map;
> -import java.util.Collections;
>
> import org.apache.commons.beanutils.ConvertUtils;
> import org.apache.commons.lang.builder.EqualsBuilder;
> import org.apache.commons.lang.builder.HashCodeBuilder;
>
> /**
> - * Implementation for Block operations. All blocks should extend
> this class. Supports the notion of parameters
> - * which can be added to a block (see {@link #setParameter(String,
> Object)} for more details).
> + * Implementation for Block operations. All blocks should extend
> this class. Supports the notion of parameters which can
> + * be added to a block (see {@link #setParameter(String, Object)}
> for more details).
> *
> * @version $Id$
> * @since 1.5M2
> @@ -70,7 +70,7 @@
> {
> this.parameters.putAll(parameters);
> }
> -
> +
> /**
> * {@inheritDoc}
> *
> @@ -194,15 +194,15 @@
> }
>
> /**
> - * Set a parameter on the current block. A parameter is any
> semantic data associated with a block.
> - * It can be used for various purposes and provide additional
> information to the renderers/listeners.
> - * For example you can pass style information such as
> <code>style="color:red"</code> (in that example
> - * the name would be <code>style</code> and the value
> <code>"color:red"</code>) to indicate that the
> - * current block should be displayed in red.
> + * Set a parameter on the current block. A parameter is any
> semantic data associated with a block. It can be used
> + * for various purposes and provide additional information to
> the renderers/listeners. For example you can pass
> + * style information such as <code>style="color:red"</code> (in
> that example the name would be <code>style</code>
> + * and the value <code>"color:red"</code>) to indicate that the
> current block should be displayed in red.
> + * <p>
> + * Note that there are currently no well-defined known
> parameter names and you'll need to check what the different
> + * renderers/listeners support to know what to use.
> + * </p>
> *
> - * <p>Note that there are currently no well-defined known
> parameter names and you'll need to check what
> - * the different renderers/listeners support to know what to
> use.</p>
> - *
> * @param name the parameter's name
> * @param value the parameter's value
> */
> @@ -285,7 +285,7 @@
>
> for (int i = index - 1; i >= 0; --i) {
> Block previousBlock = blocks.get(i);
> - if (previousBlock instanceof HeaderBlock) {
> + if
> (blockClass.isAssignableFrom(previousBlock.getClass())) {
> return (T) previousBlock;
> }
> }
> @@ -317,6 +317,7 @@
>
> /**
> * {@inheritDoc}
> + *
> * @see Object#clone()
> */
> @Override
> @@ -330,7 +331,7 @@
> throw new RuntimeException("Failed to clone object", e);
> }
> block.parameters = new LinkedHashMap<String,
> String>(getParameters());
> - // Clone all children blocks. Note that we cannot use an
> iterator since we're going to change the objects
> + // Clone all children blocks. Note that we cannot use an
> iterator since we're going to change the objects
> // themselves. Using an iterator would lead to a
> ConcurrentModificationException
> Object[] objectArray = getChildren().toArray();
> block.childrenBlocks = new ArrayList<Block>();
>
> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/
> src/main/java/org/xwiki/rendering/block/Block.java
> ===================================================================
> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
> java/org/xwiki/rendering/block/Block.java 2009-01-31 18:02:32 UTC
> (rev 15981)
> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
> java/org/xwiki/rendering/block/Block.java 2009-01-31 18:22:16 UTC
> (rev 15982)
> @@ -84,7 +84,7 @@
> * @param newBlocks the new blocks to replace the current block
> with
> */
> void replace(List<Block> newBlocks);
> -
> +
> /**
> * Get the parent block. All blocks have a parent and the top
> level parent is the {@link XDOM} object.
> *
> @@ -126,7 +126,7 @@
> <T extends Block> List<T> getChildrenByType(Class<T> blockClass,
> boolean recurse);
>
> /**
> - * Look forward to find a block which inherit or s provided type.
> + * Look forward to find a block which inherit or is provided
> type.
> *
> * @param <T> the class of the Blocks to return
> * @param blockClass the block class to look for
> @@ -135,9 +135,10 @@
> * @since 1.6M1
> */
> <T extends Block> T getPreviousBlockByType(Class<T> blockClass,
> boolean recurse);
> -
> +
> /**
> * {@inheritDoc}
> + *
> * @see Object#clone()
> */
> Block clone();
>
> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/
> xwiki-rendering-macro-toc/pom.xml
> ===================================================================
> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-
> rendering-macro-toc/pom.xml 2009-01-31 18:02:32 UTC (rev 15981)
> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-
> rendering-macro-toc/pom.xml 2009-01-31 18:22:16 UTC (rev 15982)
> @@ -43,11 +43,11 @@
> </includes>
> </configuration>
> </plugin>
> - <!-- plugin>
> - Apply the Checkstyle configurations defined in the top
> level pom.xml file
> + <plugin>
> + <!-- Apply the Checkstyle configurations defined in the top
> level pom.xml file -->
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-checkstyle-plugin</artifactId>
> - </plugin> -->
> + </plugin>
> </plugins>
> </build>
> </project>
>
> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/
> xwiki-rendering-macro-toc/src/main/java/org/xwiki/rendering/internal/
> macro/toc/TocMacro.java
> ===================================================================
> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-
> rendering-macro-toc/src/main/java/org/xwiki/rendering/internal/macro/
> toc/TocMacro.java 2009-01-31 18:02:32 UTC (rev 15981)
> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-
> rendering-macro-toc/src/main/java/org/xwiki/rendering/internal/macro/
> toc/TocMacro.java 2009-01-31 18:22:16 UTC (rev 15982)
> @@ -31,6 +31,7 @@
> import org.xwiki.rendering.block.ListItemBlock;
> import org.xwiki.rendering.block.NumberedListBlock;
> import org.xwiki.rendering.block.HeaderBlock;
> +import org.xwiki.rendering.block.SectionBlock;
> import org.xwiki.rendering.internal.util.EnumConverter;
> import org.xwiki.rendering.listener.Link;
> import org.xwiki.rendering.macro.AbstractMacro;
> @@ -108,26 +109,30 @@
> // Get the root block from scope parameter
>
> Block root;
> - HeaderBlock rootSectionBlock = null;
>
> - if (parameters.getScope() == Scope.LOCAL &&
> context.getCurrentMacroBlock() != null) {
> + if (parameters.getScope() == Scope.LOCAL) {
> root = context.getCurrentMacroBlock().getParent();
> - rootSectionBlock =
> context
> .getCurrentMacroBlock().getPreviousBlockByType(HeaderBlock.class,
> true);
> } else {
> root = context.getXDOM();
> }
>
> // Get the list of sections in the scope
>
> - List<HeaderBlock> sections =
> root.getChildrenByType(HeaderBlock.class, true);
> + List<HeaderBlock> headers =
> root.getChildrenByType(HeaderBlock.class, true);
>
> - if (!sections.isEmpty()) {
> - // Construct table of content from sections list
> - Block rootBlock =
> - generateTree(sections, parameters.getStart(),
> parameters.getDepth(), parameters.isNumbered(),
> - rootSectionBlock);
> + if (!headers.isEmpty()) {
> + // If the root block is a section, remove it's header
> block for the list of header blocks
> + if (root instanceof SectionBlock) {
> + Block block = root.getChildren().get(0);
>
> - return Arrays.asList(rootBlock);
> + if (block instanceof HeaderBlock) {
> + headers.remove(block);
> + }
> + }
> +
> + // Construct table of content from sections list
> + return Arrays.asList(generateTree(headers,
> parameters.getStart(), parameters.getDepth(), parameters
> + .isNumbered()));
> }
>
> return Collections.emptyList();
> @@ -142,47 +147,31 @@
> }
>
> /**
> - * Convert sections into list block tree.
> + * Convert headers into list block tree.
> *
> - * @param sections the sections to convert.
> + * @param headers the headers to convert.
> * @param start the "start" parameter value.
> * @param depth the "depth" parameter value.
> * @param numbered the "numbered" parameter value.
> - * @param rootSectionBlock the section where the toc macro
> search for children sections.
> * @return the root block of generated block tree.
> */
> - private Block generateTree(List<HeaderBlock> sections, int
> start, int depth, boolean numbered,
> - HeaderBlock rootSectionBlock)
> + private Block generateTree(List<HeaderBlock> headers, int
> start, int depth, boolean numbered)
> {
> - int rootSectionLevel = rootSectionBlock != null ?
> rootSectionBlock.getLevel().getAsInt() : 0;
> - boolean rootSectionFound = false;
> -
> int currentLevel = 0;
> Block currentBlock = null;
> - for (HeaderBlock sectionBlock : sections) {
> - int sectionLevel = sectionBlock.getLevel().getAsInt();
> + for (HeaderBlock headerBlock : headers) {
> + int headerLevel = headerBlock.getLevel().getAsInt();
>
> - if (rootSectionBlock != null) {
> - if (rootSectionBlock == sectionBlock) {
> - rootSectionFound = true;
> - continue;
> - } else if (rootSectionBlock.getParent() ==
> sectionBlock.getParent() && sectionLevel <= rootSectionLevel) {
> - break;
> - }
> - } else {
> - rootSectionFound = true;
> - }
> + if (headerLevel >= start && headerLevel <= depth) {
> + ListItemBlock itemBlock =
> createTocEntry(headerBlock);
>
> - if (rootSectionFound && sectionLevel >= start &&
> sectionLevel <= depth) {
> - ListItemBlock itemBlock =
> createTocEntry(sectionBlock);
> + // Move to next header in toc tree
>
> - // Move to next section in toc tree
> -
> - while (currentLevel < sectionLevel) {
> + while (currentLevel < headerLevel) {
> currentBlock = createChildListBlock(numbered,
> currentBlock);
> ++currentLevel;
> }
> - while (currentLevel > sectionLevel) {
> + while (currentLevel > headerLevel) {
> currentBlock = currentBlock.getParent();
> --currentLevel;
> }
>
> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/
> xwiki-rendering-macro-toc/src/test/java/org/xwiki/rendering/
> RenderingTests.java
> ===================================================================
> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-
> rendering-macro-toc/src/test/java/org/xwiki/rendering/
> RenderingTests.java 2009-01-31 18:02:32 UTC (rev 15981)
> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-
> rendering-macro-toc/src/test/java/org/xwiki/rendering/
> RenderingTests.java 2009-01-31 18:22:16 UTC (rev 15982)
> @@ -37,12 +37,14 @@
> {
> RenderingTestSuite suite = new RenderingTestSuite("Test Toc
> Macro");
>
> - suite.addTestsFromResource("macrotoc1", true);
> + /*suite.addTestsFromResource("macrotoc1", true);
> suite.addTestsFromResource("macrotoc2", true);
> suite.addTestsFromResource("macrotoc3", true);
> suite.addTestsFromResource("macrotoc4", true);
> - suite.addTestsFromResource("macrotoc5", true);
> + suite.addTestsFromResource("macrotoc5", true);*/
>
> + suite.addTestsFromResource("macrotoc4", true);
> +
> return new RenderingPlexusTestSetup(suite);
> }
> }
On Jan 30, 2009, at 12:37 PM, fmancinelli (SVN) wrote:
> Author: fmancinelli
> Date: 2009-01-30 12:37:35 +0100 (Fri, 30 Jan 2009)
> New Revision: 15898
>
> Modified:
> enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/
> xwiki/xmlrpc/PagesTest.java
> Log:
> [Minor] Fixed a stability bug of the page history test.
>
> The problem was due to the fact that if pages are stored too fast,
> they will have the same timestamp in the modification list (the
> granularity is 1 sec.) and they will be returned in an arbitrary
> order (depending on the server side query result).
>
> This means that the modified page in the test, even if it's present
> in the modification list, could not be returned as the first item of
> that list, causing the assertion to fail.
>
> The solution was to wait 2 seconds before storing the page. This
> will guarantee that the timestamp will surely be different from any
> previous modification (and that the page will be on the top of the
> list if things work well)
>
> Modified: enterprise/trunk/distribution-test/xmlrpc-tests/src/test/
> it/org/xwiki/xmlrpc/PagesTest.java
> ===================================================================
> --- enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/
> xwiki/xmlrpc/PagesTest.java 2009-01-30 10:27:52 UTC (rev 15897)
> +++ enterprise/trunk/distribution-test/xmlrpc-tests/src/test/it/org/
> xwiki/xmlrpc/PagesTest.java 2009-01-30 11:37:35 UTC (rev 15898)
> @@ -663,13 +663,33 @@
>
> TestUtils.banner("TEST:
> getAllModifiedPageHistoryCorrectness()");
>
> + /*
> + * Wait 2 seconds before making the modification. This is
> necessary because if pages are stored in the same
> + * second, they will have the same timestamp and they could
> be returned in an arbitrary order making the
> + * following assert fail randomly
> + */
> + try {
> + Thread.sleep(2000);
> + } catch (InterruptedException e) {
> +
> + }
ouch this is bad... We need to find a better way IMO, like changing
the date and adding 1 second after it's stored or something but not
using timers.
-Vincent
>
> +
> XWikiPage page = this.rpc.getPage(pages.get(0).getId());
>
> + System.out.format("Modifying: %s\n", page);
> +
> page.setContent(String.format("Modified %d",
> System.currentTimeMillis()));
> page = rpc.storePage(page);
>
> - List<XWikiPageHistorySummary> modifications =
> rpc.getModifiedPagesHistory(1, 0);
> + System.out.format("Modified: %s\n", page);
>
> + List<XWikiPageHistorySummary> modifications =
> rpc.getModifiedPagesHistory(3, 0);
> +
> + System.out.format("Modifications:\n");
> + for (XWikiPageHistorySummary modification : modifications) {
> + System.out.format("%s\n", modification);
> + }
> +
> assertEquals(page.getId(),
> modifications.get(0).getBasePageId());
> assertEquals(page.getModified(),
> modifications.get(0).getModified());
> }
Hello devs,
We need a deprecation/compatibility strategy for our javascript APIs, as
we do have one for Java (see
http://lists.xwiki.org/pipermail/devs/2008-February/005067.html and
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackwar…).
I propose we embrace the same idea: keep backward compatibility separate
from actual code, creating a file "compatibility.js". Since it's a
compatibility layer, our releases should work properly without including
this file. We should discuss if we want include it by default or not.
As we are doing with the velocity uberspector, I propose we also log a
warning for every call to a deprecated JS API to help our users update
their code. For this I propose we have a depreciate method in
compatibility.js with the following signature :
function depreciate(scope, method, since, useInstead);
That method would weave the warning log before the actual call to the
method.
A typicall deprecation would then look like this, in compatibility.js :
window.checkAdvancedContent = XWiki.isAdvancedContent // keep compatbility
depreciate(window, checkAdvancedContent, "1.8M2",
"XWiki.isAdvancedContent"); // but log every call to checkAdvancedContent
As for Java APIs, I propose we keep compatibility at least 2 full
releases after the current version is released as final before we allow
ourselves to remove deprecated methods.
As for what should go through this deprecation cycle, I would say
everything that is now in xwiki.js. There are methods we publicly
advertise, for example updateName
(http://www.theserverside.com/tt/articles/article.tss?l=XWiki). For our
other files (usersandgroups.js, ajaxSuggest.js, fullscreenEdit.js, etc.)
I think we can refactor them without going through a deprecation cycle.
In any case, for the future we should be more careful and expose as APIs
only what we plan to support.
My +1 for this strategy
WDYT ?
Jerome
We need a deprecation strategy, i.e. decide for how long we keep
@deprecated methods/classes.
I propose to keep them for 2 full releases after the current version
is released as final.
For example if a method is deprecated in, say Core 1.3M2 then the
method will be removed in 1.6M1. Of course any major new release can
deprecate anything so a XWiki 2.0 is expected to break backward
compatibility.
So for methods deprecated in 1.0 we can remove them in 1.3M1, M2, etc.
WDYT?
If ok then I'll add this to our dev practice guide too.
Note that for this to be easy anyone deprecating methods should add
the information of when it was deprecated. For example:
/**
* @param time the time in milliseconds
* @return the time delta in milliseconds between the current
date and the time passed
* as parameter
* @deprecated replaced by {@link
com.xpn.xwiki.api.Util#getTimeDelta(long)} since 1.3M2
*/
public int XWiki.getTimeDelta(long time)
{
return this.util.getTimeDelta(time);
}
Here's my +1
Thanks
-Vincent
Thomas Mortagne (JIRA) wrote:
> [ http://jira.xwiki.org/jira/browse/XWIKI-2882?page=com.atlassian.jira.plugin… ]
>
> Thomas Mortagne edited comment on XWIKI-2882 at 1/28/09 3:40 PM:
> -----------------------------------------------------------------
>
> * this macro should not depends on radeox, expecially if it's just to use org.radeox.util.Encoder. You should directly generate the List<Block> and not generate a html string and call html macro to do it in RssMacro.renderSearch.
>
> * in RssMacro.renderEntries() you should use ParserUtils.parseInlineNonWiki to parse the description, WordBlock is supposed to contains only one work and not an entire paragraph.
>
> * never use wiki syntax in macros
> -- macro is supposed to not be syntax dependent
> -- a macro is supposed to work on XDOM level
> -- create directly the right block is way faster
> If the problem is that you can't pass List<Block> for the title to BoxMacroParameters, do it another way:
> -- you could define a protected List<Box> getTitle() methods in AbstractBoxMacro like you have getClassProperty() and extend it with a RSSEntryMacro class
> -- you could also add a set/getBlockTitle in BoxMacroParameters based on List<Block> which can be used from java (we could even imagine to be able to use it from wiki syntax with the tight BeanUtil converter)
> -- ...
Regarding the last issue, about whether to use or not wiki syntax for
rendering the title I must say I'm a bit puzzled. I thought that the
point of allowing wiki syntax to be specified in the title for the
boxMacro was right this, to properly render the titles of the rss
entries in the RssMacro.
................................
[15:42:26] Vincent Massol: now re the links I'm not sure yet
[15:42:37] … there are different ways of doing that I guess
[15:43:29] … one idea (brainstorming): we could allow inline wiki syntax
to be used the title parameter maybe
[15:44:14] Dan Miron: yes, it could be a way
[15:44:17] Thomas Mortagne: I like that yes
[15:46:45] Vincent Massol: hmm I wonder if this is something we'd want
for all macros
[15:47:09] … not sure
[15:47:17] Thomas Mortagne: at wors we can add a isTitleWiki
[15:47:19] Vincent Massol: even for this use case I'm stil not fully sure
[15:47:51] … it sounds good but I wonder if we'd get side effects
[15:48:09] … actually we wan't do that in a generic way for all macros
[15:48:20] … since it's not going to generate text
[15:48:25] … but Blocks
[15:48:32] … so the macro needs to handle that
[15:48:50] … s/Wan't/can't/
[15:49:33] … ok I think I'm +1 for making the image and title params
allow inline wiki syntax here for this macro
[15:49:45] … (it's a good experiment, we'll see how it goes)
[15:49:49] … wdyt?
[15:49:53] Thomas Mortagne: +1
[15:50:03] Jean-Vincent Drean: +1
..................................
Anyway, if we need to quit using wiki syntax in the title, i'd prefer
the second choice, "add a set/getBlockTitle in BoxMacroParameters based
on List<Block> which can be used from java". Should I go on with this?
Tnx,
Dan
I've made quite a few improvements to the original TodoApplication, and
was told to send it here for review. First, here's a list of introduced
features:
* extended Todo class
* revamped class sheet/template
* revamped webhome (many improvements)
* ability to add todo's right from side-panel
* ability to show completeness percentage
* more..
The naming was suggested by 'jvelociter' (on irc) due to the fact that
the TodoApplication is used for a tutorial and must be kept simple..
suggestions are welcome, I've tinkered with the todo panel to make it
more compatible with toucan and albatross based skins just before i sent
this to you, so tell me if you have any takes (i.e. if it looks ugly)..
On Jan 28, 2009, at 6:28 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2009-01-28 06:28:25 +0100 (Wed, 28 Jan 2009)
> New Revision: 15808
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
> Document.java
> Log:
> XWIKI-3168: Changing the document syntax without saving the document
> can cause an invalid document state
> Fixed.
>
>
> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> api/Document.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
> Document.java 2009-01-27 23:34:55 UTC (rev 15807)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
> Document.java 2009-01-28 05:28:25 UTC (rev 15808)
> @@ -273,6 +273,15 @@
> }
>
> /**
> + * @return the Syntax id representing the syntax used for the
> current document. For example "xwiki/1.0" represents
> + * the first version XWiki syntax while "xwiki/2.0"
> represents version 2.0 of the XWiki Syntax.
> + */
> + public String getSyntaxId()
> + {
> + return this.doc.getSyntaxId();
should this be getDoc().getSyntaxId()?
Should all methods use getDoc() instead of this.doc?
> + }
> +
> + /**
> * return the language of the document if it's a traduction,
> otherwise, it return default
> */
> public String getLanguage()
> @@ -1498,6 +1507,10 @@
> getDoc().setContent(content);
> }
>
> + /**
> + * @param syntaxId the Syntax id representing the syntax used
> for the current document. For example "xwiki/1.0" represents
> + * the first version XWiki syntax while "xwiki/2.0"
> represents version 2.0 of the XWiki Syntax.
> + */
> public void setSyntaxId(String syntaxId)
> {
> getDoc().setSyntaxId(syntaxId);
> @@ -1900,15 +1913,6 @@
> }
>
> /**
> - * @return the Syntax id representing the syntax used for the
> current document. For example "xwiki/1.0" represents
> - * the first version XWiki syntax while "xwiki/2.0"
> represents version 2.0 of the XWiki Syntax.
> - */
> - public String getSyntaxId()
> - {
> - return this.doc.getSyntaxId();
> - }
> -
> - /**
> * Convert the current document content from its current syntax
> to the new syntax passed as parameter.
> *
> * @param targetSyntaxId the syntax to convert to (eg "xwiki/
> 2.0", "xhtml/1.0", etc)
> @@ -1917,7 +1921,7 @@
> public boolean convertSyntax(String targetSyntaxId) throws
> XWikiException
> {
> try {
> - this.doc.convertSyntax(targetSyntaxId);
> + getDoc().convertSyntax(targetSyntaxId);
> } catch (Exception ex) {
> return false;
> }
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net