xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [VOTE] Remove existing deprecated ColorThemes and replaced them with new ones for XE 3.4

by Ecaterina Moraru (Valica)

Hi devs, Since the recent Skin/ColorThemes changes done for XE 3.4, the existing ColorThemes are deprecated. I propose to remove them from our standard distribution and replace them with some themes created specially for the new skin changes. You can see these 3 new colorthemes (Ruby, Dusk, Mint) at: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/34NewColorThemes (clicking on the preview image you can see them in action) obs. I created a ColorTheme for every color we have in XWiki logo (blue, orange, red, green) The deprecated ColorThemes will still be available in the extensions repository: Default http://extensions.xwiki.org/xwiki/bin/view/Extension/Default33+ColorTheme Bordo http://extensions.xwiki.org/xwiki/bin/view/Extension/Bordo+ColorTheme Nature http://extensions.xwiki.org/xwiki/bin/view/Extension/Nature+ColorTheme BlueSky http://extensions.xwiki.org/xwiki/bin/view/Extension/BlueSky+ColorTheme Inner Dark http://extensions.xwiki.org/xwiki/bin/view/Extension/Inner+Dark+ColorTheme Nightfall http://extensions.xwiki.org/xwiki/bin/view/Extension/Nightfall+ColorTheme Peach http://extensions.xwiki.org/xwiki/bin/view/Extension/Peach+ColorTheme This is my +1 Pull request at https://github.com/xwiki/xwiki-enterprise/pull/14 waiting for the vote result and will be committed for 3.4 RC1. Thanks, Caty

13 years

[xwiki-devs] [VOTE] Change document id stored in the database to reduce the likelihood of duplicate id

by Denis Gervalle

Now that the database migration mechanism has been improved, I would like to go ahead with my patch to improve document ids. Currently, ids are simple string hashcode of a locally serialized document reference, including the language for translated documents. The likelihood of having duplicates with the string hashing algorithm of java is really high. What I propose is: 1) use an MD5 hashing which is particularly good at distributing. 2) truncate the hash to the first 64bits, since the XWD_ID column is a 64bit long. 3) use a better string representation as the source of hashing Based on previous discussion, point 1) and 2) has already been agreed, and this vote is in particular about the string used for 3). I propose it in 2 steps: 1) before locale are fully supported in document reference, use this format: <lengthOfLastSpaceName>:<lastSpaceName><lengthOfDocumentName>:<documentName><lengthOfLanguage>:<language> where language would be an empty string for the default document, so it would look like 7:mySpace5:myDoc0: and its french translation could be 7:mySpace5:myDoc2:fr 2) when locale are included in reference, we will replace the implementation by a reference serializer that would produce the same kind of representation, but that will include all spaces (not only the last one), to be prepared for the future. While doing so, I also propose to fix the cache key issue by using the same reference, but prefixed by <lengthOfWikiName>:<wikiName>, so the previous examples will have the following key in the document cache: 5:xwiki7:mySpace5:myDoc0: and 5:xwiki7:mySpace5:myDoc2:fr Using such a key (compared to the usual serialization) has the following advantages: - ensure uniqueness of the reference without requiring a complex escaping algorithm, which is unneeded here. - potentially reversible - faster than the usual serialization - support language - independent of the current serialization that may evolved independently, so it will be stable over time which is really important when it is used as a base for the hashing algorithm used for document ids stored in the database. I would like to introduce this as early as possible, which means has soon has we are confident with the migration mechanism recently introduced. Since the migration of ids will convert 32bits hashes into 64bits ones, the risk of collision is really low, and to be careful, I have written a migration algorithm that would support such collision (unless it cause a circular reference collision, but this is really unexpected). However, changing ids again later, if we change our mind, will be really more risky and the migration difficult to implements, so it is really important that we agree on the way we compute these ids, once for all. Here is my +1, -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years

[xwiki-devs] [VOTE] New {{display}} macro and changes to the {{include}} macro

by Vincent Massol

Hi devs, As you know in XE 3.0 we've changed the behavior for resolving local links/attachments when they're included using the {{include}} macro (they're now resolved against the included document instead of the including document). Now there might be some use cases (pretty rare IMO but they exist) where you'd want the links to be resolved against the including document. Here's a use case: you have a sheet document that references an image called image.png and you want that the including document provides it (like an Abstract in Java! ;)). So we've brainstormed with Thomas and here's our proposal: * Introduce a new {{display reference="…"/}} macro. This macro will *execute* the passed reference in its own context (it'll do what {{include context="new"…}} was doing before). It'll be located in the new display module. * Deprecate the "context" parameter of the {{include}} macro. The reason is that calling with context=new is not an include, it's a display. * Add a new "resolve" parameter for the {{include}} macro with possible values = "current" | "source", with a default value of "source". resolve=source means that the links/attachments are resolved against the source (ie the document being included). Using resolve=current means that you want the links/attachments resolved against the including document. Pros: * Clearly separate the 2 use cases: display and include * Make the include macro simple (a single "resolve" parameter) * Use the new display module as it should be and start the direction of having displayer macros for displaying all types of entities Note: In the future we'll also want to deprecate the "document" parameter of the include macro in favor of a more generic "reference" parameter, which will allow the macro to include other types of entities (such as an object property for ex). WDYT? Here's my +1 Thanks -Vincent

13 years

[xwiki-devs] CI status before 3.4M1 release

by Marius Dumitru Florea

Hi devs, I'd like to release 3.4M1 tomorrow morning (EET) but there are still failing tests on CI: * xwiki-enterprise-test-extension : ExtensionsAdminPage was not synchronized with the latest changes to the Extension Manager UI. It expects an "Extensions" administration section, which was (I guess) replaced in the mean time with three different administration sections. Sergiu or Thomas should take care of this, otherwise I'll exclude the test. * xwiki-enterprise-test-ui : Sergiu, please update TemplateProviderInlinePage and CreatePageTest due to XWIKI-7358 (Add support for simple space templates). * xwiki-enterprise-test-wysiwyg : A test is failing because when you go to an unexisting page (/bin/view/Space/UnexistingPage) the link to create that page doesn't lead to edit mode but to a strange "create" mode, which has only a button to create the page. Sergiu, I think this is related to XWIKI-7358. Can you take care of it? * there is one App Within Minutes test failing on CI which I can't reproduce locally. I'm taking care of this. Thanks, Marius

13 years

[xwiki-devs] Fwd: Configuring the webhome page of main space?

by mohit gupta

Hi Folks, I would really appreciate even if somebody can provides the pointers about below queries. Thanks and Regards Mohit Gupta ---------- Forwarded message ---------- From: mohit gupta <motgupta(a)gmail.com> Date: Thu, Jan 5, 2012 at 4:01 PM Subject: Configuring the webhome page of main space? To: XWiki Users <users(a)xwiki.org> Hi All, I want to configure the default home page i.e webhome page of main space. I am looking for these kind of customizations:- 1) Replacing *Welcome to your wiki *with Welome to *ApplicationName Wiki.*Though i can see the ways to customize the panel bars,browser title bar text but not the text. 2) Right now, on web home page under main space i can see see all the details(like what activity admin or any other users did . For example modification in existing page or creation of new page) on page just after login (i.e webhome page on main space). i want to hide these unnecessary details from specific group users? Is it possible to customize. i am not even able to find the vm file for this page so that i can do some tweaking in code?

13 years

[xwiki-devs] Comment for the display module - velocity independance

by Vincent Massol

Hi Marius, I think the display module should be independent of the Velocity module. I see that the VelocityManager is used in DocumentContentDisplayer but I don't think that's nice. It's used to isolate the velocity context in case velocity is used. I think we can improve this for the following reasons: 1) We don't always need to render content using velocity 2) Code using the displayer shouldn't need to depend on velocity if it doesn't need to I think a better solution would be to have some generic component interface for isolating content (we might already have this) and then have the displayer call "registered" components without knowing them. This would mean that the code isolating the velocity namespace would be located in the velocity module itself for ex (or in a sub module) which makes more sense IMO. WDYT? Thanks -Vincent

13 years

[xwiki-devs] [vote] Renaming and moving of Curriki Project

by Ludovic Dubost

Hi, As there are now more projects using the Curriki Distribution, in the Curriki mailing list we have voted for the following changes for the Curriki Project: * Rename the main project xwiki-learning-cms * Call the core: xwiki-learning-cms-core: http://svn.xwiki.org/svnroot/xwiki/xwiki-learning-cms/xwiki-learning-cms-co… * Call the curriki specific code : curriki: http://svn.xwiki.org/svnroot/xwiki/xwiki-learning-cms/curriki * Call the planete sankoré specific code : sankore: http://svn.xwiki.org/svnroot/xwiki/xwiki-learning-cms/sankore The curriki 1.8 branches would go into the curriki area, except for the latest branch which would be duplicated in xwiki-kearning-cms-core as the 1.0 branch The 2.x branches would go into xwiki-learning-cms-core We would then publish the sankore core to the repository. As you can see these plans are based on SVN. A separate discussion is undergoing to see if we can easily move to GitHub. In this case we would ask for one or more repositories in the xwiki-contrib area. It's not clear to me in this case if we should use only one or 3 different repositories. I tend to think it should be 3. Finally we would rename curriki.xwiki.org into lcms.xwiki.org. We're asking the goahead from the XWiki commiters to make these changes. Here's my +1 Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years

[xwiki-devs] [Proposal] Rendering: Move MacroContentParser.getCurrentSyntax() to MacroTransformationContext.getCurrentSyntax()

by Vincent Massol

Hi dev, I've just noticed that we have a MacroContentParser.getCurrentSyntax() API. However there's a more general need of being able to get the current syntax even without using a MacroContentParser (I have this need now in some code). Thus I'm proposing to deprecate (remove?) the MacroContentParser.getCurrentSyntax() method and add a new MacroTransformationContext.getCurrentSyntax() WDYT? Thanks -Vincent

13 years

[xwiki-devs] [VOTE] Release XWiki Syntax 2.1 as official in Rendering 3.4

by Vincent Massol

Hi devs, I'd like to propose releasing XWiki Syntax 2.1 as official (it's currently experimental) for XWiki Rendering 3.4. Rationale ======== * It has useful expanded support for links and images compared to 2.0 * It's been "experimental" for a long time and people are already using it * It would be nice to release it in the 3.x cycle since it was started in that cycle * That would allow us to start XWiki Syntax 2.2 for the 4.x cycle (see outstanding items at http://tinyurl.com/6pdt5oa ) Migration aspects ============== * I don't think we need to mandate moving to 2.1 for users. They can keep using 2.0 if they want * We should make it the default wiki syntax starting in XE 3.4, leaving 2.0 available by default * I believe there's no conversion issue between 2.0 and 2.1 so it shouldn't be an issue for users wanting to switch. * We could provide a migration script on extensions.xwiki.org for users wanting to convert all their 2.0 pages into 2.1 pages Here's my +1 Thanks -Vincent

13 years

[xwiki-devs] [VOTE] Improve the database migration implementation on 3.4

by Denis Gervalle

Hi Devs, In order to change the way we compute document ID to reduce the likelihood of a collision, I need to improve and secure our current data migration system. I have started this works late during 3.2, but it since this is an important refactoring, and after discussion on IRC, it have been decide to wait for 3.4 to commit it, so we have a full cycle to have it carefully test. So I would like your approval now to commit this work. The advantages of these changes are: - Ensure that the hibernate store could not be access without having it migrated in the appropriate version for the running platform - Ensure that the hibernate store is left untouched if the migration have not been allowed - Easy addition of migrations, since migrator are now components - Schema and datamigration are done only once and together - One more step in the isolation of the store from XWiki - Secure enough to allow converting document IDs The impact on API and users are: - deprecate xwiki.store.hibernate.updateschema which is enable by default - xwiki.store.migration.databases=all by default (in place of xwiki) since this is the general UC - XWikiMigrationInterface and XWikiMigratorInterface are removed and new component roles DataMigrationManager and DataMigration should be used instead These improvements consist in: - Replace Migrators by DataMigration components - Replace the MigrationManager by a DataMigrationManager component - Put a "hibernate" hint on hibernate stores (in place of default) to allow the hibernate migrator to access a correctly typed store - inject and call the HibernateDataMigrationManager from the stores (and not from XWiki) - Convert data migration like action done during schema update (yes we have some sql updates during schema update) into a LegacyDataMigration producing data version 1 from data version 0 - Join together schema update and data migration on a unique place (schema update were currently done in several places in XWiki and the store) - XWIKI-1859: Do not start migrations on a clean installation of XWiki - XWIKI-2075: Move all databases upgrades and schema updates to XWiki's initialization instead of doing it lazily (partial fix, since it is still hard to have the store initialized has needed) - data migration is moved to the first access to a store (which is still during first request, but the matter is no more here) - XWIKI-2066: Migrator fails to upgrade sub wiki databases, now properly fixed (previous fix was a hack that do not) - no more excessive synchronization required for schema update, but there is still some mandatory document added lazily - clear reporting of access error when migration does not succeed For more, read http://markmail.org/thread/l3dzx7pj32n5qlqd Here is my +1 -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years

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