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

Re: [xwiki-devs] [xwiki-notifications] r23347 - in platform: core/trunk/xwiki-core/src/main/resources web/trunk/standard/src/main/webapp/templates xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist
by Sergiu Dumitriu 09 Sep '09

09 Sep '09

Could you merge the changes for menuview.vm to the colibri skin? On Tue, Sep 8, 2009 at 18:09, jvdrean<platform-notifications(a)xwiki.org> wrote: > Author: jvdrean > Date: 2009-09-08 18:09:29 +0200 (Tue, 08 Sep 2009) > New Revision: 23347 > > Modified: > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties > platform/web/trunk/standard/src/main/webapp/templates/menuview.vm > platform/web/trunk/standard/src/main/webapp/templates/watch.vm > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListEvent.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListEventMatcher.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListJob.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListPluginApi.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListStore.java > Log: > XWIKI-4298 : Add watch/unwatch wiki in the Watch menu > XPWATCHLIST-60 : Watch List should support registering for user activity > > The API is now complete. The backend for the future "follow user activity" is implemented and can be used through the object editor. -- http://purl.org/net/sergiu

2 1

Re: [xwiki-devs] [xwiki-notifications] r23368 - platform/skins/trunk/colibri/src/main/resources/colibri
by Vincent Massol 09 Sep '09

09 Sep '09

Hi Sergiu, On Sep 9, 2009, at 8:28 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-09-09 08:28:17 +0200 (Wed, 09 Sep 2009) > New Revision: 23368 > > Modified: > platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm > Log: > XSCOLIBRI-68: Duplicate titles on some pages > Fixed on most pages. > > > Modified: platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm > =================================================================== > --- platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm 2009-09-09 06:07:41 UTC (rev 23367) > +++ platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm 2009-09-09 06:28:17 UTC (rev 23368) > @@ -33,7 +33,6 @@ > #set($content = > $content.trim().substring($content.trim().indexOf($util.newline))) > #end > #end > - ## #set($renderedContent =$cdoc.getRenderedContent()) > #set($renderedContent = $cdoc.getRenderedContent($content, > $cdoc.syntaxId)) > #end > <div id="document-title"><h1>$tdoc.displayTitle</h1></div> > @@ -42,7 +41,7 @@ > ## > ## Display the rendered content > ## > -$renderedContent > +$renderedContent.replaceFirst('^[ \n\r\t]*+<h1.*?</h1>', '') I'm not sure I understand the algorithm. Also you mention "most pages". Does it mean there are cases where this is not working? Thanks -Vincent PS: We're also missing the config flag.

1 0

Re: [xwiki-devs] [xwiki-notifications] r23356 - in platform/core/trunk/xwiki-rendering: . xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/internal/parser/wikimodel
by Vincent Massol 08 Sep '09

08 Sep '09

On Sep 8, 2009, at 8:52 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-08 20:52:51 +0200 (Tue, 08 Sep 2009) > New Revision: 23356 > > Modified: > platform/core/trunk/xwiki-rendering/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki- > rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/XDOMGeneratorListener.java > Log: > XWIKI-4177: Verbatim block and monospace break table > > Modified: platform/core/trunk/xwiki-rendering/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-rendering/pom.xml 2009-09-08 18:12:11 > UTC (rev 23355) > +++ platform/core/trunk/xwiki-rendering/pom.xml 2009-09-08 18:52:51 > UTC (rev 23356) > @@ -41,7 +41,7 @@ > <dependency> > <groupId>org.wikimodel</groupId> > <artifactId>org.wikimodel.wem</artifactId> > - <version>2.0.7-20090811</version> > + <version>2.0.7-20090908</version> > </dependency> > </dependencies> > </dependencyManagement> > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering- > parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/ > rendering/internal/parser/wikimodel/XDOMGeneratorListener.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/ > xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/XDOMGeneratorListener.java 2009-09-08 > 18:12:11 UTC (rev 23355) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/ > xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/XDOMGeneratorListener.java 2009-09-08 > 18:52:51 UTC (rev 23356) > @@ -302,55 +302,57 @@ > */ > public void endFormat(WikiFormat format) > { > - // Get the styles: the styles are wiki syntax styles (i.e. > styles which have a wiki syntax such as bold, italic ,etc). > - // As opposed to format parameters which don't have any > specific wiki syntax (they have a generic wiki syntax such as > + // Get the styles: the styles are wiki syntax styles (i.e. > styles which have a wiki syntax such as bold, italic > + // ,etc). > + // As opposed to format parameters which don't have any > specific wiki syntax (they have a generic wiki syntax > + // such as > // (% a='b' %) for example in XWiki Syntax 2.0. > List<WikiStyle> styles = format.getStyles(); > - > - // If there's any style or parameter defined, do something. > The reason we need to check for this is because wikimodel > + > + // If there's any style or parameter defined, do something. > The reason we need to check for this is because > + // wikimodel > // sends an empty begin/endFormat event before starting an > inline block (such as a paragraph). > if ((styles.size() > 0) || (format.getParams().size() > 0)) { > > // Generate nested FormatBlock blocks since XWiki uses > nested Format blocks whereas Wikimodel doesn't. > // > // Simple Use Case: (% a='b' %)**//hello//**(%%) > - // WikiModel Events: > - // beginFormat(params: a='b', styles = BOLD, ITALIC) > - // onWord(hello) > - // endFormat(params: a='b', styles = BOLD, ITALIC) > + // WikiModel Events: > + // beginFormat(params: a='b', styles = BOLD, ITALIC) > + // onWord(hello) > + // endFormat(params: a='b', styles = BOLD, ITALIC) > // XWiki Blocks: > - // FormatBLock(params: a='b', format = BOLD) > - // FormatBlock(format = ITALIC) > + // FormatBLock(params: a='b', format = BOLD) > + // FormatBlock(format = ITALIC) > // > // More complex Use Case: **(% a='b' %)hello**world > - // WikiModel Events: > - // beginFormat(params: a='b', styles = BOLD) > - // onWord(hello) > - // endFormat(params: a='b', styles = BOLD) > - // beginFormat(params: a='b') > - // onWord(world) > - // endFormat(params: a='b') > + // WikiModel Events: > + // beginFormat(params: a='b', styles = BOLD) > + // onWord(hello) > + // endFormat(params: a='b', styles = BOLD) > + // beginFormat(params: a='b') > + // onWord(world) > + // endFormat(params: a='b') > // XWiki Blocks: > - // FormatBlock(params: a='b', format = BOLD) > - // WordBlock(hello) > - // FormatBlock(params: a='b') > - // WordBlock(world) > - > + // FormatBlock(params: a='b', format = BOLD) > + // WordBlock(hello) > + // FormatBlock(params: a='b') > + // WordBlock(world) > + > // TODO: We should instead have the following which > would allow to simplify XWikiSyntaxChaining Renderer > // which currently has to check if the next format has > the same params as the previous format to decide > // whether to print it or not. > - // FormatBlock(params: a='b') > - // FormatBlock(format = BOLD) > - // WordBlock(hello) > - // WordBlock(world) > - > + // FormatBlock(params: a='b') > + // FormatBlock(format = BOLD) > + // WordBlock(hello) > + // WordBlock(world) Thomas there are lots of reformatting in your commit. In general it would be great to not reformat during a normal commit since it makes it harder to read. In addition I have the feeling the reformatting has broken all my formatting. Thanks -Vincent > + > FormatBlock block; > if (styles.size() > 0) { > block = new FormatBlock(generateListFromStack(), > convertFormat(styles.get(styles.size() - 1))); > } else { > block = new FormatBlock(generateListFromStack(), > Format.NONE); > } > - > > if (styles.size() > 1) { > ListIterator<WikiStyle> it = > styles.listIterator(styles.size() - 1); > @@ -377,7 +379,7 @@ > } > > } else { > - // Empty format. We need to remove our marker so pop > all blocks after our marker and push them back on > + // Empty format. We need to remove our marker so pop > all blocks after our marker and push them back on > // the stack. > for (Block block : generateListFromStack()) { > this.stack.push(block); > @@ -559,10 +561,11 @@ > > /** > * {@inheritDoc} > - * > - * <p>Called when WikiModel finds an reference (link or image) > such as a URI located directly in the text > - * (free-standing URI), as opposed to a link/image inside wiki > link/image syntax delimiters.</p> > - * > + * <p> > + * Called when WikiModel finds an reference (link or image) > such as a URI located directly in the text > + * (free-standing URI), as opposed to a link/image inside wiki > link/image syntax delimiters. > + * </p> > + * > * @see org.wikimodel.wem.IWemListener#onLineBreak() > */ > public void onReference(String reference) > @@ -613,8 +616,8 @@ > */ > public void onImage(WikiReference ref) > { > - this.stack.push(new > ImageBlock(this.imageParser.parse(ref.getLink()), false, > convertParameters(ref > - .getParameters()))); > + this.stack.push(new > ImageBlock(this.imageParser.parse(ref.getLink()), false, > + convertParameters(ref.getParameters()))); > } > > /** > @@ -784,4 +787,28 @@ > > return resultBlock; > } > + > + public void beginSection(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > + > + public void beginSectionContent(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > + > + public void endSection(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > + > + public void endSectionContent(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > }

1 0

[xwiki-devs] Does it make sense to add a method for saving many docs in one transaction?
by Caleb James DeLisle 08 Sep '09

08 Sep '09

It seems like there is increasing need for saving groups of documents in a single transaction. I was thinking maybe this would be a good method: XWiki.saveDocuments(List<XWikiDocument> XWikiContext) It would be up to the calling method to set the comment and isMinorEdit field in the documents before sending them to saveDocuments. Is this deserving of a jira improvement issue? What do you folks think? Caleb James DeLisle

2 1

[xwiki-devs] Translation Wiki
by hel-o 08 Sep '09

08 Sep '09

Hi, there seems to be a problem with the translation wiki, just logged in, only language available is zh and theres a application "hallo" hel. ----- semantic-web.hel.at hel(a)hel.at -- View this message in context: http://n2.nabble.com/Translation-Wiki-tp3601693p3601693.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

3 3

Re: [xwiki-devs] [xwiki-notifications] r23335 - platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-python/src/main/java/org/xwiki/rendering/internal/macro/python
by Vincent Massol 08 Sep '09

08 Sep '09

Thomas, Be careful that you need to update the jython macro doc on code.xwiki.org too since it says both macro names can be used I think. Thanks -Vincent On Sep 8, 2009, at 10:08 AM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-08 10:08:09 +0200 (Tue, 08 Sep 2009) > New Revision: 23335 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-python/src/main/java/org/xwiki/rendering/internal/ > macro/python/PythonMacro.java > Log: > XWIKI-2798: Create jython macro for rendering 2.0 > * remove "jython" hint until we find a better solution from the > WYSIWYG POV > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/ > xwiki-rendering-macro-python/src/main/java/org/xwiki/rendering/ > internal/macro/python/PythonMacro.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-python/src/main/java/org/xwiki/rendering/internal/ > macro/python/PythonMacro.java 2009-09-08 06:38:19 UTC (rev 23334) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-python/src/main/java/org/xwiki/rendering/internal/ > macro/python/PythonMacro.java 2009-09-08 08:08:09 UTC (rev 23335) > @@ -30,7 +30,7 @@ > * @version $Id$ > * @since 2.0M2 > */ > -@Component(hints = {"python", "jython" }) > +@Component("python") > public class PythonMacro extends > AbstractJSR223ScriptMacro<JSR223ScriptMacroParameters> > { > /**

1 0

Re: [xwiki-devs] Blog Plugin Proposal
by Guillaume Lerouge 08 Sep '09

08 Sep '09

Hi Andreas, On Mon, Aug 31, 2009 at 1:11 AM, Andreas Schaefer <schaefera(a)me.com> wrote: > My try to deploy the Blog Plugin together with the updated Blog > Application failed miserably today and my dislike of Velocity reach a > new high. > > Because I see the value of the scripting nature of the Blog allowing > users to customize their Blog to a quite large degree I don't want to > ditch that but I have a lot of problems with Velocity and the way is > plastering over issues. I rather fail fast than late with hardly a > trail to understand what is going on. > My personal experience with velocity is more of a try & fail, try & fail, try and succeed one than anything else. What I found out is that I was msot of the time better off rewriting stuff starting with small chunks rather than trying to take existing code and reuse it all at once. The current blog is a fairly complex piece of velocity code (that is, given the lack of debugging tools when coding in velocity in the wiki). This is one of the reasons I think Sergiu's argument that "devs will be able to look at the code and learn from it" is not entirely true ;-) What's really important for the blog is that it can be customized easily at 2 levels: - Look: an user should be able to use the panels she wants for her blog - Deployment: an user should be able to create a new space blog or global wiki blog in any space she wants Besides that the way the blog is code doesn't matter much for the end user. That said I still think that it might be a good idea to convert the > scripted part of the Blog over to Groovy and keep the rest in the Blog > Plugin. I don't have any experience with Groovy inside XWiki but for > sure the documentation of Groovy outside is excellent compared to > Velocity. I will use the next week to get up to speed and try to > convert a piece of the Blog over to Groovy. Then go ahead and give it a go :-) One thing you need to be aware of when using Groovy inside the wiki is that your pages will haveto be saved using programming rights. This can cause a number of issues, don't forget to code with an user that has them, it will save yo ua lot of hassle ;-) > Cheers - Andy > Good luck and thanks for all the nice work, Guillaume > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

3 3

[xwiki-devs] Can't find descriptor for the component DocumentAccessBridge
by Juri Kühn 05 Sep '09

05 Sep '09

Hi all, first of all, thanks for the great work, xwiki is a great product i'm trying to integrate the rendering component of xwiki into our application for hours, without success. I included all the libraries from XWiki 2.0 M4 and was running following code in a standalone application (not within servlet container, but thats no problem?) -- EmbeddableComponentManager componentManager = new EmbeddableComponentManager(); componentManager.initialize(this.getClass().getClassLoader()); Parser parser = (Parser)componentManager.lookup(Parser.class, Syntax.XWIKI_2_0.toIdString()); XDOM xdom = parser.parse(new StringReader("test")); // Generate XHTML PrintRendererFactory rf = componentManager.lookup(PrintRendererFactory.class, Syntax.XHTML_1_0.toIdString()); DefaultWikiPrinter printer = new DefaultWikiPrinter(); Renderer htmlRenderer = rf.createRenderer(printer); // Perform the rendering - the exception is raised here xdom.traverse(htmlRenderer); -- The stacktrace is attached below. The DocumentAccessBridge component cannot be loaded. I tried to figure out what is going on and debugged around. The loop that loads all descriptors for xwiki components doesnt include DocumentAccessBridge. There is no META-INF/components.txt in the xwiki-core-bridge-2.0-milestone-4.jar and no class in this library has the @Component annotation. I just cannot figure out what is going wrong. Different parsers and printrenderers (other than XWIKI_2_0 and XHTML_1_0) as the use of the Converter instead of Parser produce the same result. What am i doing wrong? Any help would be really appreciated. Best regards, Juri Output and Stacktrace: 05.09.2009 00:50:35 org.xwiki.component.logging.CommonsLoggingLogger warn WARNUNG: Component [org.xwiki.rendering.internal.configuration.DefaultRenderingConfiguration] is being overwritten by component [org.xwiki.rendering.internal.configuration.XWikiRenderingConfiguration] for Role/Hint [role = [org.xwiki.rendering.configuration.RenderingConfiguration] hint = [default]]. It will not be possible to look it up. 05.09.2009 00:50:35 org.xwiki.component.logging.CommonsLoggingLogger warn WARNUNG: Component [org.xwiki.rendering.internal.renderer.DefaultLinkLabelGenerator] is being overwritten by component [org.xwiki.rendering.internal.renderer.XWikiLinkLabelGenerator] for Role/Hint [role = [org.xwiki.rendering.renderer.LinkLabelGenerator] hint = [default]]. It will not be possible to look it up. 05.09.2009 00:50:35 org.xwiki.component.logging.CommonsLoggingLogger warn WARNUNG: Failed to load configuration file [/WEB-INF/xwiki.properties]. Using default configuration. Internal error [null] Exception in thread "main" java.lang.RuntimeException: Failed to create [XHTML 1.0] renderer at org.xwiki.rendering.internal.renderer.AbstractPrintRendererFactory.createRenderer(AbstractPrintRendererFactory.java:51) at de.lernbase.XWikiRenderTest.doit(XWikiRenderTest.java:30) at de.lernbase.XWikiRenderTest.main(XWikiRenderTest.java:58) Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.renderer.PrintRenderer] hint = [xhtml/1.0]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.internal.DefaultComponentManager.lookup(DefaultComponentManager.java:85) at org.xwiki.rendering.internal.renderer.AbstractPrintRendererFactory.createRenderer(AbstractPrintRendererFactory.java:49) ... 2 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.renderer.xhtml.XHTMLLinkRenderer] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 5 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.renderer.LinkLabelGenerator] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 9 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.configuration.RenderingConfiguration] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 13 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.configuration.ConfigurationSource] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 17 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.configuration.ConfigurationSource] hint = [wiki]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 21 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.bridge.DocumentAccessBridge] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 25 more Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component [role = [org.xwiki.bridge.DocumentAccessBridge] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:325) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 29 more

4 5

Re: [xwiki-devs] [xwiki-users] [Vote] Default Color Theme
by Ecaterina Valica 04 Sep '09

04 Sep '09

Current Votes: (0) +0.5 Anca (1) (2) +1 Lucien, +0.66 Marta, +0.5 Jean C, +1 Gaëtan, +0.66 Raluca, +0.5 Vincent G, +1 Emilie, (3) +1 G, +1 Christophe P, +0.33 Raluca, (4) +1 Caty, +1 Vincent, +1 Ricardo R, +1 Florin, +1 Silvia, +0.5 Trevor, +1 Marius (5) +0.33 Marta, (A) (B) +1 Oana, +1 Thomas M, +1 Sergiu, +0.5 Vincent G, +1 Philipp, +1 Martijn, +0.5 Trevor (C) +0.5 Anca, +0.5 Jean C (D) (E) (F) (G) (H)

4 7

[xwiki-devs] documenting changes in trusted rights
by [Ricardo Rodriguez] Your EPEC Network ICT Team 04 Sep '09

04 Sep '09

Hi! One of the biggest problems I've been facing concerning changes in a property, or the access rights to a document or space is how to keep track of the reasons that cause them. I mean, for instance, how could we document the reason (a message sent by the responsible of some contents, a detected abuse,...) why some rights have been granted or denied to one or several users or a group? Is this a matter of programming, data model or it is an absolutely absurd idea? Having the wiki model in charge of documenting who, when and why a change is done in a document, I truly miss a system to keep track on the assigned rights as a metaphor of the trusting relationship on a given document or space. Thanks in advance for your thoughts! Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

1 0