xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Vote] Should the RSS macro extend the Box macro instead of just using it internally?

by Dan Miron

Hi guys! I'd like to know what you think about this matter, which has been raised on http://jira.xwiki.org/jira/browse/XWIKI-3375. As I posted there, this is what I think: -the parameters for the two macros are completely different, so i see no point for having the box specific parameters (cssClass, title, image, width and blockTitle) among the rss macro's ones, this will lead to confusion for the user. The box parameters are deduced from the rss feed's properties and then passed to the box macro. No need for them to be exposed in the Rss Macro. Therefore, extending the RssMacroParameters from the BoxMacroParameters is unreliable. -extending the RssMacro from the AbstractBoxMacro<RssMacroParameters> doesn't mean simply implementing AbstractBoxMacro.parseContent instead of Macro.execute. Currently, most of the code about the box around the css macro is placed in the box macro's implementation, which is DefaultBoxMacro, so we do make use of the existing implementations. Giving up using the box macro internally means giving up using most of the features already presented in the box macro and rewriting them -and finally, the most time costing disadvantage is that extending the rss macro from the box basically means rewriting this macro from scratch, because it involves redesigning it, task that will cost us time. So, therefore, I'm -1 for this. Tnx, Dan

15 years, 10 months

Re: [xwiki-devs] XWikiException Unable to build interceptor chain

by Cristi

Hello, I had the same problem. I have 2 PCs: the first one with a JRE 5 and the all-in-one installer exe bundle worked perfectly. PC no. 2, JDK 5, Tomcat 5.5 and Postgres using the war file - not OK, I had this problem. My resolution to this problem: I have upgraded my JDK to 6, and I don't have the problem any more. This is curious as I compared the dirs & files from the 2 distributions and they were identical. So I didn't have to download this file: jcip-annotations-1.0.jar. I am guessing that the system tries to look for that file only in some cases, and if jdk 6 is installed, it doesn't need this lib any more. Best regards, CS. -- View this message in context: http://n2.nabble.com/XWikiException-Unable-to-build-interceptor-chain-tp131… Sent from the XWiki- Dev mailing list archive at Nabble.com.

15 years, 10 months

[xwiki-devs] [GSoc 2009] Question regarding Anti Vandalism Filters project

by Anamaria Stoica

Hi, Just to quickly introduce myself. My name is Anamaria Stoica, and I'm studying Computer Science at University "Politehnica" of Bucharest. I'm currently in the 5th year. (graduation year) I have a 2 year experience working with Java SE & EE on the ITerating.com platform (http://www.iterating.com) (also with JS, AJAX, HTML&CSS). The team (less than 10 members) was spread out in several countries (but mostly in Romania) and worked remotely. My working experience also includes a summer internship (in 2008) at Cresta Technology, Inc. (http://www.crestatech.com) in Santa Clara, CA. There I worked as a Software Engineer Intern. Regarding the "Anti Vandalism Filters" project, before today it had as a developer requirement Machine Learning knowledge. I loved the idea of the project since the first time I saw it, not only because of the Machine Learning component in which I have recently developed a lot of interest, but also of the project as a whole. So, my question is: does the project still imply some work on ML Algorithms, just that it isn't a strong requirement as before or has that change ? Also, will the project use some other components already developed towards this end ? Thanks in advance, Anamaria

15 years, 10 months

[xwiki-devs] [PROPOSAL] Add a setParent() method to DocumentAccessBridge / DocumentModelBridge

by Asiri Rathnayake

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

15 years, 10 months

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

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();

15 years, 10 months

[xwiki-devs] Why can't we use the id macro inside a heading, table cell etc. ?

by Asiri Rathnayake

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

15 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r17898 - platform/core/trunk/xwiki-officeimporter/src/test/java/org/xwiki/officeimporter/internal

by Vincent Massol

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

15 years, 10 months

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

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

15 years, 10 months

[xwiki-devs] Authentication and SavedRequestRestorerFilter

by Denis Gervalle

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

15 years, 10 months

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

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

15 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs