xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] WYSIWYG editor loading time

by Marius Dumitru Florea

Hi devs, I noticed today that the time spent by Hudson to run all the WYSIWYG selenium tests (274) has increased from 19 to 22 minutes although the number of tests didn't change much from XE 2.4 and neither the tests' code. I wanted to know if this was caused by an increased WYSIWYG editor loading time so I did a quick profiling using Firefox 3.6.10 and Firebug 1.5.4. The WYSIWYG editor loading time (alone, excluding other artifacts on the host page) has three components: (T1) time to interpret the WYSIWYG editor JavaScript code (~530KB) (T2) time to load the edited document in the in-line frame (T3) time to load the editor plugins and to initialize the UI (menu, tool bar) It seems that (T3) is: * XE 2.4 -> 219.128ms, 26753 calls * XE 2.5 -> 242.968ms, 28282 calls Next I checked with Firebug's Net tab the page loading time. In order to test the editor alone I created a simple velocity template (wysiwyg.vm) that includes only the editor (plus the JavaScript and stylesheets needed by the editor). XE 2.4 ------ 4.35s -> WYSIWYG edit mode with SmartClient 2.47s -> WYSIWYG edit mode without SmartClient 3.4s -> xpage=wysiwyg with SmartClient 1.7s -> xpage=wysiwyg without SmartClient XE 2.5 ------ 3.9s -> WYSIWYG edit mode with SmartClient 2s -> WYSIWYG edit mode without SmartClient 3.2s -> xpage=wysiwyg with SmartClient 1.3s -> xpage=wysiwyg without SmartClient So the overall page loading time in edit mode has decreased. Also note that SmartClient adds a lot of time and it is used only for the XWiki Explorer tree.. This means the increased time spent on WYSIWYG selenium tests is caused by something else. Thanks, Marius

14 years, 3 months

[xwiki-devs] [VOTE] Stop supporting the Albatross skin

by Sergiu Dumitriu

Hi devs, I'd like to propose that we don't maintain the Albatross skin anymore, since it's time consuming to port all the UI improvements and fixes to it. The skin will not be removed from the distribution yet, since it's still the base skin on which Toucan and Colibri are built, although we should try to fix this dependency in the near future. -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 3 months

[xwiki-devs] Create a trunks for enterprise/ in SVN

by Vincent Massol

Hi devs, I'd like to create svn externals for enterprise in enterprise/trunks that would build both platform and enterprise. I would put a pom.xml in trunks for doing that. The need is to have a single maven multi module project to run Clover on (otherwise it's more complex for setting up Clover). WDYT? Thanks -Vincent

14 years, 3 months

Re: [xwiki-devs] [xwiki-notifications] r31913 - platform/xwiki-applications/trunk/administration

by Vincent Massol

Hi Sergiu, On Oct 17, 2010, at 3:33 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-10-17 03:33:22 +0200 (Sun, 17 Oct 2010) > New Revision: 31913 > > Modified: > platform/xwiki-applications/trunk/administration/pom.xml > Log: > [misc] New version number > > Modified: platform/xwiki-applications/trunk/administration/pom.xml > =================================================================== > --- platform/xwiki-applications/trunk/administration/pom.xml 2010-10-17 01:10:40 UTC (rev 31912) > +++ platform/xwiki-applications/trunk/administration/pom.xml 2010-10-17 01:33:22 UTC (rev 31913) > @@ -31,7 +31,7 @@ > </parent> > <artifactId>xwiki-application-administration</artifactId> > <name>XWiki Platform - Applications - Administration</name> > - <version>1.42-SNAPSHOT</version> > + <version>2.0-SNAPSHOT</version> Why are we doing this? Did we agree about a strategy? I'm worried about aligning versions for all apps in case we decided something. Thanks -Vincent > <packaging>xar</packaging> > <description>Application for administrating wiki features like users, groups, rights etc.</description> > <!-- We must configure SCM in each module. For more information see:

14 years, 3 months

[xwiki-devs] Remove com.xpn.xwiki.test.smtp package

by Vincent Massol

Hi, I'd like to remove this package which doesn't seem to be used and is something used for testing and thus has nothing to do in src/main/java. In addition for tests we now use Greenmail. Please let me know if you think this is used somewhere and I've missed it. Thanks -Vincent

14 years, 3 months

[xwiki-devs] [Proposal][UX] Administration with vertical tabs

by Ecaterina Valica

This is a proposal for a new Administration UI having vertical tabs for grouping instead of the current select input. Proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Administration Category: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Administration… Section: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Administration… The vertical tab could be also integrated into the User Profile: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Administration#pro… This proposal is made using CSS3 rules. The degradation of the tabs: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Administration… Thanks, Caty

14 years, 3 months

[xwiki-devs] [Announcement] XWiki Enterprise 2.5 Release Candidate 1 Released

by Sergiu Dumitriu

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.5 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Main changes since XWiki Enterprise 2.5 Milestone 2: * New macros for the Space List and Tag Cloud * Display user avatars in annotations * A few improvements to the Extension Manager * A few improvements to the User Directory * WYSIWYG and Rendering improvements * A few security and performance improvements For more information see the Release notes at http://www.xwiki.org/xwiki/bin/Main/ReleaseNotesXWikiEnterprise25RC1 Thanks -The XWiki dev team

14 years, 3 months

[xwiki-devs] [proposal] Add public void setContent(InputStream is) throws IOException to c.x.x.doc.XWikiAttachment.

by Caleb James DeLisle

This is just a small API change proposal. Since my implementation changes for XWikiAttachment store the attachment content in a temp file rather than a byte array, there is no need to require the user to provide the length of the provided stream and in many cases (upload for instance) this number is very difficult to determine in advance. I propose we add: public void setContent(InputStream is) throws IOException In addition to the existing: public void setContent(InputStream is, int length) throws IOException WDYT? Caleb

14 years, 3 months

[xwiki-devs] [discussion] The future of attachments and attachment versioning.

by Caleb James DeLisle

Hi, I have some changes to the attachment system which will allow XWiki to handle much larger attachments without memory exhaustion. I have found that there are some places where I cannot make any changes because the code is not in XWiki but rather in JRCS. XWiki versions attachments by creating a JRCS node for the XML version of each version of each attachment. This means that memory consumption improvements hit a hard wall at 2 * 2 * 1.3 * the size of the attachment. base-64 encoding for XML increases the size by 1.3 times, storage as a String (array of 16 bit chars) doubles the size and the need to copy the String doubles the size again. The second issue is that the database and JDBC do not handle multiple hundreds of megabytes in a single query well. If I try to attach a 500MB attachment with attachment versioning disabled, my changes allow the attachment to be streamed to the database but postgresql is not able to save it. I am able to attach a 256MB attachment but with 512MB of heap space, the attachment cannot be loaded from the database because JDBC lacks the necessary streaming functionality. An option which I am now considering is adding a binary table to the database schema. The table would contain a composite id made of the id of the data and the part number of that entry, and a data column slightly smaller than 1MB (default max_allowed_packet in mysql). All interaction with this table would go through a storage engine which would require InputStreams and OutputStreams and the streams would be written and read by the storage mechanism which would ID tag them and break them up into parts to be sent to the database individually. WDYT? Caleb

14 years, 3 months

[xwiki-devs] [VOTE] Better release strategy

by Sergiu Dumitriu

Hi devs, I don't think that Monday is a good day for releases, since voting over the weekend is not a good thing. Thus, I propose to move the general release day to the Thursday of the week. The current release process doesn't really follow the VOTE rules, since the way it's done is: send vote mail at 10AM, wait a few hours, start the release around 1PM. The rule for VOTE emails is to wait for three days. Thus: - Send release VOTE on Monday - Prepare the release during the following three days (release plan, release notes) - Perform the maven release on Thursday, request tests for publishing the release (testing of the build) - Finalize the release on Friday (download, announcements, version update) -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 3 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