xwiki-devs June 2009

xwiki-devs@xwiki.org

36 participants
117 discussions

[xwiki-devs] Macros and 1.0 2.0 xwiki syntax

by glenn_engel＠agilent.com

I have a java macro which I've written that I'd like to reference from a panel. Is there a way to use xwiki 2.0 syntax in a panel so I can invoke my macro? It would appear that panels utilize 1.0 syntax? As a workaround I added yet another 2.0 page with just the macro invocation and then included that page in the panel. It seems like a catch22 if I create a component macro I can only use it in 2.0 and if I create a radeox macro I can only use it in 1.0. How does one write a macro that can be accessable from 1.0 or 2.0 as well as from a panel? Or, will the 1.0 be jettisoned entirely at some point ? Thanks, Glenn

15 years, 6 months

Re: [xwiki-devs] [xwiki-notifications] r20796 - platform/xwiki-applications/trunk/tag/src/main/resources/XWiki

by Sergiu Dumitriu

jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-06-04 15:27:25 +0200 (Thu, 04 Jun 2009) > New Revision: 20796 > > Modified: > platform/xwiki-applications/trunk/tag/src/main/resources/XWiki/TagCloud.xml > Log: > XATAG-11 : Modify TagCloud style to make it look better outside of the dashboard > > Modified: platform/xwiki-applications/trunk/tag/src/main/resources/XWiki/TagCloud.xml > =================================================================== > --- platform/xwiki-applications/trunk/tag/src/main/resources/XWiki/TagCloud.xml 2009-06-04 13:21:14 UTC (rev 20795) > +++ platform/xwiki-applications/trunk/tag/src/main/resources/XWiki/TagCloud.xml 2009-06-04 13:27:25 UTC (rev 20796) What is this? Please remove it. > + text-justify: auto; -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 6 months

[xwiki-devs] [Rendering] Adding a Plain text parser & syntax

by Vincent Massol

Hi, I think we need to add a plain text parser & a "plain/1.0" syntax id. Here's a use case: you want to add a groovy class in a wiki page (and you don't want it to be rendered as wiki syntax of course). WDYT? Thanks -Vincent

15 years, 6 months

[xwiki-devs] [VOTE] Modify Block.replace() API

by Vincent Massol

Hi, Following the previously aborted vote, here's a new proposal. The problem with the current implementation is that you cannot write: for (LinkBlock block : xdom.getChildrenByType(LinkBlock.class, true)) { Block newBlock = new FormatBlock(Collections.<Block>singletonList(block), Format.ITALIC); block.replace(newBlock); } This fails because when the "block" is added in FormatBlock, its parent is set to be the FormatBlock and thus when block.replace() executes the parent of the new block is set to be the format block instead of its parent. I thus propose an API that is inline with the w3c DOM API: /** * Replaces an existing children block with the passed new block. * Also sets the new block's parent to be the current block. * * @param newBlock the new block to replace the old block with */ void replaceChild(Block newBlock, Block oldBlock); /** * Replaces an existing children block with the passed new blocks. * Also sets the new block's parents to be the current block. * * @param newBlocks the new blocks to replace the old block with */ void replaceChild(List<Block> newBlocks, Block oldBlock); Note for Sergiu (before he asks ;)): - We had evaluated using either the w3c Node API or the JCR Node API before we created our own Block API. - We cannot use the w3c Node interface since it contains too many references to XML (like CDATA, ProcessingInstruction, etc) - We cannot use the JCR Node API since it's too complex and contains references to mixins, etc. Here's my +1 Thanks -Vincent

15 years, 6 months

[xwiki-devs] Plugin Spaces

by glenn_engel＠agilent.com

It seems that plugins that need to add panels or js/css support files end up creating a space with pages to store these elements. This in turn seems like it would lead to a plethora of spaces for which end users don't really have much use. Ideally it would be nice to just have all these files in the jar file and have them invisibly be part of xwiki without needing to import an xar and create a new space. The advantage of this is you have a nice single package for updating and installation. This is typical of a confluence plugin. Are there any plans to allow for 'plugin spaces' that might be 'hidden' or possibly have content provided more easily from a jar? On a separate but related note, how do people deal today with revision control when there are wiki pages needed as part of a plugin? Do you keep exporting the plugin space and checking in xar files? I'm currently keeping page content separately as conventional files and pasting them into the wiki for testing. I guess I'm not reporting anything is broke here but seems like some rough edges I'd like to smooth out. -- Glenn

15 years, 6 months

[xwiki-devs] [VOTE] Add Block.replace(Block) API in Rendering

by Vincent Massol

Hi, Right now we have a Block.replace(List<Block> newBlocks) API but I'd like to add a new one: Block.replace(Block newBlock); Here's a use case, be able to write: for (LinkBlock block : xdom.getChildrenByType(LinkBlock.class, true)) { Block newBlock = new FormatBlock(Collections.<Block>singletonList(block), Format.ITALIC); block.replace(newBlock); } Rather than: for (LinkBlock block : xdom.getChildrenByType(LinkBlock.class, true)) { Block newBlock = new FormatBlock(Collections.<Block>singletonList(block), Format.ITALIC); block.replace(Collections.<Block>singletonList(newBlock)); } The rationale is that in most cases when we do a replace we do it with a single block since most of our blocks contain children blocks. I'd like to add this in 2.0 and also in 1.9 (not breaking anything). The reason for 1.9 is that I'd like to use it in our Rendering documentation (actually that's how I discovered the pb). Here's my +1 Thanks -Vincent

15 years, 6 months

[xwiki-devs] [VOTE] Change checkstyle.xml to ignore the length of lines with GWT JSNI calls

by Marius Dumitru Florea

Hi devs, Currently our Checkstyle configuration contains this: <module name="LineLength"> <property name="ignorePattern" value="(@version|@see|@link|^import)"/> <property name="max" value="120"/> </module> I propose we add the following pattern to the ignorePattern property: @(\w+\.)+\w+::\w+\( The reason is that "Java identifiers referenced from within JSNI methods can get quite long and cannot be parsed if split across lines." ( http://code.google.com/webtoolkit/makinggwtbetter.html#codestyle ). Here's an example: var editor = @com.xpn.xwiki.wysiwyg.client.editor.WysiwygEditorApi::new(Lorg/xwiki/gwt/dom/client/JavaScriptObject;)(config); editor.@com.xpn.xwiki.wysiwyg.client.editor.WysiwygEditorApi::getSourceText(Lorg/xwiki/gwt/dom/client/JavaScriptObject;Lorg/xwiki/gwt/dom/client/JavaScriptObject;)(onSuccess, onFailure); So without modifying the ignorePattern I'm forced to exclude an entire Java source file from Checkstyle just because some of the JSNI lines are too long. I'm +1 changing the ignorePattern property. Thanks, Marius

15 years, 6 months

Re: [xwiki-devs] [xwiki-notifications] r20727 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc

by Thomas Mortagne

On Wed, Jun 3, 2009 at 06:45, asiri <platform-notifications(a)xwiki.org> wrote: > Author: asiri > Date: 2009-06-03 06:45:22 +0200 (Wed, 03 Jun 2009) > New Revision: 20727 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java > Log: > [misc] Made setParent() method use a compact document name serializer instead of the toString() method in DocumentName class. > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java 2009-06-03 00:14:00 UTC (rev 20726) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java 2009-06-03 04:45:22 UTC (rev 20727) > @@ -605,7 +605,9 @@ > */ > public void setParent(DocumentName parentName) > { > - this.parent = parentName.toString(); > + DocumentNameSerializer serializer = > + (DocumentNameSerializer) Utils.getComponent(DocumentNameSerializer.class, "compact"); You don't need that, there is already a compactDocumentNameSerializer initialized in XWikiDocument constructor. > + this.parent = serializer.serialize(parentName); > } > > public String getFullName() > @@ -3154,10 +3156,10 @@ > > public List<String> getChildren(XWikiContext context) throws XWikiException > { > - String[] whereParams = { this.getWikiName() + ":" + this.getFullName(), this.getFullName(), this.getName(), > - this.getSpace() }; > - > - String whereStatement = "doc.parent=? or doc.parent=? or (doc.parent=? and doc.space=?)"; > + String[] whereParams = > + {this.getWikiName() + ":" + this.getFullName(), this.getFullName(), this.getName(), this.getSpace()}; > + > + String whereStatement = "doc.parent=? or doc.parent=? or (doc.parent=? and doc.space=?)"; > return context.getWiki().getStore().searchDocumentsNames(whereStatement, Arrays.asList(whereParams), context); > } > > @@ -3953,10 +3955,7 @@ > * renaming algorithm takes into account the fact that there are several ways to write a link to a given page and > * all those forms need to be renamed. For example the following links all point to the same page: > * <ul> > - * <li>[Page]</li> > - * <li>[Page?param=1]</li> > - * <li>[currentwiki:Page]</li> > - * <li>[CurrentSpace.Page]</li> > + * <li>[Page]</li> <li>[Page?param=1]</li> <li>[currentwiki:Page]</li> <li>[CurrentSpace.Page]</li> > * </ul> > * <p> > * Note: links without a space are renamed with the space added. > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > -- Thomas Mortagne

15 years, 6 months

Re: [xwiki-devs] [xwiki-notifications] r20727 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc

by Vincent Massol

On Jun 3, 2009, at 6:45 AM, asiri (SVN) wrote: > Author: asiri > Date: 2009-06-03 06:45:22 +0200 (Wed, 03 Jun 2009) > New Revision: 20727 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java > Log: > [misc] Made setParent() method use a compact document name > serializer instead of the toString() method in DocumentName class. > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > doc/XWikiDocument.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java 2009-06-03 00:14:00 UTC (rev 20726) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java 2009-06-03 04:45:22 UTC (rev 20727) > @@ -605,7 +605,9 @@ > */ > public void setParent(DocumentName parentName) > { > - this.parent = parentName.toString(); > + DocumentNameSerializer serializer = > + (DocumentNameSerializer) > Utils.getComponent(DocumentNameSerializer.class, "compact"); > + this.parent = serializer.serialize(parentName); > } > > public String getFullName() > @@ -3154,10 +3156,10 @@ > > public List<String> getChildren(XWikiContext context) throws > XWikiException > { > - String[] whereParams = { this.getWikiName() + ":" + > this.getFullName(), this.getFullName(), this.getName(), > - this.getSpace() }; > - > - String whereStatement = "doc.parent=? or doc.parent=? or > (doc.parent=? and doc.space=?)"; > + String[] whereParams = > + {this.getWikiName() + ":" + this.getFullName(), > this.getFullName(), this.getName(), this.getSpace()}; > + > + String whereStatement = "doc.parent=? or doc.parent=? or > (doc.parent=? and doc.space=?)"; > return > context.getWiki().getStore().searchDocumentsNames(whereStatement, > Arrays.asList(whereParams), context); > } > > @@ -3953,10 +3955,7 @@ > * renaming algorithm takes into account the fact that there are > several ways to write a link to a given page and > * all those forms need to be renamed. For example the following > links all point to the same page: > * <ul> > - * <li>[Page]</li> > - * <li>[Page?param=1]</li> > - * <li>[currentwiki:Page]</li> > - * <li>[CurrentSpace.Page]</li> > + * <li>[Page]</li> <li>[Page?param=1]</li> > <li>[currentwiki:Page]</li> <li>[CurrentSpace.Page]</li> Can you put back the nicely formatted javadoc? Thanks -Vincent

15 years, 6 months

[xwiki-devs] [Proposal] Reorganize the document footer

by Sergiu Dumitriu

Hello devs, I'd like to reorganize the document footer as depicted in http://incubator.myxwiki.org/xwiki/bin/view/Mockups/DocumentFooter , namely: 1: Tags will be displayed after the document content, as links to tag pages, and not in an input element in the Information tab as they are now. They are still editable in view mode by clicking an edit button available after the tags list. 2. The "Created by ... on ..." information about the document will be displayed before "Last modified by...", under the document content, and not down in the page footer, where it seems ambiguous (seems to be referring to the whole wiki), nor in the Information tab. 3. The "Information" tab becomes "Related documents", since it does not contain the tags and the creator anymore. The related documents are: * parent (editable in view mode by the same mechanism as the tags) * children * included documents * links and backlinks 4. A new "Rights" tab is displayed for admins after "Related pages", basically providing the rights management UI. Here's my +1. Any objections / other suggestions? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2009