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
> +
> + }
> }
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
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.
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/
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
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