March 2009 - xwiki-devs@xwiki.org

[xwiki-devs] [PROPOSAL] Add a setParent() method to DocumentAccessBridge / DocumentModelBridge
by Asiri Rathnayake 23 Mar '09

23 Mar '09

Hi Devs, I'm in need of a method to set the parent document of a given document. So until the we remodel the model classes (when? xwiki 2.0 release?), I propose to add the following method: void setParent(String parentDoc); Now the next question is where to add this method? DocumentAccessBridge or DocumentModelBridge? To me it seems to fit DocumentModelBridge. WDYT? Thanks. - Asiri

4 4

Re: [xwiki-devs] [xwiki-notifications] r17925 - in platform/core/trunk: xwiki-bridge/src/main/java/org/xwiki/bridge xwiki-core/src/main/java/com/xpn/xwiki/doc
by Vincent Massol 23 Mar '09

23 Mar '09

On Mar 23, 2009, at 3:01 PM, asiri (SVN) wrote: > Author: asiri > Date: 2009-03-23 15:01:31 +0100 (Mon, 23 Mar 2009) > New Revision: 17925 > > Modified: > platform/core/trunk/xwiki-bridge/src/main/java/org/xwiki/bridge/ > DocumentModelBridge.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java > Log: > XWIKI-3427: Introduce DocumentModelBridge.setParent() method > > * Implemented. > > Modified: platform/core/trunk/xwiki-bridge/src/main/java/org/xwiki/ > bridge/DocumentModelBridge.java > =================================================================== > --- platform/core/trunk/xwiki-bridge/src/main/java/org/xwiki/bridge/ > DocumentModelBridge.java 2009-03-23 13:20:50 UTC (rev 17924) > +++ platform/core/trunk/xwiki-bridge/src/main/java/org/xwiki/bridge/ > DocumentModelBridge.java 2009-03-23 14:01:31 UTC (rev 17925) > @@ -30,6 +30,13 @@ > public interface DocumentModelBridge > { > /** > + * Sets the parent document attribute of this document to the > given value. > + * > + * @param parent the {@link DocumentModelBridge} representing > the parent document. > + */ > + void setParent(DocumentModelBridge parent); > + > + /** > * Retrieve the full name of the document, in the > <code>Space.Name</code> format, for example <tt>Main.WebHome</tt>. > * > * @return A <code>String</code> representation of the > document's full name. > > 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-03-23 13:20:50 UTC (rev 17924) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java 2009-03-23 14:01:31 UTC (rev 17925) > @@ -567,6 +567,14 @@ > this.name = name; > } > > + /** > + * {@inheritDoc} > + */ > + public void setParent(DocumentModelBridge parent) > + { > + this.parent = parent.getFullName(); > + } > + This looks strange and not corredct. I don't understand this since there's already a setParent() and it looks confusing to me. Why do you need to pass a DocumentModelBridge instead of a string (which already exists)? Thanks -Vincent > > public String getFullName() > { > StringBuffer buf = new StringBuffer();

2 1

[xwiki-devs] Why can't we use the id macro inside a heading, table cell etc. ?
by Asiri Rathnayake 23 Mar '09

23 Mar '09

Hi devs, I came across this problem when trying to fix: http://jira.xwiki.org/jira/browse/XWIKI-3416. According to http://learningforlife.fsu.edu/webmaster/references/xhtml/tags/hypertext/a.… xhtml anchor can appear inside several other elements like headings, table cells, table headers and many more. But in xwiki syntax I have to place the Id macro always on a new line and this complicates things a lot. I can fix http://jira.xwiki.org/jira/browse/XWIKI-3416 by dragging out all the nested anchors right bellow the <body> element so that generated id macros will always land on a newline. But this is ugly and will not work for many cases. Why do we need the id macro to be on a newline always? Any ideas? Thanks. - Asiri

3 2

Re: [xwiki-devs] [xwiki-notifications] r17898 - platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/officeimporter/internal
by Vincent Massol 23 Mar '09

23 Mar '09

On Mar 23, 2009, at 6:52 AM, asiri (SVN) wrote: > Author: asiri > Date: 2009-03-23 06:52:52 +0100 (Mon, 23 Mar 2009) > New Revision: 17898 > > Modified: > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/OfficeImporterFileStorageTest.java > Log: > XWIKI-3406: Office Importer not working under windows environments > > * Forgot to cleanup the temporary storage. > > Modified: platform/core/trunk/xwiki-officeimporter/src/test/java/org/ > xwiki/officeimporter/internal/OfficeImporterFileStorageTest.java > =================================================================== > --- platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/OfficeImporterFileStorageTest.java > 2009-03-23 05:50:34 UTC (rev 17897) > +++ platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/OfficeImporterFileStorageTest.java > 2009-03-23 05:52:52 UTC (rev 17898) > @@ -45,5 +45,6 @@ > { > OfficeImporterFileStorage storage = new > OfficeImporterFileStorage("Temp/\\:*?\"<>|Dir"); > assertEquals("Temp---------Dir", > storage.getTempDir().getName()); > + storage.cleanUp(); There's no guarantee that this will be called. Imagine if there's an exception for example. You should do cleaning in tearDown(). Shouldn't it be the code under test that should do the cleaning in this case? Thanks -Vincent

2 1

Re: [xwiki-devs] [xwiki-notifications] r17880 - in platform/web/trunk: . wysiwyg wysiwyg/src/main/java wysiwyg/src/test/java wysiwyg/src/test/java/com/xpn/xwiki/wysiwyg/client/widget xwiki-gwt-dom xwiki-gwt-dom/src xwiki-gwt-dom/src/main xwiki-gwt-dom/src/main/java xwiki-gwt-dom/src/main/java/org xwiki-gwt-dom/src/test xwiki-gwt-dom/src/test/java xwiki-gwt-dom/src/test/java/org xwiki-gwt-dom/src/test/java/org/xwiki/gwt/dom/client
by Vincent Massol 23 Mar '09

23 Mar '09

On Mar 23, 2009, at 8:49 AM, Marius Dumitru Florea wrote: > Hi Anca, > > Anca Paula Luca wrote: >> mflorea (SVN) wrote: >>> Author: mflorea >>> Date: 2009-03-20 19:48:20 +0100 (Fri, 20 Mar 2009) >>> New Revision: 17880 >>> >>> Added: >>> platform/web/trunk/wysiwyg/src/test/java/com/xpn/xwiki/wysiwyg/ >>> client/widget/MockEvent.java >>> platform/web/trunk/xwiki-gwt-dom/ >> >> actually, could we have this just gwt-dom ? for consistency with >> the others >> module names. > > I thought it's consistent with: > http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rendering/xwik… > > I replaced "core" with "web" and "rendering" with "gwt". > >> We could also think about putting it under gwt in this case, but >> the truth is >> that that one should be renamed into xwiki-gwt since that one is >> xwiki specific >> API and this one is generic. > > Yes, I had in mind: platform/web/xwiki-gwt/xwiki-gwt-dom but I said to > myself that we should wait till we have more than one module to put > inside xwiki-gwt. Also note that xwiki-rendering is pretty generic and > still prefixed with xwiki. I think it's good like this. > > I could have moved/renamed the gwt module to > platform/web/xwiki-gwt/xwiki-gwt-api but I wanted to know first how is > this move going to affect the projects using it, like Curriki. > > My target is something like: > > platform/web/xwiki-gwt > /xwiki-gwt-api (the current gwt module) > /xwiki-gwt-diff (used for real-time editing) > /xwiki-gwt-dom > /xwiki-gwt-rta (the rich text area used by the WYSIWYG) > /xwiki-gwt-wysiwyg Sounds good to me as a first step. The following step would be to move some modules to top level project status. Thanks -Vincent

1 0

[xwiki-devs] Authentication and SavedRequestRestorerFilter
by Denis Gervalle 23 Mar '09

23 Mar '09

Hi all and Sergiu in particular, I need a more flexible as well as new kind of authentication for my xwiki farm, I have therefore started a review of the current implementations (which is not really nice), as well as patch proposal (stackable auth and iopen)... I am currently puzzled by the introduction of the SavedRequestRestorerFilter in 10525 (1.5M2). When I apply the selenium test case provided on earlier version (1.4.1), I do not found any issue, and I there wonder what is the use case of this fix ? It seems to me useless in regards to the current state of the authentication code. I have also remove it from my test build, and I see no regression. Does anyone have a test case that shows the usefulness of this ? TIA. Denis

2 4

Re: [xwiki-devs] [xwiki-notifications] r17895 - in platform/core/trunk/xwiki-officeimporter/src: main/java/org/xwiki/officeimporter/internal test/java/org/xwiki/officeimporter/internal
by Vincent Massol 23 Mar '09

23 Mar '09

On Mar 22, 2009, at 10:54 AM, asiri (SVN) wrote: > Author: asiri > Date: 2009-03-22 10:54:52 +0100 (Sun, 22 Mar 2009) > New Revision: 17895 > > Added: > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/OfficeImporterFileStorageTest.java > Modified: > platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/internal/OfficeImporterFileStorage.java > Log: > XWIKI-3406: Office Importer not working under windows environments > > * Fixed the problem with invalid file name characters. > > Modified: platform/core/trunk/xwiki-officeimporter/src/main/java/org/ > xwiki/officeimporter/internal/OfficeImporterFileStorage.java > =================================================================== > --- platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/internal/OfficeImporterFileStorage.java 2009-03-22 > 07:16:13 UTC (rev 17894) > +++ platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/internal/OfficeImporterFileStorage.java 2009-03-22 > 09:54:52 UTC (rev 17895) > @@ -50,13 +50,18 @@ > private File outputFile = null; > > /** > + * A regular expression matching any invalid file name character. I think this comment should be improved as these characters are not invalid on all OSes AFAIK. > + */ > + public static final String INVALID_FILE_NAME_CHARS = "[/\\\\:\\* > \\?\"<>|]"; > + > + /** > * Default constructor. > * > * @param tempDirName name of the temporary files directory. > */ > public OfficeImporterFileStorage(String tempDirName) > { > - tempDir = new File(System.getProperty("java.io.tmpdir"), > tempDirName); > + tempDir = new File(System.getProperty("java.io.tmpdir"), > tempDirName.replaceAll(INVALID_FILE_NAME_CHARS, "-")); > tempDir.mkdir(); hmm, shouldn't you ensure these files are deleted on jvm exit? (using deleteOnExit()) Also note that all temporary files should be created through a common generic xwiki api. This has been discussed last week on the xwiki dev list I think. We were wondering where to put it and ApplicationContext was discussed. Using java.io.tmpdir is not completely correct in a servlet environment for ex... > > inputFile = new File(tempDir, "input.tmp"); > outputDir = new File(tempDir, "output"); > > Added: platform/core/trunk/xwiki-officeimporter/src/test/java/org/ > xwiki/officeimporter/internal/OfficeImporterFileStorageTest.java > =================================================================== > --- platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/ > OfficeImporterFileStorageTest.java (rev 0) > +++ platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/OfficeImporterFileStorageTest.java > 2009-03-22 09:54:52 UTC (rev 17895) > @@ -0,0 +1,58 @@ > +/* > + * See the NOTICE file distributed with this work for additional > + * information regarding copyright ownership. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This software is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this software; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > + */ > +package org.xwiki.officeimporter.internal; > + > +import com.xpn.xwiki.test.AbstractXWikiComponentTestCase; > + > +/** > + * Test calss for {@link OfficeImporterFileStorage}. typo. > + * > + * @version $Id$ > + * @since 1.9M1 > + */ > +public class OfficeImporterFileStorageTest extends > AbstractXWikiComponentTestCase > +{ > + /** > + * {@inheritDoc} > + */ > + protected void setUp() throws Exception > + { > + > getComponentManager > ().registerComponentDescriptor > (MockDocumentAccessBridge.getComponentDescriptor()); > + super.setUp(); > + } > + > + /** > + * Test filtering of invalid file name characters. > + */ > + public void testInvalidFileNameCharacterFiltering() > + { > + String[] invalidCharacters = {"/", "\\", ":", "*", "?", > "\"", "<", ">", "|"}; > + String filePath = "Temp%sDir"; > + OfficeImporterFileStorage storage = null; > + try { > + for (String s : invalidCharacters) { > + storage = new > OfficeImporterFileStorage(String.format(filePath, s)); why not create a single string name containing all chars? > > + assertEquals("Temp-Dir", > storage.getTempDir().getName()); > + } > + } catch (RuntimeException ex) { > + fail(ex.getMessage()); See previous mail on this anti pattern for junit tests. Thanks -Vincent

2 1

[xwiki-devs] [Idea] Automatically attach the javadoc of XWiki APIs to a document in XE
by Jerome Velociter 23 Mar '09

23 Mar '09

Hello devs, I am thinking it would be good to automatically attach the javadoc generated for XWiki apis (XWiki, Document, Context, Utils, etc) + maybe velocity tools (listtool, mathtool, etc.) in a wiki document of XE at build time. We could embed the HTML javadoc in view mode with an iframe (or using getURLContent API), or just link to it with the zipexplorer plugin. I think this would make it easier for developers to find out the documentation for the exact version they are running, and without the need of an Internet connection. Tell me what you think, Jerome.

4 4

Re: [xwiki-devs] [xwiki-notifications] r17894 - in platform/core/trunk/xwiki-officeimporter/src: main/java/org/xwiki/officeimporter/filter test/java/org/xwiki/officeimporter/internal/cleaner
by Vincent Massol 23 Mar '09

23 Mar '09

Hi Asiri, On Mar 22, 2009, at 8:16 AM, asiri (SVN) wrote: > Author: asiri > Date: 2009-03-22 08:16:13 +0100 (Sun, 22 Mar 2009) > New Revision: 17894 > > Modified: > platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/filter/AnchorFilter.java > platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/LinkOpenOfficeCleaningTest.java > Log: > XWIKI-3415: Office Importer fails when importing documents with TOC > (Table Of Contents) structures > > * Fixed. > * But there is still a problem (not a failure) with importing word > documents with TOC structures. That's a different issue. > > Modified: platform/core/trunk/xwiki-officeimporter/src/main/java/org/ > xwiki/officeimporter/filter/AnchorFilter.java > =================================================================== > --- platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/filter/AnchorFilter.java 2009-03-21 22:20:38 UTC (rev > 17893) > +++ platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/ > officeimporter/filter/AnchorFilter.java 2009-03-22 07:16:13 UTC (rev > 17894) > @@ -61,7 +61,7 @@ > Node heading = link.getParentNode(); > Node paragraph = (heading != null) ? > heading.getPreviousSibling() : null; > Node originalAnchor = > - (paragraph != null) ? ((Element) > paragraph).getElementsByTagName(TAG_A).item(0) : null; > + (paragraph instanceof Element) ? ((Element) > paragraph).getElementsByTagName(TAG_A).item(0) : null; > if (isSameAnchor(link, originalAnchor)) { > // Means this anchor was a result of close- > before-copy-inside operation of default html cleaner. > anchorsToRemove.add(link); > > Modified: platform/core/trunk/xwiki-officeimporter/src/test/java/org/ > xwiki/officeimporter/internal/cleaner/LinkOpenOfficeCleaningTest.java > =================================================================== > --- platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/LinkOpenOfficeCleaningTest.java > 2009-03-21 22:20:38 UTC (rev 17893) > +++ platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/ > officeimporter/internal/cleaner/LinkOpenOfficeCleaningTest.java > 2009-03-22 07:16:13 UTC (rev 17894) > @@ -72,6 +72,21 @@ > } > > /** > + * Test duplicate anchor filtering with TOC structures. see: http://jira.xwiki.org/jira/browse/XWIKI-3415 > + */ > + public void testAnchorFilteringWithTOC() > + { > + String html = header + "<div>some text<h1><a name= > \"Topic1\"/>Topic1</h1></div>" + footer; > + try { > + Document doc = openOfficeHTMLCleaner.clean(new > StringReader(html)); > + NodeList nodes = doc.getElementsByTagName("a"); > + assertEquals(1, nodes.getLength()); > + } catch (ClassCastException ex) { > + fail(ex.getMessage()); > + } > + } The best practice is never to catch an exception unless the test is about testing for exeption use cases. So you should instead have testAnchor*() throws Exception {...} and don't put put the try/catch. see http://junit.sourceforge.net/doc/faq/faq.htm#tests_8 for example. Thanks -Vincent

2 1

[xwiki-devs] GSOC 2009 project "Content Fetching for XWiki Watch"
by usw wickramasinghe 22 Mar '09

22 Mar '09

Hi devs , I'm a Computer Science undergraduate Student wiling to undergo a project for GSoc 09 under Xwiki . I've contacted this list before and would like to undergo 'Improved content fetching mechanism for XWiki Watch' XWiki project for Gsoc 09 . I would really like to know some more detail regarding the scope and requirement for this project before submitting my proposal. Really appreciate some feedback on above aspects n thnx in advance.. Regards Udayanga

2 2