- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] possible small problem with import/export & virtual wiki & copy doc after import

by Pascal Voitot

Hello, I use virtual wikis and I have created a XAR by exporting from one wiki and then importing the XAR into another wiki. Then I choose a doc in the new wiki and I just want to copy it into another document in the same wiki and it gives "Successfully copied" but when I access the new doc, it says "your doc doesn't exist" and it is really empty... No error anywhere... After comparing with other documents I could copy without any problem, I discovered that my doc has a parent such as "oldwiki:MySpace.MyParentDoc" instead of "newwiki:MySpace.MyParentDoc". (I didn't set the parent using virtual wikis explicitely, it was created by the wiki like that) So apparently, the export keeps the parent name with wiki relationship. As the export is just a raw serialization of the document structure, it is not really surprising. And the copy function fails to copy the document without any error. regards Pascal

16 years, 2 months

1
0
0 0

[xwiki-devs] groovy console question...

by Pascal Voitot

Hello, maybe I'm a bit stupid but I tried using the Groovy Console app it works perfectly but it requires loading/saving scripts into XWiki.ConsoleScriptClass. But where is this class because I can't find it? Moreover, when a script is stored in one object of this class, how to use it? Is there a kind of extension such as jsx or ssx? regards Pascal

16 years, 2 months

1
0
0 0

[xwiki-devs] velocity error in xwiki.org

by Pascal Voitot

http://www.xwiki.org/xwiki/bin/view/Main/ProductDocumentation gives velocity error... Pascal

16 years, 2 months

2
1
0 0

Re: [xwiki-devs] [Proposal] Unification of input/output syntaxes (was Re: [xwiki-notifications] r21811 - in platform: core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc core/trunk/xwiki-core/sr

by Thomas Mortagne

On Sat, Jul 11, 2009 at 10:09, Vincent Massol<vincent(a)massol.net> wrote: > Summarizing (I've now understood): > - We have input syntaxes (parser syntaxes) and output syntaxes > (renderer syntaxes) > > Proposal > ======= > > a- we rename SyntaxFactory.getAvailableSyntaxes() in > getAvailableInputSyntaxes() (or getAvailableParserSyntaxes()) +1 , since it's in rendering module we should always use same vocabulary so +1 for getAvailableParserSyntaxes > b- we add SyntaFactory.getAvailableOutputSyntaxes() (or > getAvailableRendererSyntaxes()) +1 for getAvailableRendererSyntaxes > c- (optional) we add a Renderer.getSyntax() interface method (for > later use when renderers will be components) let's wait for when we will make renderers componenents since it depends on how we do that exactly > d- we rename Document/XWikiDocument/XWiki methods for getting syntaxes > to use Input/Ouput (or Parser/Renderer) in their names. +1 > > Note that b) means that we'll hardcode the list of available renderer > syntaxes but that's ok for now (this is hat is currently done in > PrintRendererFactory). This will be made dynamic when Renderer are > made components. The advantage of putting this in PrintRendererFactory is that you have less chance to forget to update the list when you add a new renderer but i doubt we will add one before making renderers real components actually so i guess it ok. > > WDYT? > > Thanks > -Vincent > > On Jul 10, 2009, at 6:49 PM, Thomas Mortagne wrote: > >> On Fri, Jul 10, 2009 at 09:41, Vincent Massol<vincent(a)massol.net> >> wrote: >>> >>> On Jul 4, 2009, at 2:44 PM, tmortagne (SVN) wrote: >>> >>>> Author: tmortagne >>>> Date: 2009-07-04 14:44:30 +0200 (Sat, 04 Jul 2009) >>>> New Revision: 21811 >>>> >>>> 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/ >>>> XWiki.java >>>> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ >>>> XWikiDocument.java >>>> platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/api/ >>>> XWikiTest.java >>>> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml >>>> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >>>> java/org/xwiki/rendering/internal/renderer/ >>>> DefaultPrintRendererFactory.java >>>> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >>>> java/org/xwiki/rendering/parser/Syntax.java >>>> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >>>> java/org/xwiki/rendering/parser/SyntaxType.java >>>> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >>>> java/org/xwiki/rendering/renderer/PrintRendererFactory.java >>>> platform/web/trunk/standard/src/main/webapp/templates/ >>>> contentview.vm >>>> platform/web/trunk/standard/src/main/webapp/templates/plain.vm >>>> Log: >>>> XWIKI-4042: Add a way to choose the renderer when viewing a page >>> >>>> >>>> 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-07-04 12:42:14 UTC (rev 21810) >>>> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ >>>> Document.java 2009-07-04 12:44:30 UTC (rev 21811) >>>> @@ -37,6 +37,7 @@ >>>> import org.suigeneris.jrcs.diff.DifferentiationFailedException; >>>> import org.suigeneris.jrcs.diff.delta.Delta; >>>> import org.suigeneris.jrcs.rcs.Version; >>>> +import org.xwiki.rendering.parser.Syntax; >>>> >>>> import com.xpn.xwiki.XWiki; >>>> import com.xpn.xwiki.XWikiContext; >>>> @@ -473,6 +474,16 @@ >>>> } >>>> >>>> /** >>>> + * @param targetSyntax the syntax in which render the document >>>> content >>>> + * @return the rendered content >>>> + * @throws XWikiException error when rendering content >>>> + */ >>>> + public String getRenderedContent(Syntax targetSyntax) throws >>>> XWikiException >>>> + { >>>> + return this.doc.getRenderedContent(targetSyntax, >>>> getXWikiContext()); >>>> + } >>> >>> Since this is for Velocity, isn't it better to use a syntax Id String >>> instead of a Syntax object which is hard to construct from velocity? >> >> The problem is that it was not easy to find a right signature since >> there is already getRenderedContent taking string fo the parser >> syntax. Since anyway it's necessary to give a supported syntax by >> looking at existing one it was easier to not have to directly give the >> found valid syntax object. >> >>> >>>> + >>>> + /** >>>> * return a escaped version of the content of this document >>>> */ >>>> public String getEscapedContent() throws XWikiException >>>> >>>> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/ >>>> xwiki/ >>>> api/XWiki.java >>>> =================================================================== >>>> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ >>>> XWiki.java 2009-07-04 12:42:14 UTC (rev 21810) >>>> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ >>>> XWiki.java 2009-07-04 12:44:30 UTC (rev 21811) >>>> @@ -30,6 +30,8 @@ >>>> import org.apache.commons.logging.LogFactory; >>>> import org.suigeneris.jrcs.diff.delta.Chunk; >>>> import org.xwiki.query.QueryManager; >>>> +import org.xwiki.rendering.parser.Syntax; >>>> +import org.xwiki.rendering.renderer.PrintRendererFactory; >>>> >>>> import com.xpn.xwiki.XWikiContext; >>>> import com.xpn.xwiki.XWikiException; >>>> @@ -2685,4 +2687,42 @@ >>>> { >>>> return this.xwiki.getDefaultDocumentSyntax(); >>>> } >>>> + >>>> + /** >>>> + * Find the corresponding available renderer syntax. >>>> + * <p> >>>> + * If <code>syntaxVersion</code> is null the last version of >>>> the available provided syntax type is returned. >>>> + * >>>> + * @param syntaxType the syntax type >>>> + * @param syntaxVersion the syntax version >>>> + * @return the available corresponding {@link Syntax}. Null if >>>> no available renderer can be found. >>>> + */ >>>> + public Syntax getAvailableRendererSyntax(String syntaxType, >>>> String syntaxVersion) >>>> + { >>>> + Syntax syntax = null; >>>> + >>>> + PrintRendererFactory printRendererFactory = >>>> + (PrintRendererFactory) >>>> Utils.getComponent(PrintRendererFactory.class); >>>> + >>>> + List<Syntax> availableSyntaxes = >>>> printRendererFactory.getAvailableSyntaxes(); >>> >>> We already have the notion of available syntaxes in the >>> SyntaxFactory. >> >> No, we have the notion of available parsers, the method name is just >> wrong in SyntaxFactory... The only place where we know the available >> renderers is the PrintRendererFactory since it's impossible to get all >> renderers otherwise until renderer are made components. >> >>> I don't understand why we need to have them in the >>> PrintRendererFactory (which is not supposed to return syntaxes BTW, >>> it's only supposed to return PrintRenderer(s). >>> >>>> + >>>> + for (Syntax availableSyntax : availableSyntaxes) { >>> >>> Why not instead do: >>> SyntaxType syntaxType = SyntaxType.getSyntaxType(syntaxTypeAsString); >>> >>> And then (when syntaxVersion != null): >>> Syntax syntax = new Syntax(syntaxType, syntaxVersion); >>> >>> And then: >>> syntaxFatory.getAvailableSyntaxes().contains(syntax) >> >> It's not that simple since we have to support the use case where >> syntaxVersion is not given (which is most of the time). >> >>> >>> hmmm.... Actually thinking more about it, I believe this whole code >>> should be moved out of XWikiDocument and instead go in the rendering >>> module in SyntaxFactory. >> >> Again in SyntaxFactory you have no idea what are the available >> renderers syntaxes and here we don't care about parsers. >> Until we have clean renderer componet my goal was to put as less as >> possible temporary code in rendering module. >> >>> >>>> + if (syntaxVersion != null) { >>>> + if >>>> (availableSyntax.getType().toIdString().equalsIgnoreCase(syntaxType) >>>> + && >>>> availableSyntax.getVersion().equals(syntaxVersion)) { >>>> + syntax = availableSyntax; >>>> + break; >>>> + } >>>> + } else { >>>> + // TODO: improve version comparaison since it does >>>> not work when comparing 2.0 and 10.0 for example. We >>>> + // should have a Version which implements >>>> Comparable like we have SyntaxId in Syntax >>>> + if >>>> (availableSyntax.getType().toIdString().equalsIgnoreCase(syntaxType) >>>> + && (syntax == null || >>>> availableSyntax.getVersion().compareTo(syntax.getVersion()) > 0)) { >>>> + syntax = availableSyntax; >>>> + } >>>> + } >>>> + } >>>> + >>>> + return syntax; >>>> + } >>>> } >>> >>> [snip] >>>> >>>> /** >>>> + * @return the syntax of the document >>>> + */ >>>> + private Syntax getSyntax() >>>> + { >>>> + Syntax syntax = null; >>>> + >>>> + String syntaxId = getDefaultDocumentSyntax(); >>>> + try { >>>> + syntax = >>>> this.syntaxFactory.createSyntaxFromIdString(getSyntaxId()); >>> >>> Shouldn't we save the Syntax object instead of syntaxId in >>> XWikiDocument so that we don't perform the conversion every time >>> getSyntax is called? >> >> I did not planed to refactor the whole XWikiDocument, i just done what >> was needed but at some point yes we should have Syntax and XDOM >> instead of the syntax/content strings :) >> >>> >>>> + } catch (ParseException e) { >>>> + LOG.error("Failed to genrate Syntax object for syntax >>>> identifier [" + syntaxId + "] in page [" >>> >>> Typo: generate >>> >>>> + + getDocumentName() + "]", e); >>>> + >>>> + syntaxId = getDefaultDocumentSyntax(); >>> >>> I don't understand this line above, it's the same as the one a few >>> lines above. >>> >>>> + try { >>>> + syntax = >>>> this >>>> .syntaxFactory.createSyntaxFromIdString(getDefaultDocumentSyntax()); >>> >>> It seems you're not using the syntaxId variable. >> >> Yes it's an error, I added the variables when added the error message >> and forgot to change the "real" code properly. >> >>> >>>> + } catch (ParseException e1) { >>>> + LOG.error("Failed to genrate default Syntax object. >>>> The defautlt syntax id in [" + syntaxId + "]", e); >>> >>> same typo >>> >>> [snip] >>> >>>> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/ >>>> pom.xml >>>> =================================================================== >>>> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml >>>> 2009-07-04 12:42:14 UTC (rev 21810) >>>> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml >>>> 2009-07-04 12:44:30 UTC (rev 21811) >>>> @@ -187,7 +187,9 @@ >>>>  >>>> <exclude>org/xwiki/rendering/macro/MacroManager</ >>>> exclude> >>>> <exclude>org/xwiki/rendering/macro/MacroSource</ >>>> exclude> >>>> - <exclude>org/xwiki/rendering/macro/ >>>> AbstractMacroSource</exclude> >>>> + <exclude>org/xwiki/rendering/macro/ >>>> AbstractMacroSource</exclude> >>>> +  >>> >>> It doesn't normally (it' considered as an INFO level) unless it >>> breaks >>> binary compatibility. But I don't know why in your case (would need >>> to >>> check more the code, i'm only looking at the svn diff). >> >> If you remove this the plugin clearly say that there is an error and >> it also clearly say that the error is that there is new api in >> PrintRendererFactory. Maybe the error message is wrong but i check and >> rechecked and this is the only difference. >> >>> >>>> + <exclude>org/xwiki/rendering/renderer/ >>>> PrintRendererFactory</exclude> >>>> </excludes> >>>> </configuration> >>>> </execution> >>>> >>>> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/ >>>> src/main/java/org/xwiki/rendering/internal/renderer/ >>>> DefaultPrintRendererFactory.java >>>> =================================================================== >>>> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/ >>>> main/ >>>> java/org/xwiki/rendering/internal/renderer/ >>>> DefaultPrintRendererFactory.java 2009-07-04 12:42:14 UTC (rev >>>> 21810) >>>> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/ >>>> main/ >>>> java/org/xwiki/rendering/internal/renderer/ >>>> DefaultPrintRendererFactory.java 2009-07-04 12:44:30 UTC (rev >>>> 21811) >>>> @@ -19,6 +19,10 @@ >>>> */ >>>> package org.xwiki.rendering.internal.renderer; >>>> >>>> +import java.util.Arrays; >>>> +import java.util.Collections; >>>> +import java.util.List; >>>> + >>>> import org.xwiki.component.annotation.Component; >>>> import org.xwiki.component.annotation.Requirement; >>>> import org.xwiki.rendering.parser.Syntax; >>>> @@ -43,6 +47,10 @@ >>>> @Component >>>> public class DefaultPrintRendererFactory implements >>>> PrintRendererFactory >>>> { >>>> + private static final List<Syntax> AVAILABLE_SYNTAXES = >>>> + >>>> Collections.unmodifiableList(Arrays.asList(Syntax.XHTML_1_0, >>>> Syntax.XWIKI_2_0, Syntax.EVENT_1_0, >>>> + Syntax.TEX_1_0, Syntax.PLAIN_1_0)); >>> >>> I don't like this, see above. >> >> Again it's a factory, it's the only place where we really now what are >> the renderers. I don't like this either but since renderer are not >> component there is no choice. >> >>> >>>> + >>>> /** >>>> * Factory to easily create an XHTML Image and Link Renderers. >>>> */ >>>> @@ -55,6 +63,16 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @see >>>> org >>>> .xwiki >>>> .rendering.renderer.PrintRendererFactory#getAvailableSyntaxes() >>>> + */ >>>> + public List<Syntax> getAvailableSyntaxes() >>>> + { >>>> + return AVAILABLE_SYNTAXES; >>>> + } >>>> + >>> >>> I don't like this, see above. >>> >>> [snip] >>> >>> Thanks >>> -Vincent >>> >>> _______________________________________________ >>> devs mailing list >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

16 years, 2 months

1
0
0 0

[xwiki-devs] serialVersionUID (was Re: [xwiki-notifications] r21863 - platform/xwiki-plugins/trunk/wiki-manager/src/main/java/com/xpn/xwiki/plugin/wikimanager)

by Vincent Massol

On Jul 9, 2009, at 12:15 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-07-09 12:15:53 +0200 (Thu, 09 Jul 2009) > New Revision: 21863 > > Modified: > platform/xwiki-plugins/trunk/wiki-manager/src/main/java/com/xpn/ > xwiki/plugin/wikimanager/WikiManagerException.java > Log: > [misc] Add serialize id > > Modified: platform/xwiki-plugins/trunk/wiki-manager/src/main/java/ > com/xpn/xwiki/plugin/wikimanager/WikiManagerException.java > =================================================================== > --- platform/xwiki-plugins/trunk/wiki-manager/src/main/java/com/xpn/ > xwiki/plugin/wikimanager/WikiManagerException.java 2009-07-09 > 09:56:02 UTC (rev 21862) > +++ platform/xwiki-plugins/trunk/wiki-manager/src/main/java/com/xpn/ > xwiki/plugin/wikimanager/WikiManagerException.java 2009-07-09 > 10:15:53 UTC (rev 21863) > @@ -30,11 +30,6 @@ > public class WikiManagerException extends PluginException > { > /** > - * Serialize id. > - */ > - private static final long serialVersionUID = > -6451750749104331619L; > - > - /** > * Error when trying to use provided user that does not exists. > * <p> > * TODO : move in XWikiException > @@ -98,6 +93,11 @@ > // ////// > > /** > + * Serialize id. > + */ > + private static final long serialVersionUID = > -6451750749104331619L; > + I've asked myself several times how to document this. I've used different versions: - "Unique ID for Class Serialization." - "Class id for Serialization." and the more descriptive: /** * Needed to identify the version of this code when serializing/ deserializing (since Exception is Serializable). * Note that the value needs to be modified whenever a non transient field is added or removed in this class. */ The last one is the one I prefer (I think) since not everyone knows about this and it makes it clear that the id needs to be modified whenever a new field is added/removed. We could also add a link to some URL describing class serialization. WDYT? Thanks -Vincent

16 years, 2 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r21811 - in platform: core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/api core/trunk/xwiki-rendering/

by Thomas Mortagne

On Fri, Jul 10, 2009 at 09:41, Vincent Massol<vincent(a)massol.net> wrote: > > On Jul 4, 2009, at 2:44 PM, tmortagne (SVN) wrote: > >> Author: tmortagne >> Date: 2009-07-04 14:44:30 +0200 (Sat, 04 Jul 2009) >> New Revision: 21811 >> >> 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/ >> XWiki.java >> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ >> XWikiDocument.java >> platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/api/ >> XWikiTest.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/ >> DefaultPrintRendererFactory.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/parser/Syntax.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/parser/SyntaxType.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/renderer/PrintRendererFactory.java >> platform/web/trunk/standard/src/main/webapp/templates/contentview.vm >> platform/web/trunk/standard/src/main/webapp/templates/plain.vm >> Log: >> XWIKI-4042: Add a way to choose the renderer when viewing a page > >> >> 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-07-04 12:42:14 UTC (rev 21810) >> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ >> Document.java 2009-07-04 12:44:30 UTC (rev 21811) >> @@ -37,6 +37,7 @@ >> import org.suigeneris.jrcs.diff.DifferentiationFailedException; >> import org.suigeneris.jrcs.diff.delta.Delta; >> import org.suigeneris.jrcs.rcs.Version; >> +import org.xwiki.rendering.parser.Syntax; >> >> import com.xpn.xwiki.XWiki; >> import com.xpn.xwiki.XWikiContext; >> @@ -473,6 +474,16 @@ >> } >> >> /** >> + * @param targetSyntax the syntax in which render the document >> content >> + * @return the rendered content >> + * @throws XWikiException error when rendering content >> + */ >> + public String getRenderedContent(Syntax targetSyntax) throws >> XWikiException >> + { >> + return this.doc.getRenderedContent(targetSyntax, >> getXWikiContext()); >> + } > > Since this is for Velocity, isn't it better to use a syntax Id String > instead of a Syntax object which is hard to construct from velocity? The problem is that it was not easy to find a right signature since there is already getRenderedContent taking string fo the parser syntax. Since anyway it's necessary to give a supported syntax by looking at existing one it was easier to not have to directly give the found valid syntax object. > >> + >> + /** >> * return a escaped version of the content of this document >> */ >> public String getEscapedContent() throws XWikiException >> >> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ >> api/XWiki.java >> =================================================================== >> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ >> XWiki.java 2009-07-04 12:42:14 UTC (rev 21810) >> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ >> XWiki.java 2009-07-04 12:44:30 UTC (rev 21811) >> @@ -30,6 +30,8 @@ >> import org.apache.commons.logging.LogFactory; >> import org.suigeneris.jrcs.diff.delta.Chunk; >> import org.xwiki.query.QueryManager; >> +import org.xwiki.rendering.parser.Syntax; >> +import org.xwiki.rendering.renderer.PrintRendererFactory; >> >> import com.xpn.xwiki.XWikiContext; >> import com.xpn.xwiki.XWikiException; >> @@ -2685,4 +2687,42 @@ >> { >> return this.xwiki.getDefaultDocumentSyntax(); >> } >> + >> + /** >> + * Find the corresponding available renderer syntax. >> + * <p> >> + * If <code>syntaxVersion</code> is null the last version of >> the available provided syntax type is returned. >> + * >> + * @param syntaxType the syntax type >> + * @param syntaxVersion the syntax version >> + * @return the available corresponding {@link Syntax}. Null if >> no available renderer can be found. >> + */ >> + public Syntax getAvailableRendererSyntax(String syntaxType, >> String syntaxVersion) >> + { >> + Syntax syntax = null; >> + >> + PrintRendererFactory printRendererFactory = >> + (PrintRendererFactory) >> Utils.getComponent(PrintRendererFactory.class); >> + >> + List<Syntax> availableSyntaxes = >> printRendererFactory.getAvailableSyntaxes(); > > We already have the notion of available syntaxes in the SyntaxFactory. No, we have the notion of available parsers, the method name is just wrong in SyntaxFactory... The only place where we know the available renderers is the PrintRendererFactory since it's impossible to get all renderers otherwise until renderer are made components. > I don't understand why we need to have them in the > PrintRendererFactory (which is not supposed to return syntaxes BTW, > it's only supposed to return PrintRenderer(s). > >> + >> + for (Syntax availableSyntax : availableSyntaxes) { > > Why not instead do: > SyntaxType syntaxType = SyntaxType.getSyntaxType(syntaxTypeAsString); > > And then (when syntaxVersion != null): > Syntax syntax = new Syntax(syntaxType, syntaxVersion); > > And then: > syntaxFatory.getAvailableSyntaxes().contains(syntax) It's not that simple since we have to support the use case where syntaxVersion is not given (which is most of the time). > > hmmm.... Actually thinking more about it, I believe this whole code > should be moved out of XWikiDocument and instead go in the rendering > module in SyntaxFactory. Again in SyntaxFactory you have no idea what are the available renderers syntaxes and here we don't care about parsers. Until we have clean renderer componet my goal was to put as less as possible temporary code in rendering module. > >> + if (syntaxVersion != null) { >> + if >> (availableSyntax.getType().toIdString().equalsIgnoreCase(syntaxType) >> + && >> availableSyntax.getVersion().equals(syntaxVersion)) { >> + syntax = availableSyntax; >> + break; >> + } >> + } else { >> + // TODO: improve version comparaison since it does >> not work when comparing 2.0 and 10.0 for example. We >> + // should have a Version which implements >> Comparable like we have SyntaxId in Syntax >> + if >> (availableSyntax.getType().toIdString().equalsIgnoreCase(syntaxType) >> + && (syntax == null || >> availableSyntax.getVersion().compareTo(syntax.getVersion()) > 0)) { >> + syntax = availableSyntax; >> + } >> + } >> + } >> + >> + return syntax; >> + } >> } > > [snip] >> >> /** >> + * @return the syntax of the document >> + */ >> + private Syntax getSyntax() >> + { >> + Syntax syntax = null; >> + >> + String syntaxId = getDefaultDocumentSyntax(); >> + try { >> + syntax = >> this.syntaxFactory.createSyntaxFromIdString(getSyntaxId()); > > Shouldn't we save the Syntax object instead of syntaxId in > XWikiDocument so that we don't perform the conversion every time > getSyntax is called? I did not planed to refactor the whole XWikiDocument, i just done what was needed but at some point yes we should have Syntax and XDOM instead of the syntax/content strings :) > >> + } catch (ParseException e) { >> + LOG.error("Failed to genrate Syntax object for syntax >> identifier [" + syntaxId + "] in page [" > > Typo: generate > >> + + getDocumentName() + "]", e); >> + >> + syntaxId = getDefaultDocumentSyntax(); > > I don't understand this line above, it's the same as the one a few > lines above. > >> + try { >> + syntax = >> this >> .syntaxFactory.createSyntaxFromIdString(getDefaultDocumentSyntax()); > > It seems you're not using the syntaxId variable. Yes it's an error, I added the variables when added the error message and forgot to change the "real" code properly. > >> + } catch (ParseException e1) { >> + LOG.error("Failed to genrate default Syntax object. >> The defautlt syntax id in [" + syntaxId + "]", e); > > same typo > > [snip] > >> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/ >> pom.xml >> =================================================================== >> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml >> 2009-07-04 12:42:14 UTC (rev 21810) >> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml >> 2009-07-04 12:44:30 UTC (rev 21811) >> @@ -187,7 +187,9 @@ >>  >> <exclude>org/xwiki/rendering/macro/MacroManager</ >> exclude> >> <exclude>org/xwiki/rendering/macro/MacroSource</ >> exclude> >> - <exclude>org/xwiki/rendering/macro/ >> AbstractMacroSource</exclude> >> + <exclude>org/xwiki/rendering/macro/ >> AbstractMacroSource</exclude> >> +  > > It doesn't normally (it' considered as an INFO level) unless it breaks > binary compatibility. But I don't know why in your case (would need to > check more the code, i'm only looking at the svn diff). If you remove this the plugin clearly say that there is an error and it also clearly say that the error is that there is new api in PrintRendererFactory. Maybe the error message is wrong but i check and rechecked and this is the only difference. > >> + <exclude>org/xwiki/rendering/renderer/ >> PrintRendererFactory</exclude> >> </excludes> >> </configuration> >> </execution> >> >> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/ >> src/main/java/org/xwiki/rendering/internal/renderer/ >> DefaultPrintRendererFactory.java >> =================================================================== >> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/ >> DefaultPrintRendererFactory.java 2009-07-04 12:42:14 UTC (rev 21810) >> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/ >> DefaultPrintRendererFactory.java 2009-07-04 12:44:30 UTC (rev 21811) >> @@ -19,6 +19,10 @@ >> */ >> package org.xwiki.rendering.internal.renderer; >> >> +import java.util.Arrays; >> +import java.util.Collections; >> +import java.util.List; >> + >> import org.xwiki.component.annotation.Component; >> import org.xwiki.component.annotation.Requirement; >> import org.xwiki.rendering.parser.Syntax; >> @@ -43,6 +47,10 @@ >> @Component >> public class DefaultPrintRendererFactory implements >> PrintRendererFactory >> { >> + private static final List<Syntax> AVAILABLE_SYNTAXES = >> + >> Collections.unmodifiableList(Arrays.asList(Syntax.XHTML_1_0, >> Syntax.XWIKI_2_0, Syntax.EVENT_1_0, >> + Syntax.TEX_1_0, Syntax.PLAIN_1_0)); > > I don't like this, see above. Again it's a factory, it's the only place where we really now what are the renderers. I don't like this either but since renderer are not component there is no choice. > >> + >> /** >> * Factory to easily create an XHTML Image and Link Renderers. >> */ >> @@ -55,6 +63,16 @@ >> /** >> * {@inheritDoc} >> * >> + * @see >> org >> .xwiki.rendering.renderer.PrintRendererFactory#getAvailableSyntaxes() >> + */ >> + public List<Syntax> getAvailableSyntaxes() >> + { >> + return AVAILABLE_SYNTAXES; >> + } >> + > > I don't like this, see above. > > [snip] > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

16 years, 2 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r21856 - in platform/core/trunk: xwiki-core/src/test/java/com/xpn/xwiki/doc xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/block

by Vincent Massol

On Jul 8, 2009, at 7:17 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-07-08 19:17:52 +0200 (Wed, 08 Jul 2009) > New Revision: 21856 > > Modified: > platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/ > XWikiDocumentTest.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/block/AbstractBlock.java > Log: > XWIKI-4071: Error on save after removing all content from a document > section > > Modified: platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/ > doc/XWikiDocumentTest.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/ > XWikiDocumentTest.java 2009-07-08 14:25:48 UTC (rev 21855) > +++ platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/ > XWikiDocumentTest.java 2009-07-08 17:17:52 UTC (rev 21856) > @@ -504,6 +504,7 @@ > + "== header 2==\nheader 2 content"); > this.document.setSyntaxId("xwiki/2.0"); > > + // Modify section content > String content1 = this.document.updateDocumentSection(2, "== > header 2==\nmodified header 2 content"); > > assertEquals( > @@ -517,6 +518,11 @@ > assertEquals( > "content not in section\n\n= header 1 =\n\nmodified also > header 1 content\n\n== header 2 ==\n\nheader 2 content", > content2); > + > + // Remove a section > + String content3 = this.document.updateDocumentSection(2, ""); > + > + assertEquals("content not in section\n\n= header 1 =\n > \nheader 1 content", content3); > } > > public void testDisplay10() > > 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-07-08 > 14:25:48 UTC (rev 21855) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/block/AbstractBlock.java 2009-07-08 > 17:17:52 UTC (rev 21856) > @@ -150,7 +150,7 @@ > block.setParent(this); > } > blocks.addAll(pos, newBlocks); > - blocks.remove(pos + 1); > + blocks.remove(pos + newBlocks.size()); Are we missing a unit test in BlockTest for this? Thanks -Vincent

16 years, 2 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r21818 - platform/xwiki-plugins/trunk/tag/src/main/java/com/xpn/xwiki/plugin/tag

by Vincent Massol

I like this. Shouldn't we also remove the automatic creation of Tag objects in all documents by default? I have never understood why we do this for Tags and not for Rights, and all other objects. For me the objects should be created only when required and not by default. Thanks -Vincent On Jul 4, 2009, at 5:22 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-07-04 17:22:41 +0200 (Sat, 04 Jul 2009) > New Revision: 21818 > > Modified: > platform/xwiki-plugins/trunk/tag/src/main/java/com/xpn/xwiki/ > plugin/tag/TagPlugin.java > Log: > XATAG-20: Adding tags fails when there is no Tag object attached to > the document > Fixed. > > Modified: platform/xwiki-plugins/trunk/tag/src/main/java/com/xpn/ > xwiki/plugin/tag/TagPlugin.java > =================================================================== > --- platform/xwiki-plugins/trunk/tag/src/main/java/com/xpn/xwiki/ > plugin/tag/TagPlugin.java 2009-07-04 15:22:34 UTC (rev 21817) > +++ platform/xwiki-plugins/trunk/tag/src/main/java/com/xpn/xwiki/ > plugin/tag/TagPlugin.java 2009-07-04 15:22:41 UTC (rev 21818) > @@ -29,12 +29,18 @@ > > import org.apache.commons.collections.CollectionUtils; > import org.apache.commons.lang.StringUtils; > +import org.apache.commons.logging.Log; > +import org.apache.commons.logging.LogFactory; > > import com.xpn.xwiki.XWikiContext; > import com.xpn.xwiki.XWikiException; > import com.xpn.xwiki.api.Api; > import com.xpn.xwiki.doc.XWikiDocument; > +import com.xpn.xwiki.objects.BaseObject; > import com.xpn.xwiki.objects.BaseProperty; > +import com.xpn.xwiki.objects.DBStringListProperty; > +import com.xpn.xwiki.objects.classes.BaseClass; > +import com.xpn.xwiki.objects.classes.PropertyClass; > import com.xpn.xwiki.plugin.XWikiDefaultPlugin; > import com.xpn.xwiki.plugin.XWikiPluginInterface; > > @@ -45,6 +51,9 @@ > */ > public class TagPlugin extends XWikiDefaultPlugin implements > XWikiPluginInterface > { > + /** Logging helper object. */ > + public static final Log LOG = LogFactory.getLog(TagPlugin.class); > + > /** > * The identifier for this plugin; used for accessing the plugin > from velocity, and as the action returning the > * extension content. > @@ -116,10 +125,40 @@ > private void setDocumentTags(XWikiDocument document, > List<String> tags, XWikiContext context) > { > BaseProperty prop = (BaseProperty) > document.getObject(TAG_CLASS, true, context).safeget(TAG_PROPERTY); > + // Properties aren't added to an object unless a value is > specified either from the Web or from an XML. > + if (prop == null) { > + prop = createTagProperty(document.getObject(TAG_CLASS, > true, context), context); > + } > prop.setValue(tags); > } > > /** > + * Create and add the main tag property to the provided tag > object. The new property corresponds to the definition > + * in the tag class, but in case of an error, the default type > is a relational-stored list. > + * > + * @param tagObject the target tag object > + * @param context the current request context > + * @return the created property > + * @see #TAG_PROPERTY > + */ > + private BaseProperty createTagProperty(BaseObject tagObject, > XWikiContext context) > + { > + BaseProperty tagProperty; > + try { > + BaseClass tagClass = > context.getWiki().getClass(TAG_CLASS, context); > + PropertyClass tagPropertyDefinition = (PropertyClass) > tagClass.getField(TAG_PROPERTY); > + tagProperty = tagPropertyDefinition.newProperty(); > + } catch (XWikiException ex) { > + LOG.warn("Failed to properly create tag property for > the tag object, creating a default one"); > + tagProperty = new DBStringListProperty(); > + } > + tagProperty.setName(TAG_PROPERTY); > + tagProperty.setObject(tagObject); > + tagObject.safeput(TAG_PROPERTY, tagProperty); > + return tagProperty; > + } > + > + /** > * Get all tags within the wiki. > * > * @param context XWiki context. > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

16 years, 2 months

3
2
0 0

[xwiki-devs] EventListener

by glenn_engel＠agilent.com

I've implemented the simplest EventListener possible by just implementing the EventListener required methods, adding an @Component("mystartup") line and adding my class to components.txt. However, on startup I get an error Failed to lookup component [role = [org.xwiki.observation.ObservationManager] hint = [default]] What am I missing? Is this a chicken and egg problem? @Component("mystartup") public class MyStartup implements EventListener { public List<Event> getEvents() { return Arrays.asList(new ApplicationStartedEvent(), new ApplicationStoppedEvent()); } public String getName() { return "mystartup"; } public void onEvent(Event arg0, Object arg1, Object arg2) { // TODO Auto-generated method stub } java.lang.RuntimeException: Failed to find the Observation Manager component at org.xwiki.container.servlet.XWikiServletContextListener.contextInitialized(XWikiServletContextListener.java:79) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.mortbay.start.Main.invokeMain(Main.java:194) at org.mortbay.start.Main.start(Main.java:523) at org.mortbay.start.Main.main(Main.java:119) Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.observation.ObservationManager] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:263) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:93) at org.xwiki.container.servlet.XWikiServletContextListener.contextInitialized(XWikiServletContextListener.java:76) ... 22 more Caused by: java.lang.NullPointerException at org.xwiki.observation.internal.DefaultObservationManager.addListener(DefaultObservationManager.java:157) at org.xwiki.observation.internal.DefaultObservationManager.initialize(DefaultObservationManager.java:128) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:254) ... 24 more

16 years, 2 months

2
3
0 0

[xwiki-devs] [Proposal] Group wiki macro & it's parameters into a single wiki page (one wiki page, one wiki macro)

by Asiri Rathnayake

Hi Devs, This is because of several reasons, 1. Having one wiki macro per wiki page makes it clean to group a single WikiMacroClass object and several WikiMacroParameterClass objects together and we do not need to keep a reference from WikiMacroParameterClass objects as to which macro in belongs to. 2. It makes the wiki macro registration / updating easy. I mean we only need to track document save / update events involving WikiMacroClass objects. On the other hand if we allow WikiMacros to have their parameters defined in some other documents, things get a little complex. 3. This will make wiki macro presentation easy. We can define a sheet that will present a single wiki macro (inside a single wiki page) in a unque manner to the user. This sheet will not have to bother about other wiki macros in the same document or worry about wiki macro parameters located elsewhere. WDYT? Thanks. - Asiri

16 years, 2 months

5
4
0 0

[xwiki-devs] DocumentAccessBridge - object property values access

by Anamaria Stoica

Hi, Is there a way to get all the values for the properties of an object attached to a page? For example, in my case, I need to get all the properties that were defined and their values for an object which belongs to XWiki.XWikiUsers class, given the name of the document (that the object belongs to). >From my component I use DocumentAccessBridge, but the only methods to get properties values are the ones like: public String getProperty(String documentName, String className, String propertyName) Is there a more elegant way to get all of them, besides calling .getProperty() for each of the property names ? Or, is there a way to get all the properties defined for a class? (i.e. for the XWiki.XWikiUsers class). Are there any other components which provide access to the data model? From what I understood from here [0], the XWiki data model resides in the old xwiki-core module, therefore must be used a bridge (like DocumentAccessBridge). [0] - http://platform.xwiki.org/xwiki/bin/view/DevGuide/WritingComponents#HTheXWi… Thanks a lot, Anamaria

16 years, 2 months

2
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r21865 - in platform/web/trunk/wysiwyg/src/main: java/com/xpn/xwiki/wysiwyg/client java/com/xpn/xwiki/wysiwyg/client/editor java/com/xpn/xwiki/wysiwyg/client/plugin/image/ui java/com/xpn/xwiki/wysiwyg/client/plugin/link/ui java/com/xpn/xwiki/wysiwyg/client/widget/wizard/util java/com/xpn/xwiki/wysiwyg/server resources/com/xpn/xwiki/wysiwyg/client/editor resources/com/xpn/xwiki/wysiwyg/public resources/com/xpn/xwiki/wysiwyg/public/images resources/com/xpn/xwiki/wysiwyg/

by Sergiu Dumitriu

Marius Dumitru Florea wrote: > Hi Anca, >> + /** >> + * Builds a selector from a list of pages of the specified page. >> + * >> + * @param editedResource the currently edited resource (page for which editing is done) >> + */ >> + public AbstractPageListSelectorWizardStep(ResourceName editedResource) >> + { > >> + super(); > > Isn't this called by default? Yes, by default the super constructor with no parameters is called, so this line is not needed. It makes sense to call super only when calling a constructor with parameters. >> + return LinkWizardSteps.WIKIPAGECREATOR.toString(); > > Since I can't use camelcase on constant names I use an underscore > instead to separate words: WIKI_PAGE_CREATOR. I don't know if this is a > code style convension but it is surely more readable. Yes, this is how it should be done. I'll add it on http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle a bit later. Related, I'd like to change the codestyle to allow two consecutive underscores to better separate chunks of the name, like a kind of prefix: DOC_COMMENT__TAG_ADDED, DOC_COMMENT__TAG_REMOVED... -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 2 months

1
0
0 0

[xwiki-devs] [GSoc][XEclipse-Navigator] Mid Term Status.

by Venkatesh Nandakumar

Hi all, You can test the latest xeclipse code by following the README here :- http://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/xeclipse/README The status of the features completed is here:- http://gsoc.myxwiki.org/xwiki/bin/view/XEclipse/ The svn log gives a more detailed explanation of features. http://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/xeclipse/log [svn log copy] The bugs I already know of are written in readme. Please let me know how you think the features have shaped up till now, and of course if you find any bugs. Suggestions for more possible features to the Navigator also welcome. A crude approximation gave me the statistic that I've added upto 7.56% of 1.2rc1 xeclipse codebase. Venkatesh Nandakumar Department of Electronics & Computer Engineering Indian Institute of Technology Roorkee

16 years, 2 months

1
0
0 0

[xwiki-devs] document name with "." in it?

by Pascal Voitot

Hello, For example, I have a space "Space" and I want to create a doc "mydoc.name" in it I do xwiki.getDocument("Space.mydoc.name") but it creates a space "Space.mydoc" and a doc with name "name" is it possible to do that? Pascal

16 years, 2 months

3
3
0 0

by Vincent Massol

On Jul 5, 2009, at 4:32 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-07-05 16:32:57 +0200 (Sun, 05 Jul 2009) > New Revision: 21829 > > Added: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/xwiki/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/xwiki/rendering/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/xwiki/rendering/internal/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/xwiki/rendering/internal/ > macro/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/xwiki/rendering/internal/ > macro/footnote/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/xwiki/rendering/internal/ > macro/footnote/FootnoteMacro.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/xwiki/rendering/internal/ > macro/footnote/PutFootnotesMacro.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/xwiki/rendering/macro/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/xwiki/rendering/macro/ > footnote/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/java/org/xwiki/rendering/macro/ > footnote/FootnoteMacroParameters.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/resources/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/resources/META-INF/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/main/resources/META-INF/components.txt > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/test/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/test/java/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/test/java/org/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/test/java/org/xwiki/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/test/java/org/xwiki/rendering/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/test/java/org/xwiki/rendering/ > RenderingTests.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/test/resources/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/test/resources/macrofootnote1.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-footnotes/src/test/resources/macrofootnote2.test > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/pom.xml > Log: > XWIKI-4065: New Footnote macro > Done. > > More functional tests need to be added. [snip] > +/** > + * Generate footnotes, listed at the end of the page. A reference > to the generated footnote is inserted at the location > + * where the macro is called. > + * > + * @version $Id$ > + * @since 2.0M2 > + */ > +(a)Component(FootnoteMacro.MACRO_NAME) > +public class FootnoteMacro extends > AbstractMacro<FootnoteMacroParameters> > +{ > + /** The name of this macro. */ > + public static final String MACRO_NAME = "footnote"; > + > + /** The description of the macro. */ > + private static final String DESCRIPTION = "Genereates a > footnote to display at the end of the page."; typo: generates [snip] Thanks -Vincent

16 years, 2 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r21811 - in platform: core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/api core/trunk/xwiki-rendering/xwiki-rendering-api core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/parser core/trunk/xwiki-rendering/xwiki-rendering-api/src/main

by Vincent Massol

On Jul 4, 2009, at 2:44 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-07-04 14:44:30 +0200 (Sat, 04 Jul 2009) > New Revision: 21811 > > 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/ > XWiki.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java > platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/api/ > XWikiTest.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/ > DefaultPrintRendererFactory.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/parser/Syntax.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/parser/SyntaxType.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/renderer/PrintRendererFactory.java > platform/web/trunk/standard/src/main/webapp/templates/contentview.vm > platform/web/trunk/standard/src/main/webapp/templates/plain.vm > Log: > XWIKI-4042: Add a way to choose the renderer when viewing a page > > 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-07-04 12:42:14 UTC (rev 21810) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ > Document.java 2009-07-04 12:44:30 UTC (rev 21811) > @@ -37,6 +37,7 @@ > import org.suigeneris.jrcs.diff.DifferentiationFailedException; > import org.suigeneris.jrcs.diff.delta.Delta; > import org.suigeneris.jrcs.rcs.Version; > +import org.xwiki.rendering.parser.Syntax; > > import com.xpn.xwiki.XWiki; > import com.xpn.xwiki.XWikiContext; > @@ -473,6 +474,16 @@ > } > > /** > + * @param targetSyntax the syntax in which render the document > content > + * @return the rendered content > + * @throws XWikiException error when rendering content > + */ > + public String getRenderedContent(Syntax targetSyntax) throws > XWikiException > + { > + return this.doc.getRenderedContent(targetSyntax, > getXWikiContext()); > + } Since this is for Velocity, isn't it better to use a syntax Id String instead of a Syntax object which is hard to construct from velocity? > + > + /** > * return a escaped version of the content of this document > */ > public String getEscapedContent() throws XWikiException > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > api/XWiki.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ > XWiki.java 2009-07-04 12:42:14 UTC (rev 21810) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/ > XWiki.java 2009-07-04 12:44:30 UTC (rev 21811) > @@ -30,6 +30,8 @@ > import org.apache.commons.logging.LogFactory; > import org.suigeneris.jrcs.diff.delta.Chunk; > import org.xwiki.query.QueryManager; > +import org.xwiki.rendering.parser.Syntax; > +import org.xwiki.rendering.renderer.PrintRendererFactory; > > import com.xpn.xwiki.XWikiContext; > import com.xpn.xwiki.XWikiException; > @@ -2685,4 +2687,42 @@ > { > return this.xwiki.getDefaultDocumentSyntax(); > } > + > + /** > + * Find the corresponding available renderer syntax. > + * <p> > + * If <code>syntaxVersion</code> is null the last version of > the available provided syntax type is returned. > + * > + * @param syntaxType the syntax type > + * @param syntaxVersion the syntax version > + * @return the available corresponding {@link Syntax}. Null if > no available renderer can be found. > + */ > + public Syntax getAvailableRendererSyntax(String syntaxType, > String syntaxVersion) > + { > + Syntax syntax = null; > + > + PrintRendererFactory printRendererFactory = > + (PrintRendererFactory) > Utils.getComponent(PrintRendererFactory.class); > + > + List<Syntax> availableSyntaxes = > printRendererFactory.getAvailableSyntaxes(); We already have the notion of available syntaxes in the SyntaxFactory. I don't understand why we need to have them in the PrintRendererFactory (which is not supposed to return syntaxes BTW, it's only supposed to return PrintRenderer(s). > + > + for (Syntax availableSyntax : availableSyntaxes) { Why not instead do: SyntaxType syntaxType = SyntaxType.getSyntaxType(syntaxTypeAsString); And then (when syntaxVersion != null): Syntax syntax = new Syntax(syntaxType, syntaxVersion); And then: syntaxFatory.getAvailableSyntaxes().contains(syntax) hmmm.... Actually thinking more about it, I believe this whole code should be moved out of XWikiDocument and instead go in the rendering module in SyntaxFactory. > + if (syntaxVersion != null) { > + if > (availableSyntax.getType().toIdString().equalsIgnoreCase(syntaxType) > + && > availableSyntax.getVersion().equals(syntaxVersion)) { > + syntax = availableSyntax; > + break; > + } > + } else { > + // TODO: improve version comparaison since it does > not work when comparing 2.0 and 10.0 for example. We > + // should have a Version which implements > Comparable like we have SyntaxId in Syntax > + if > (availableSyntax.getType().toIdString().equalsIgnoreCase(syntaxType) > + && (syntax == null || > availableSyntax.getVersion().compareTo(syntax.getVersion()) > 0)) { > + syntax = availableSyntax; > + } > + } > + } > + > + return syntax; > + } > } [snip] > > /** > + * @return the syntax of the document > + */ > + private Syntax getSyntax() > + { > + Syntax syntax = null; > + > + String syntaxId = getDefaultDocumentSyntax(); > + try { > + syntax = > this.syntaxFactory.createSyntaxFromIdString(getSyntaxId()); Shouldn't we save the Syntax object instead of syntaxId in XWikiDocument so that we don't perform the conversion every time getSyntax is called? > + } catch (ParseException e) { > + LOG.error("Failed to genrate Syntax object for syntax > identifier [" + syntaxId + "] in page [" Typo: generate > + + getDocumentName() + "]", e); > + > + syntaxId = getDefaultDocumentSyntax(); I don't understand this line above, it's the same as the one a few lines above. > + try { > + syntax = > this > .syntaxFactory.createSyntaxFromIdString(getDefaultDocumentSyntax()); It seems you're not using the syntaxId variable. > + } catch (ParseException e1) { > + LOG.error("Failed to genrate default Syntax object. > The defautlt syntax id in [" + syntaxId + "]", e); same typo [snip] > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/ > pom.xml > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml > 2009-07-04 12:42:14 UTC (rev 21810) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml > 2009-07-04 12:44:30 UTC (rev 21811) > @@ -187,7 +187,9 @@ >  > <exclude>org/xwiki/rendering/macro/MacroManager</ > exclude> > <exclude>org/xwiki/rendering/macro/MacroSource</ > exclude> > - <exclude>org/xwiki/rendering/macro/ > AbstractMacroSource</exclude> > + <exclude>org/xwiki/rendering/macro/ > AbstractMacroSource</exclude> > +  It doesn't normally (it' considered as an INFO level) unless it breaks binary compatibility. But I don't know why in your case (would need to check more the code, i'm only looking at the svn diff). > + <exclude>org/xwiki/rendering/renderer/ > PrintRendererFactory</exclude> > </excludes> > </configuration> > </execution> > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/ > src/main/java/org/xwiki/rendering/internal/renderer/ > DefaultPrintRendererFactory.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/ > DefaultPrintRendererFactory.java 2009-07-04 12:42:14 UTC (rev 21810) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/ > DefaultPrintRendererFactory.java 2009-07-04 12:44:30 UTC (rev 21811) > @@ -19,6 +19,10 @@ > */ > package org.xwiki.rendering.internal.renderer; > > +import java.util.Arrays; > +import java.util.Collections; > +import java.util.List; > + > import org.xwiki.component.annotation.Component; > import org.xwiki.component.annotation.Requirement; > import org.xwiki.rendering.parser.Syntax; > @@ -43,6 +47,10 @@ > @Component > public class DefaultPrintRendererFactory implements > PrintRendererFactory > { > + private static final List<Syntax> AVAILABLE_SYNTAXES = > + > Collections.unmodifiableList(Arrays.asList(Syntax.XHTML_1_0, > Syntax.XWIKI_2_0, Syntax.EVENT_1_0, > + Syntax.TEX_1_0, Syntax.PLAIN_1_0)); I don't like this, see above. > + > /** > * Factory to easily create an XHTML Image and Link Renderers. > */ > @@ -55,6 +63,16 @@ > /** > * {@inheritDoc} > * > + * @see > org > .xwiki.rendering.renderer.PrintRendererFactory#getAvailableSyntaxes() > + */ > + public List<Syntax> getAvailableSyntaxes() > + { > + return AVAILABLE_SYNTAXES; > + } > + I don't like this, see above. [snip] Thanks -Vincent

16 years, 2 months

1
0
0 0

[xwiki-devs] default behavior of editsection when including documents?

by Pascal Voitot

Hello, I can now edit sections on my 1.9RCx (modifications where light so I could retrofit them) But when I do sthg like: {{include document="MyDocument"/}} I don't see the section editing for the included content. Is it the default behavior not to propose section editing when the document is included into another one? regards Pascal

16 years, 2 months

2
2
0 0

[xwiki-devs] section editing in wiki/2.0

by Pascal Voitot

Hello, apparently this feature is no more "directly" available in wiki/2.0. But when I use /xwiki/bin/edit/MySpace/MyDoc?section=1, it edits the section 1 of my doc but when I save it, it keeps only section 1 in the doc and removes everything else. Is it a bug? regards Pascal

16 years, 2 months

2
2
0 0

[xwiki-devs] [xoo] XOO status

by Cristina Scheau

Hi all! If you were curious about how is going with XOO, you can install it in your OpenOffice 3.0. You can find more details about how to install it and the extension archive in my blog : http://gsoc.myxwiki.org/xwiki/bin/view/XWiki+Integration+With+Open+Office/X… There are still a lot of features to implement, but your feedback is very important to me. Thank you, Cristina

16 years, 2 months

4
7
0 0

[xwiki-devs] [VOTE] Move wiki macro instantiation code into xwiki-core

by Asiri Rathnayake

Hi Devs, This is about the wiki-macro-bridge. According to our previous discussion, I was going to put document listening, macro creation and macro registration logic into xwiki-core-rendering-macro-wikibridge module. But as it seems the macro creation part is going to be highly dependant on bridges (DAB) and would require a couple of more methods on DAB. Since DAB is becomming heavy and poluted, I'm proposing that we split the wikimacrobridge as follows: * Keep document listening, macro registration and macro de-registration logic inside xwiki-core-rendering-macro-wikibridge module as it is. * Differ the macro instantiation logic into some component interface (WikiMacroGenerator). * Have the default WikiMacroGenerator in xwiki-core. (perhaps inside com.xpn.xwiki.doc? any other place?) Here is my +1. Thanks. - Asiri

16 years, 2 months

5
5
0 0

[xwiki-devs] Accessing the XWiki Source

by Lawry, Joe

All, I just started using XWiki recently and was curious as to how I can access its source. The reason I ask is because there's a link on the Main page that I'd like to modify but can't. The link itself is what users click to log into the wiki and is located above the Registration link on the Main page. I've added another link on the Main page as a temporary solution to the problem but would like to either redirect or remove the link altogether. Thank you in advance for your time. Respectfully, Joe Lawry

16 years, 2 months

2
2
0 0

[xwiki-devs] Blog 2.0 Upgrade Status

by Andreas Schaefer

Hi With a seemingly futile attempt I finally was able to create blog documents with 2.0 syntax. The blog is displaying the the entries as well as the blog web home nicely. The only thing I noticed is that the document of the blog entry is still marked xwiki/1.0. For now except the Blog.WebHome all the changed documents contain a '2' prefix so that it is possible to compare them when needed. I am sure that there is more to be done but for now I am happy that at least the first step is done. As soon as I am back home I will export the blog documents and zip up the changed files. Because I cannot upload them onto this mailing list I was wondering if I should create a JIRA report and attached there. Have fun Andreas Schaefer CEO of Madplanet.com Inc. EMail: andreas.schaefer(a)madplanet.com schaefera(a)me.com Twitter: andy_mpc AIM: schaefera(a)me.com

16 years, 2 months

2
1
0 0

[xwiki-devs] Blog Syntax Upgrade to XWiki Syntax 2.0

by Andreas Schaefer

Using the XWiki blog quite often I am sometimes frustrated by the fact that still in 2.0 M1 the syntax based on 1.0. Beside the fact that nobody found time and/or urge to attack that is there any other reason why this cannot be done ? In case it is possible and someone could tell me where to start looking into it I would try to accomplish that. For now I cannot promise anything because my time is very limited and free time is quite unpredictable. Cheers Andreas Schaefer CEO of Madplanet.com Inc. EMail: andreas.schaefer(a)madplanet.com schaefera(a)me.com Twitter: andy_mpc AIM: schaefera(a)me.com

16 years, 2 months

3
3
0 0

[xwiki-devs] what's the best way to "scrape" an HTML document with Xwiki

by Niels Mayer

Is there anything like the Xwiki-feed-plugin except that instead of fetching a feed, it would fetch an HTML document via HTTP, returning a DOM structure that can be scanned or filtered by API-calls, e.g.: $fetchedDom = $xwiki.FetchPlugin.getDocumentDOM("http://nielsmayer.com") $images = $fetchedDom.getImgList() $media = $fetchedDom.getAnchorHREFsByExtension([".mp3", ".mv4", ".mp4"]) $content = $fetchedDom.getDivListById(['xwikicontent, 'container', 'content']) Since this would happen on the server, you'd probably need to "fake" being a real browser (or just capture the user's browser configuration and pass it via the call to the hypothetical "getDocumentDOM()" in order to capture an accurate scraped representation of a modern site.) The existing examples I've seen store an Xwiki document in the database first. I was hoping there was an "in memory" option that would allow for the document to be maintained in the app's context for long enough to process the remaining stream of plugin calls such as "getDivListById()" or "getAnchorHREFsByExtension()" and then appropriately dispose the DOM when no longer referenced, via garbage collection. Maybe compared to the implementation headaches -- of retrieving a potentially large document into memory incrementally, parsing it into a DOM incrementally, making that available in the context, etc -- maybe I should just write the damn document into the database, scrape it, and delete it. Since I would use Xwiki to store a JSON "scrape" of the document in the DB (as a xwiki doc), I could store it in XWiki.JavaScriptExtension[0] of the retrieved document, and then just delete the wiki-contents after scraping.... So actually, if anybody has any suggestions for "scraping" with a retrieved document, stored as Xwiki doc, please, suggest as well! This seems like an area potentially fraught with peril that many people have already dealt with, so I would appreciate advice. Thanks, Niels http://nielsmayer.com

16 years, 2 months

3
3
0 0

[xwiki-devs] Blog 2.0 Conversion

by Andreas Schaefer

Hi Well, right now it is 1 step forward and 2 steps back. After much trial and error I finally did this: Convert to 2.0: - BlogSheet - CreatePost - BlogPostTemplate - BlogPostSheet This enables me to create a 2.0 blog entry but the display of that entry fails miserable. For example the Edit Tools (Publish/Hide, Edit, Delete) are having comment added to it because 2.0 adds comments of what it is doing into the HTML page but when that is inside a string ("") and the code contains double quotes as well all hell breaks loose. But when I tried to convert BlogCode (which contains the creation of the Edit Tools) then the panels start to fail. In turn these panels are still 1.0 and so I cannot convert all of them. Any idea how to fix that? Thanks - Andy

16 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs