xwiki-devs September 2009

xwiki-devs@xwiki.org

44 participants
135 discussions

[xwiki-devs] [VOTE] Remove the Search & Create Page panels from the right column in the default XAR

by Guillaume Lerouge

Hi Devs, Right now the Colibri skin introduces 2 new components (among others): - a search box in the header - a "create" menu entry in the top action bar that allows user to create new pages / spaces Those 2 new features duplicate the Create Page & the Search panel and thus make those panels irrelevant in the default distrib. I'd like to send a vote on removing those 2 panels from the right column in the default XAR & updating the release notes accordingly (so that toucan & albatross users know how to get them back easily). Here's my +1 to remove both panels from the right column in the default XAR. Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

15 years, 3 months

by Vincent Massol

On Sep 22, 2009, at 3:57 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-22 15:57:53 +0200 (Tue, 22 Sep 2009) > New Revision: 23822 > > Modified: > platform/xwiki-applications/trunk/application-manager/pom.xml > platform/xwiki-applications/trunk/calendar/pom.xml > platform/xwiki-applications/trunk/ircbot/pom.xml > platform/xwiki-applications/trunk/photoalbum/pom.xml > platform/xwiki-applications/trunk/scheduler/pom.xml > platform/xwiki-applications/trunk/selenium/pom.xml > platform/xwiki-applications/trunk/statistics/pom.xml > platform/xwiki-applications/trunk/tag/pom.xml > platform/xwiki-applications/trunk/watchlist/pom.xml > platform/xwiki-applications/trunk/webdav/pom.xml > platform/xwiki-applications/trunk/wiki-macro-bridge/pom.xml > platform/xwiki-applications/trunk/wiki-manager/pom.xml > platform/xwiki-applications/trunk/workstream/pom.xml > platform/xwiki-plugins/trunk/activitystream/pom.xml > platform/xwiki-plugins/trunk/adwords/pom.xml > platform/xwiki-plugins/trunk/alexa/pom.xml > platform/xwiki-plugins/trunk/application-manager/pom.xml > platform/xwiki-plugins/trunk/calendar/pom.xml > platform/xwiki-plugins/trunk/exoplatform/pom.xml > platform/xwiki-plugins/trunk/invitationmanager/pom.xml > platform/xwiki-plugins/trunk/jodatime/pom.xml > platform/xwiki-plugins/trunk/lucene/pom.xml > platform/xwiki-plugins/trunk/mailsender/pom.xml > platform/xwiki-plugins/trunk/scheduler/pom.xml > platform/xwiki-plugins/trunk/skinx/pom.xml > platform/xwiki-plugins/trunk/spacemanager/pom.xml > platform/xwiki-plugins/trunk/swizzle/pom.xml > platform/xwiki-plugins/trunk/tag/pom.xml > platform/xwiki-plugins/trunk/watchlist/pom.xml > platform/xwiki-plugins/trunk/wiki-manager/pom.xml > platform/xwiki-plugins/trunk/xml/pom.xml > Log: > Add jira url thanks, I was too lazy to finish... ;) -Vincent

15 years, 3 months

Re: [xwiki-devs] [xwiki-notifications] r23810 - enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium

by Vincent Massol

On Sep 22, 2009, at 2:39 PM, mflorea (SVN) wrote: > Author: mflorea > Date: 2009-09-22 14:39:37 +0200 (Tue, 22 Sep 2009) > New Revision: 23810 > > Modified: > enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/LineTest.java > enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/NativeJavaScriptApiTest.java > enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/StandardFeaturesTest.java > Log: > Fixed some of the WYSIWYG failing tests > * Replaced 'y' with 'Y' to overcome a Selenium bug that > misinterprets 'y' as 'alt' key when typing. This must be well documented in the code below. Thanks -Vincent > * The bogus BR tag is not deleted anymore in FF3.5 when pressing the > Delete key so we must add it when asserting HTML. > > > Modified: enterprise/trunk/distribution-test/wysiwyg-tests/src/test/ > it/com/xpn/xwiki/it/selenium/LineTest.java > =================================================================== > --- enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/LineTest.java 2009-09-22 12:09:21 UTC (rev > 23809) > +++ enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/LineTest.java 2009-09-22 12:39:37 UTC (rev > 23810) > @@ -252,11 +252,10 @@ > // thus we are forced to collapse the selection to the end. > runScript("XWE.selection.collapseToEnd()"); > typeEnter(); > - typeText("xyz"); > - typeDelete(); > + typeText("xYz"); > assertXHTML("" > + "<img src=\"/xwiki/bin/download/XWiki/AdminSheet/ > photos.png\" alt=\"photos.png\">" > - + "xyz"); > + + "xYz "); > } > > /** > > Modified: enterprise/trunk/distribution-test/wysiwyg-tests/src/test/ > it/com/xpn/xwiki/it/selenium/NativeJavaScriptApiTest.java > =================================================================== > --- enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/NativeJavaScriptApiTest.java 2009-09-22 > 12:09:21 UTC (rev 23809) > +++ enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/NativeJavaScriptApiTest.java 2009-09-22 > 12:39:37 UTC (rev 23810) > @@ -123,7 +123,7 @@ > typeText("x"); > assertEquals("x", getSourceText("editor")); > > - typeText("y"); > + typeText("Y"); > clickButtonWithText("Load Editor"); > waitForCondition("typeof window.editor == 'object'"); > focusRichTextArea(); > > Modified: enterprise/trunk/distribution-test/wysiwyg-tests/src/test/ > it/com/xpn/xwiki/it/selenium/StandardFeaturesTest.java > =================================================================== > --- enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/StandardFeaturesTest.java 2009-09-22 12:09:21 > UTC (rev 23809) > +++ enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/StandardFeaturesTest.java 2009-09-22 12:39:37 > UTC (rev 23810) > @@ -257,15 +257,15 @@ > { > typeText("x"); > typeShiftEnter(); > - typeText("y"); > + typeText("Y"); > selectAllContent(); > clickUnorderedListButton(); > // Since the left arrow key doesn't move the caret we have > to use the Range API instead. > moveCaret("XWE.body.firstChild.childNodes[1].firstChild", 0); > typeTab(); > - assertXHTML("<ul><li>x<ul><li>y</li></ul></li></ul>"); > + assertXHTML("<ul><li>x<ul><li>Y</li></ul></li></ul>"); > typeShiftTab(); > - assertXHTML("<ul><li>x</li><li>y</li></ul>"); > + assertXHTML("<ul><li>x</li><li>Y</li></ul>"); > } > > /** > @@ -414,7 +414,7 @@ > */ > public void testInsertHRInsideParagraph() > { > - typeText("xy"); > + typeText("xY"); > applyStyleTitle1(); > applyStylePlainText(); > > @@ -435,7 +435,7 @@ > > // We have to assert the XHTML because the arrow keys don't > move the caret so we can't test if the user can edit > // the generated empty paragraphs. The fact that they > contain a BR proves this. > - assertXHTML(" <hr>x</ > p><hr>y<hr> "); > + assertXHTML(" <hr>x</ > p><hr>Y<hr> "); > } > > /**

15 years, 3 months

[xwiki-devs] [VOTE] Change group id for skins from com.xpn to xwiki.org

by Vincent Massol

Hi, Vote: change com.xpn.xwiki.platform.skins to org.xwiki.platform.skins To be done on trunk (2.1) Here's my +1 Thanks -Vincent

15 years, 3 months

[xwiki-devs] [VOTE] Change group id for applications from com.xpn to xwiki.org

by Vincent Massol

Hi, Vote: change com.xpn.xwiki.platform.applications to org.xwiki.platform.applications To be done on trunk (2.1) Here's my +1 Thanks -Vincent

15 years, 3 months

[xwiki-devs] Faster loadXWikiDoc method, preliminary data, 850 - 1000% speed increase.

by Caleb James DeLisle

My loader is able to load every page in my copy of XE and they all pass the .equals( test against the same page loaded by the default loader so I feel that I'm ready to publish some tests. These are time results (in milliseconds) for loading a page containing 1000 comments. see: http://jira.xwiki.org/jira/browse/XWIKI-2874 My test script runs the tests 30 times interchanging old loader and new. These tests were all the first call to a newly started server, you can see it speed up as the code is jit compiled. Conclusion: 850% improvment can be expected for loading a page with 1000 comments. StringListProperty and LargeStringProperty being mapped to the same column costs about 100ms for the workaround, disabling this workaround brings it to an even 1000% speed increase. Disabling custom mapping saves a whopping 8ms. This surprised me. My loader is only marginally faster at loading all of the pages in XE, it is best at scaling with lots of objects. This didn't surprise me. The actual test results are below. Caleb James DeLisle test1: no special optimizations. Old loader ===================== New Loader 11835ms. ===================== 2875ms. 7776ms. ===================== 771ms. 6827ms. ===================== 684ms. 6652ms. ===================== 405ms. 4406ms. ===================== 348ms. 3790ms. ===================== 363ms. 3482ms. ===================== 288ms. 3431ms. ===================== 965ms. 3173ms. ===================== 295ms. 3029ms. ===================== 271ms. 3714ms. ===================== 278ms. 3017ms. ===================== 285ms. 3828ms. ===================== 271ms. 2907ms. ===================== 285ms. 2845ms. ===================== 258ms. 2884ms. ===================== 275ms. 2829ms. ===================== 276ms. 2871ms. ===================== 256ms. 3638ms. ===================== 285ms. 2797ms. ===================== 295ms. old loader's average: 4284.6ms. new loader's average: 501.4ms. test2: this is with the LargeString/StringList workaround disabled. Old loader ===================== New Loader 11494ms. ===================== 1541ms. 8916ms. ===================== 902ms. 7209ms. ===================== 639ms. 5584ms. ===================== 365ms. 4649ms. ===================== 324ms. 3700ms. ===================== 275ms. 3454ms. ===================== 282ms. 3391ms. ===================== 258ms. 3875ms. ===================== 260ms. 3087ms. ===================== 260ms. 3714ms. ===================== 342ms. 3012ms. ===================== 279ms. 3045ms. ===================== 1109ms. 3012ms. ===================== 242ms. 2873ms. ===================== 244ms. 2863ms. ===================== 247ms. 2880ms. ===================== 257ms. 2842ms. ===================== 276ms. 3667ms. ===================== 255ms. 2881ms. ===================== 259ms. old loader's average: 4305.3ms. new loader's average: 430.8ms. test3: LargeString/StringList workaround & custom mapping disabled. Old loader ===================== New Loader 11813ms. ===================== 1465ms. 7984ms. ===================== 853ms. 6819ms. ===================== 602ms. 6182ms. ===================== 373ms. 4609ms. ===================== 320ms. 3749ms. ===================== 280ms. 3484ms. ===================== 309ms. 3348ms. ===================== 269ms. 3797ms. ===================== 263ms. 3119ms. ===================== 257ms. 3733ms. ===================== 327ms. 3044ms. ===================== 274ms. 2985ms. ===================== 1086ms. 2864ms. ===================== 239ms. 2888ms. ===================== 265ms. 2854ms. ===================== 262ms. 2836ms. ===================== 264ms. 2835ms. ===================== 269ms. 3653ms. ===================== 241ms. 2843ms. ===================== 247ms. old loader's average: 4269.8ms. new loader's average: 423.2ms.

15 years, 3 months

[xwiki-devs] Rendering Groovy Script in Objects

by Andreas Schaefer

I am investigation the possibility to write Panels in Groovy. Unfortunately I am not able to figure out: - if I XWiki would render Groovy script code by itself and if how ? - If not can I render a Groovy script form another Groovy script ? BTW I was stuck for a while when trying to create my own BlogPostTemplate because XWiki would not allow me to run it as Groovy script even if I gave myself programming rights. But when I wrote the BlogPostSheet as Groovy class and loaded it inside the Velocity script of the BlogPostTemplate it worked perfectly. Now I am wondering why I could not execute the Groovy script if I can circumvent this restriction so easily. Cheers - Andy

15 years, 3 months

[xwiki-devs] Something to be aware of when using velocity macro and wiki syntax mixed

by Vincent Massol

Hi everyone, Example: ----- %> cut here -------- ... something #end ## some comment {{warning..../}} ----- %> cut here -------- Quizz: Will the macro be inline or standalone? Answer: inline Reason is that velocity will start by removing the comment, which will leave a whitespace after the #end Thus you'll get: something + NL + (space) + NL + warning macro Thus since there are no 2 NLs before the macro it's going to be inline! Thanks -Vincent

15 years, 3 months

[xwiki-devs] [VOTE] Move web/exo module in sandbox

by Vincent Massol

Since we're not maintaining it and can't guarantee it's quality and since nobody is working on it today. We can put it back when it's updated and working fine. Note: even if we put it back it should be done differently and not as part of platform IMO. Probably an end product. Here's my +1 Thanks -Vincent

15 years, 3 months

[xwiki-devs] [Proposal] Reorganize XWiki Core JIRA components reflecting core/web modules (Take 2)

by Vincent Massol

Hi, Following our previous discussion (see http://markmail.org/thread/5lsaq274tvczr5wd) , I'd like to move this forward. Here's what I propose now: 1) We create a new "XWiki Core" (key: XCORE) jira project which is where we put the new components and where we invite everyone to create new core issues. * In this new jira project we use the rule of one jira component per module, whatever the size of the module. ** For example for the rendering module (which is our largest module right now) this means one jira component only. In order to make it easy for users we should name it with something like "Rendering (wiki syntaxes, macros, ...)" ** Users will simply need to explain what it's about in the issue title. For example instead of having a "Rendering - Macro - RSS" component the issue will be named "Add blahblah feature to the RSS macro" ** Having lots of modules might look better but I think 1) having too many components make it hard for end users to find the right one and 2) I don't see real needs for them. Do you see any? 2) We keep the existing "XWiki Core" (key: XWIKI) jira project but: ** we change its permissions so that no new issues can be created in it ** we change its name to "XWiki Core - Old" ** we change its description to tell people to use the other one with a link to it ** we add a welcome message in the default dashboard to explain the change and point people to the new jira project. ** we slowly move whatever issues we can from it to the new project. For example we can easily move all Rendering 2.0 issues or all GWT WYSIWYG issues. For the rest we can move other time whenever we encounter an issue that should go in the new jira project 3) We change our existing jira filters so that they include both XCORE and XWIKI jira projects. WDYT? If we agree, I can start doing this. Thanks -Vincent

15 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2009